Cloudkeel-DD · Self-hosted drift detection

Know what’s
actually running.

Understand the gap between declared infrastructure and what is running across AWS, Azure, GCP and Kubernetes.

Investigate drift, review unmanaged resources and trace changes using available audit evidence. Cloudkeel-DD runs inside your cluster and reads connected infrastructure without changing it.

  • Self-hosted
  • Read-only scanning
  • No vendor telemetry
Cloudkeel-DDIllustrative findings
Investigate a change
Drift

Network rule changed

A declared resource differs from its current configuration.

Unmanaged

Resource outside Terraform state

Review resources that are not declared in the connected state.

Check supported coverage →
From a change to an investigation

Find the gaps.
Understand the change.

Review supported infrastructure in one place, then take findings back into your normal engineering workflow.

01

Configuration drift

Compare declared configuration with connected cloud resources and Kubernetes workloads. Investigate changes made outside your delivery workflow.

02

Unmanaged resources

Review discovered resources that are absent from connected Terraform state or Helm releases, within the supported inventory coverage.

03

Change attribution

Use available cloud audit evidence to investigate who changed a resource. Attribution depends on the connected source and available records.

What a finding can show

Illustrative examples · not customer data
AWS
Azure
GCP
AKS
EKS
GKE

Examples illustrate supported finding types. They are not proof of live-cloud validation for every resource shown. Review the coverage boundaries →

Make findings useful

Focus on changes
that need attention.

Use configurable rules, suppression and ownership to make drift review part of day-to-day operations.

Severity rules

Set thresholds by resource type, environment and property.

Semantic comparison

Account for defaulted fields and equivalent values; ignore tag-only changes.

Scoped suppression

Record a reason, set an expiry and define maintenance windows.

Finding ownership

Assign owners and route notifications by severity, category and team.

Back into your delivery process
  1. Review the finding
  2. Assess the change
  3. Prepare remediation
  4. Review and apply through your process

Remediation guidance and pull requests are reviewable. Cloudkeel-DD does not run terraform apply.

Coverage, with its limits

Know what
has been verified.

Available depth depends on your resource type and connected state source.

200
Resource types verified through engine and fixture tests.
3
Live-cloud drift demonstrations: Azure NSG rules, AWS security-group rules and GCP firewall rules.
View the full coverage tables →

Terraform Cloud

68 Azure types, 59 GCP types and AWS security groups with field-level comparison.

Raw Terraform state

77 Azure, 62 AWS and 59 GCP types. State can come from S3, GCS or Azure Blob.

Kubernetes / Helm

Deployments, StatefulSets, DaemonSets, Services, ConfigMaps and Ingress, compared with Helm release records.

Other discovered resources

Clearly labelled inventory where field-level comparison is not supported.

Your environment. Your control.

Run it inside
your own cluster.

Findings stay in your installation and stored credentials are encrypted. Configured notifications and remediation pull requests can share finding data with destinations you choose.

  • Read-only access to connected infrastructure.
  • Documented least-privilege permissions.
  • Kubernetes Secret values are never read or diffed.
Read the security overview →
Pricing

Start free.
Scale by scope.

A scope is an enabled subscription, account, project or cluster. Plans are priced by scope, with no per-resource charge.

New installs begin with 30 days unmetered, then continue on Free limits. One scope keeps scanning; findings and history remain available.

Take the next step

Start with your
own infrastructure.

Follow the installation guide, or discuss your deployment requirements with us.