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. That’s enforced in code, not just policy: every cloud and Kubernetes call is checked against a deny-list at runtime, backed by a test that scans each connector for a mutating call before it ships. 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 envelope-encrypted at the ORM boundary: a data key wrapped by a key only your install holds, and the unwrapped key is never written to disk or database.
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.