Security model
Cloudkeel-DD is designed to be safe to point at production: it runs in your cluster, reads with least-privilege credentials, and never writes to your cloud.
Read-only, always
Section titled “Read-only, always”- No writes to your cloud. Cloudkeel-DD never creates, updates, or deletes
cloud resources, and never runs
terraform apply. Every connection guide uses a read-only credential. - No auto-remediation. It produces a revert plan for drift; acting on it stays with you.
- The least-privilege reference lists the exact permissions each credential needs: all read/list/get, nothing mutating.
What it reads
Section titled “What it reads”| Source | What it reads |
|---|---|
| Terraform Cloud / state bucket | Your .tfstate (desired resource config) |
| Cloud APIs (Azure/AWS/GCP) | Live resource configuration in enabled scopes |
| Kubernetes API | Helm release records + live workload specs |
What it never reads or stores
Section titled “What it never reads or stores”- Kubernetes
Secretcontents are excluded from comparison entirely: secret values never land in a diff. - It reads Helm’s own release secrets only to learn desired state (the
rendered manifest), and still never diffs
Secretobjects. - It does not read your source code, CI logs, or anything outside the integrations you connect.
Credential handling
Section titled “Credential handling”- Connected credentials are encrypted at rest. Preserve the installation’s immutable Fernet key during upgrades and recovery; changing it can make stored credentials unreadable.
- Credentials are supplied by you and scoped narrowly (a bucket, a subscription, a cluster). Rotating them is a mint-new-key-then-update flow: see troubleshooting.
- Credentials are isolated per tenant: one workspace can never reach another’s integration, cloud credential, or GitHub/GitLab token.
Network & data residency
Section titled “Network & data residency”- Inventory, findings and encrypted credentials are stored in your installation.
- Outbound calls go only to the endpoints you connect: your Terraform backend, your cloud, your clusters, and any notification webhook or Git host you configure. Notifications and remediation pull requests can carry finding data to those chosen destinations.
- The UI is reached via
kubectl port-forwardby default, or through your own ingress if you opt in. Terminate TLS there in production.
Application security
Section titled “Application security”- All container images run as a non-root user.
- The API enforces authentication; sessions are signed with the JWT secret. Startup fails fast if that secret is missing, default, or too short: there is no way to run with a known or guessable key.
- Security headers (including a Content-Security-Policy and HSTS) are set on every route of the app and the marketing site.
- Rate limiting protects the API (configurable).
- Dependencies are kept current against known CVEs.
Tenancy
Section titled “Tenancy”Each install serves your organization’s tenant(s). Integrations, scopes, resources, and findings are isolated per tenant: one tenant’s credentials and integrations are never reachable from another’s.
Reporting a vulnerability
Section titled “Reporting a vulnerability”Email hello@cloudkeel.io.
Internal security implementation details are available through a private technical review.