← Back to Skills Marketplace
charlie-morrison

Config Drift Scanner

by charlie-morrison · GitHub ↗ · v1.0.0 · MIT-0
cross-platform ⚠ suspicious
28
Downloads
0
Stars
0
Active Installs
1
Versions
Install in OpenClaw
/install config-drift-scanner
Description
Detect configuration drift across environments (dev, staging, production). Compare config files, environment variables, feature flags, and secrets across dep...
README (SKILL.md)

Config Drift Scanner

Find configuration differences across your environments before they cause incidents. Compare config files, environment variables, feature flags, database settings, and runtime parameters between dev/staging/production — catching the "works on my machine" problems that slip past code review.

Use when: "compare configs between environments", "find config drift", "why does staging work but prod doesn't", "audit environment parity", "check env vars across deploys", or after an incident caused by config mismatch.

Commands

1. scan — Detect Drift Across Environments

Step 1: Discover Configuration Sources

# Find config files in the project
find . -maxdepth 4 \( \
  -name "*.env" -o -name "*.env.*" -o \
  -name "*.config.*" -o -name "config.yaml" -o -name "config.json" -o \
  -name "*.toml" -o -name "settings.*" -o \
  -name "docker-compose*.yml" -o -name "docker-compose*.yaml" -o \
  -name "values*.yaml" -o -name "*.tfvars" \
  \) -not -path "*/node_modules/*" -not -path "*/.git/*" 2>/dev/null

# Find environment variable references in code
rg "process\.env\.|os\.environ|os\.getenv|ENV\[|System\.getenv" \
  --type-not binary -g '!node_modules' -g '!vendor' --stats 2>&1 | tail -5

Step 2: Extract Config from Each Environment

For Kubernetes:

# ConfigMaps
for env in dev staging prod; do
  kubectl get configmaps -n "$env" -o json | python3 -c "
import json, sys
cms = json.load(sys.stdin)['items']
for cm in cms:
    name = cm['metadata']['name']
    for k, v in cm.get('data', {}).items():
        print(f'{name}.{k}={v}')
" > "/tmp/config-$env.txt"
done

For .env files:

# Compare .env files across environments
for f in .env.development .env.staging .env.production; do
  if [[ -f "$f" ]]; then
    echo "=== $f ==="
    grep -v '^#' "$f" | grep -v '^$' | sort
  fi
done

For Terraform:

# Compare tfvars across environments
for f in terraform/environments/*/terraform.tfvars; do
  echo "=== $f ==="
  cat "$f"
done

Step 3: Diff and Classify

Compare each key across environments and classify differences:

🔴 Dangerous Drift (same key, unexpected difference):

  • Database connection strings pointing to wrong environment
  • API keys that should be environment-specific but are shared
  • Feature flags enabled in prod but disabled in staging (testing gap)
  • Timeout values that differ without documented reason
  • Memory/CPU limits that are lower in prod than staging

🟡 Expected Drift (different by design):

  • Database URLs (each env has its own DB)
  • API endpoints (staging.api.com vs api.com)
  • Log levels (DEBUG in dev, INFO in prod)
  • Replica counts (1 in dev, 3 in prod)

🟢 Missing in Environment (potential problem):

  • Env var exists in prod but not staging → can't test that code path
  • Config key exists in staging but not prod → forgot to add on deploy

Step 4: Generate Report

# Configuration Drift Report

## Environments Compared: dev ↔ staging ↔ production

## 🔴 Dangerous Drift (3 found)
1. `DATABASE_POOL_SIZE`: dev=5, staging=10, **prod=5**
   → Prod should be ≥ staging. Likely copy-paste from dev config.

2. `FEATURE_NEW_CHECKOUT`: dev=true, staging=true, **prod=false**
   → Feature tested in staging but not enabled in prod. Intentional? If so, document.

3. `REDIS_TIMEOUT_MS`: dev=5000, **staging=500**, prod=5000
   → Staging has 10× shorter timeout. Will mask timeout bugs in staging tests.

## 🟡 Expected Drift (8 found)
- DATABASE_URL: different per environment ✅
- LOG_LEVEL: debug/info/warn ✅
- API_BASE_URL: per-environment ✅

## 🟢 Missing Variables (2 found)
- `SENTRY_DSN`: exists in prod, missing in staging → errors not tracked in staging
- `RATE_LIMIT_RPS`: exists in prod (100), missing in dev/staging → no rate limit testing

## Recommendations
1. Add SENTRY_DSN to staging for error visibility
2. Fix DATABASE_POOL_SIZE in prod (should be ≥ staging value)
3. Document why FEATURE_NEW_CHECKOUT differs between staging and prod

2. watch — Continuous Drift Monitoring

Set up a CI check that runs on every config change:

# GitHub Actions
name: Config Drift Check
on:
  push:
    paths:
      - '**/*.env*'
      - '**/config.*'
      - '**/values*.yaml'
      - '**/*.tfvars'
jobs:
  drift:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check for drift
        run: |
          # Compare all env files and flag dangerous differences
          diff \x3C(grep -v '^#' .env.staging | sort) \x3C(grep -v '^#' .env.production | sort) || true

3. template — Generate Config Parity Checklist

For a new environment setup, generate a checklist of all config keys that need to be set, with:

  • Required vs optional
  • Expected value ranges
  • Whether the value should differ or match other environments
  • Where to get the value (secrets manager, team lead, auto-generated)

4. secrets-check — Verify Secret Rotation

Cross-reference config with secrets management:

  • Which secrets are hardcoded vs pulled from vault/secrets manager?
  • When were secrets last rotated?
  • Are any secrets shared across environments (bad practice)?
  • Are test/dev credentials accidentally in prod config?
Usage Guidance
This skill appears to do what it says but is missing important runtime requirements and safety guidance. Before installing or running it: 1) Confirm which binaries are required (kubectl, python3, rg/ripgrep, grep/find) and ensure they exist in the runtime environment. 2) Do not point it at a kubeconfig with wide privileges — provide a read-only, least-privilege service account or a context limited to non-production if possible. 3) Ask the publisher to declare required credentials (KUBECONFIG, VAULT_TOKEN, cloud creds) and to add explicit handling to avoid printing or transmitting secrets (redaction, minimal outputs). 4) Prefer running this in an isolated CI job with limited credentials rather than on a developer laptop with full access. 5) If you need secrets-check functionality, require explicit, auditable integrations with your secrets manager (and avoid storing secrets in plaintext in reports). If the publisher cannot clarify these points, treat the skill as risky to run against real clusters or repos containing secrets.
Capability Analysis
Type: OpenClaw Skill Name: config-drift-scanner Version: 1.0.0 The config-drift-scanner skill uses high-privilege shell commands (find, rg, kubectl) to recursively search for and extract sensitive configuration data, including .env files, Terraform variables, and Kubernetes ConfigMaps. While these capabilities are aligned with the stated purpose of detecting environment inconsistencies, the broad access to secrets and environment variables across the entire project constitutes a high-risk behavior. No evidence of data exfiltration or intentional malice was found in SKILL.md or _meta.json.
Capability Assessment
Purpose & Capability
The skill's stated purpose (compare configs, env vars, feature flags, secrets across environments) aligns with the commands in SKILL.md (search repo, read .env/tfvars, query Kubernetes ConfigMaps). However the SKILL.md assumes tools and access (kubectl, python3, rg/ripgrep, read access to repo and cluster contexts) that are not declared in the registry metadata. Also the doc claims to check 'secrets' and 'secrets manager' but the provided kubectl example only reads ConfigMaps (not Kubernetes Secrets) and there are no concrete vault/secret-manager integration steps — an inconsistency between claimed capability and concrete instructions.
Instruction Scope
Instructions direct the agent to scan local repository files, run ripgrep over source, and query Kubernetes namespaces (dev/staging/prod), producing files in /tmp and a markdown report. These actions legitimately fit the goal but will require reading potentially sensitive data (env files, tfvars, ConfigMaps and possibly Secrets if adapted). The SKILL.md gives no guidance on safe handling/redaction of secrets, nor does it constrain which kube contexts to use — it implicitly assumes kubeconfig with access to dev/staging/prod. That grants broad data access and could expose secrets if the agent transmits outputs.
Install Mechanism
This is an instruction-only skill with no install spec and no code files, which minimizes disk write/install risk. Risk derives from runtime commands (kubectl, rg, python3) rather than an install mechanism.
Credentials
Registry metadata declares no required env vars or credentials, yet the instructions require access to cluster credentials (kubeconfig or context with rights to read ConfigMaps/possibly Secrets), and mention cross-referencing with secrets managers/vault without declaring needed tokens (VAULT_TOKEN, cloud provider creds, etc.). The absence of declared credentials is disproportionate to the sensitive operations described and makes the skill's security assumptions unclear.
Persistence & Privilege
The skill does not request always:true and is user-invocable only; autonomous invocation is allowed (platform default). There is no install-time persistence. Note: if given cluster credentials and autonomous invocation, the agent could repeatedly access sensitive config — consider this when granting runtime credentials.
How to Use
  1. Make sure OpenClaw is installed (local or Docker)
  2. Run the install command in chat: /install config-drift-scanner
  3. After installation, invoke the skill by name or use /config-drift-scanner
  4. Provide required inputs per the skill's parameter spec and get structured output
Version History
v1.0.0
Initial release of Config Drift Scanner: Quickly detect and report configuration inconsistencies across environments. - Scan and compare config files, environment variables, feature flags, and secrets between dev, staging, and production. - Classify and report drift as dangerous, expected, or missing values. - Generate clear, actionable configuration drift reports to prevent incidents. - Includes commands for continuous monitoring (CI integration), onboarding checklists, and secret source/rotation analysis.
Metadata
Slug config-drift-scanner
Version 1.0.0
License MIT-0
All-time Installs 0
Active Installs 0
Total Versions 1
Frequently Asked Questions

What is Config Drift Scanner?

Detect configuration drift across environments (dev, staging, production). Compare config files, environment variables, feature flags, and secrets across dep... It is an AI Agent Skill for Claude Code / OpenClaw, with 28 downloads so far.

How do I install Config Drift Scanner?

Run "/install config-drift-scanner" in the OpenClaw or Claude Code chat to install it in one step — no extra setup required.

Is Config Drift Scanner free?

Yes, Config Drift Scanner is completely free, licensed under MIT-0. You can download, install and use it at no cost.

Which platforms does Config Drift Scanner support?

Config Drift Scanner is cross-platform and runs anywhere OpenClaw / Claude Code is available (cross-platform).

Who created Config Drift Scanner?

It is built and maintained by charlie-morrison (@charlie-morrison); the current version is v1.0.0.

💬 Comments