How drift detection works

Cloudkeel-DD compares desired state against actual state on every scan.

The two halves

Most clouds need two integrations working together:

1. A state source (Terraform Cloud, or raw .tfstate in cloud storage) supplies the desired state.
2. A cross-check credential (a read-only Azure/AWS/GCP identity) lets Cloudkeel-DD read the actual live resources.

With only the state source, resources are discovered but tagged “no live comparison available”: you get inventory, not drift. With only the credential, there’s nothing to compare against. Connect both, per cloud.

Kubernetes is the exception; one kubeconfig integration is self-contained: desired = Helm’s own stored release manifest, actual = a live read of the Kubernetes API.

What to expect from a scan

A completed scan can report differences on supported fields, discovered resources that are not declared in connected state, and policy findings. Findings can open, refresh or resolve as the observed configuration changes. Review coverage before treating an absence of findings as evidence that a resource was compared.

Scans are point-in-time observations. Use the scan timestamp and connection status when interpreting the result; a previous scan does not establish the current state of a rapidly changing environment.

Scopes

A scope is an account / subscription / project / cluster that a credential can see. Live verification only runs against enabled scopes:

• AWS and GCP auto-enable the scope from the account ID / project ID you enter.
• Azure discovers your subscriptions and leaves each disabled until you opt in: a common “connected but no drift shows” cause. See troubleshooting.

Does scanning cost anything on your cloud bill, or hit rate limits?

Scanning reads the state sources and cloud or Kubernetes APIs you connect. Choose a cadence appropriate to the environment size and your provider quotas. Check scan status and connection errors if a scan takes longer than expected.

Your environment also needs capacity to run the installation and store its findings. Review applicable provider charges for connected services and storage; read-only access is not a guarantee that every surrounding service is free. The integration troubleshooting guide covers permissions, scope selection and connection checks.

By-design behaviours (not bugs)

• Tag/label-only changes aren’t flagged. A changed cloud tag, GCP label, or Kubernetes label is low-signal; comparison focuses on supported fields (firewall/security-group rules, replica counts, images).
• Adding a brand-new field the chart never declared isn’t Kubernetes drift: changing a field the manifest owns is. The API server defaults dozens of fields no chart declares; without this every resource would “drift” the moment it was created.

For internal architecture and implementation questions, request a private technical review.