Eight ways your Terraform state is already lying to you.

The console fix that never made it back into code

Someone opened a security group during an incident to unblock a teammate, the incident closed, and the rule stayed open. Nobody wrote a PR. Nobody was thinking about Terraform at 2 a.m. terraform plan stays clean, because the resource is still declared.

Cloudkeel-DD re-reads the live resource on every scan and diffs it field by field against what’s declared. The finding names the exact property, not "something changed," and this is one of the three types proven against a real, live cloud account with drift actually injected and detected.

source_ranges[0]: 10.30.0.0/16 → 0.0.0.0/0

Who made the change is best-effort, from cloud activity logs, within a lookback window, not a guarantee for every provider or every change age.

The resource nobody remembers creating

A "temporary" bucket from a migration two years ago. A contractor’s VM. A load balancer someone spun up to test something and never tore down. None of it is in any .tfstate: invisible to terraform plan by construction, not by bug.

Unmanaged-resource detection surfaces live infrastructure that no connected Terraform state declares: 202 enumerated resource types across the three clouds today, labeled clearly as unmanaged rather than folded into a drift count.

The first scan’s unmanaged list is genuinely noisy: service-created resources (default VPC security groups, service-linked roles, GCP’s default-allow-* rules) surface too. Ownership is assigned manually, never guessed.

The kubectl edit that Git never saw

Someone scaled a Helm-managed Deployment by hand during a traffic spike, or patched a ConfigMap directly to unblock a rollout. It works, everyone moves on, and the chart in Git now describes a cluster state that doesn’t exist anymore.

Cloudkeel-DD reads Helm’s own stored release records directly and diffs the live object against them (no Argo CD or Flux required). Field-level coverage spans sixteen kinds: Deployments, StatefulSets, DaemonSets, Services, ConfigMaps, Ingress, NetworkPolicies, Jobs, CronJobs, HorizontalPodAutoscalers, PersistentVolumeClaims, ServiceAccounts, ClusterRoles, ClusterRoleBindings, Roles, and RoleBindings.

Sixteen kinds, not "all Kubernetes objects"; anything outside that list isn’t compared field by field yet.

The container that’s allowed to run as root, and nobody flagged it

A Deployment ships without securityContext.runAsNonRoot, which is easy to miss in review: most eyes are on the image and the rollout strategy, not a security-context block three levels deep in the YAML.

Cloudkeel-DD evaluates every Deployment, StatefulSet, and DaemonSet against this rule on every scan of the live cluster, not just once at review time. The same rule catches it on day one, and catches it again if a later manual edit quietly drops the non-root guarantee.

container "web" in Deployment/checkout-api has no securityContext.runAsNonRoot

This isn’t a pre-merge or admission-control gate: it runs on your normal scan schedule, so there’s a window between the change landing and the next scan, not an inline block on kubectl apply.

The LoadBalancer Service that quietly went public

Someone flips a Service to type LoadBalancer to test something externally, or a Helm values change does it without anyone reading the networking implication; now there’s a public IP in front of a workload that was never supposed to be internet-facing.

The same exception-based policy model used for public IPs and load balancers on the cloud side applies here: any Kubernetes Service of type LoadBalancer without an explicit exception annotation gets flagged, checked against the live cluster on every scan.

Service "checkout-api" is type LoadBalancer with no exception annotation

Same scan-schedule caveat as above: this flags exposure that already exists, on your next scan, not at the moment someone applies the change.

Catching it before it merges, not after

The worst version of case 1 is the one that ships on purpose: a PR that widens a rule to unblock a deploy, reviewed quickly, merged, applied. Nobody flags it because nobody ran a policy check against that specific change before it landed.

Copy-paste GitHub Actions and GitLab CI templates evaluate a terraform change against your policy rules pre-merge and fail the PR/MR before apply. A merge that gets through still fires an immediate post-deploy scan, so the gate and the continuous check share one rule set.

The audit finding on a resource nobody owns

An audit flags a finding, and the first ten minutes go to figuring out who’s responsible, whether it’s known, and why it’s still open. If the last drift tool got noisy and got muted, there’s no history to point to either.

Severity is rule-based and yours to define (by resource type, environment, and property, most-specific wins), and a suppressed finding requires a reason, carries an expiry, and auto-reopens if the drift changes. An append-only record, not a dashboard where findings silently vanish.

This is a suppression and audit-history model, not a compliance certification; Cloudkeel-DD is pre-launch and does not hold a SOC 2.

One tool, three clouds, a bill that doesn’t punish you for looking

Estates spanning AWS, Azure and GCP usually end up with three separate drift workflows, or a SaaS CSPM priced per resource, which taxes exactly the behavior you want to encourage: connecting more of the estate.

Cloudkeel-DD is one self-hosted install covering AWS, Azure, GCP and Kubernetes, metered per enabled scope (one subscription, account, project, or cluster), never per resource. A scope with 5 resources and one with 5,000 cost the same.

Coverage depth isn’t identical across clouds: 200 types have field-level specs (Azure 79, AWS 62, GCP 59), and AWS field diffs want raw .tfstate specifically. Detection is comparable across clouds; severity scoring is not yet.