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. - Enforced in code, not just policy. Every cloud and Kubernetes API call is checked against a deny-list at runtime, and a test scans each connector for a mutating call before it ships. The two share one list, so they can’t drift apart.
- 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 using envelope encryption: a data key wraps each secret, and that data key is itself wrapped by your install’s immutable Fernet key. The unwrapped data key is never written to disk or database.
- 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”- All data (inventory, findings, encrypted credentials) stays in your PostgreSQL inside your cluster.
- Outbound calls go only to the endpoints you connect: your Terraform backend, your cloud, your clusters. The site and app make no third-party calls.
- 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.
- Policy evaluation (OPA) is best-effort: a broken or absent policy engine degrades gracefully and never fails a scan or exposes data.
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.