← 返回 Skills 市场
charlie-morrison

Config Drift Scanner

作者 charlie-morrison · GitHub ↗ · v1.0.0 · MIT-0
cross-platform ⚠ suspicious
28
总下载
0
收藏
0
当前安装
1
版本数
在 OpenClaw 中安装
/install config-drift-scanner
功能描述
Detect configuration drift across environments (dev, staging, production). Compare config files, environment variables, feature flags, and secrets across dep...
使用说明 (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?
安全使用建议
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.
功能分析
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.
能力评估
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.
如何使用
  1. 确保已安装 OpenClaw(本地或 Docker 部署)
  2. 在对话框中输入安装命令:/install config-drift-scanner
  3. 安装完成后,直接呼叫该 Skill 的名称或使用 /config-drift-scanner 触发
  4. 根据 Skill 的参数说明提供必要输入,即可获得结构化输出
版本历史
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.
元数据
Slug config-drift-scanner
版本 1.0.0
许可证 MIT-0
累计安装 0
当前安装数 0
历史版本数 1
常见问题

Config Drift Scanner 是什么?

Detect configuration drift across environments (dev, staging, production). Compare config files, environment variables, feature flags, and secrets across dep... 它是一个面向 Claude Code / OpenClaw 的 AI Agent Skill 插件,目前累计下载 28 次。

如何安装 Config Drift Scanner?

在 OpenClaw 或 Claude Code 对话框中运行命令「/install config-drift-scanner」即可一键安装,无需额外配置。

Config Drift Scanner 是免费的吗?

是的,Config Drift Scanner 完全免费,采用 MIT-0 许可证,可自由下载、安装和使用。

Config Drift Scanner 支持哪些平台?

Config Drift Scanner 跨平台运行,可在任意部署了 OpenClaw / Claude Code 的环境中使用(cross-platform)。

谁开发了 Config Drift Scanner?

由 charlie-morrison(@charlie-morrison)开发并维护,当前版本 v1.0.0。

💬 留言讨论