The whole product is built on one boundary: Cloudkeel-DD runs inside your environment and only ever reads. Your credentials stay yours, findings live in your database, and the only paths out are the ones you wire up yourself.
Cloudkeel-DD never creates, updates, or deletes a resource, and never runs terraform apply. It reads state and reads live infrastructure — that’s the entire surface. Detection and remediation are separate: a revert plan is generated for you to review and run yourself, never applied automatically.
There is no SaaS backend. No vendor holds keys to your estate. Integration secrets — tokens, kubeconfigs — are Fernet-encrypted at the ORM boundary and stored in your own PostgreSQL, with a key only your install holds.
The exact permissions each connector needs are published per cloud, scoped read-only. Our own verification used exactly these: a read-only IAM user on AWS, a scoped ServiceAccount + read-only ClusterRole on Kubernetes. Nothing broader.
The Kubernetes connector reads workload manifests and live object state to detect drift. Secret object values are never read or diffed — they never enter the diff engine at all.