/arn-infra-secrets

name: arn-infra-secrets
description: >-
  This skill should be used when the user says "manage secrets", "arn infra secrets",
  "infra secrets", "secrets management", "set up secrets", "configure secrets",
  "audit secrets", "secrets audit", "rotate secrets", "secret storage",
  "vault setup", "key management", "credential management", "secrets scan",
  "check for exposed secrets", "secrets provider", "arn-infra-secrets",
  "set up secret manager", "configure secret injection", "environment variables",
  "env vars", "secure env vars", or wants to set up,
  configure, audit, or manage secrets and credential storage for their
  infrastructure deployment.
version: 1.0.0

Arness Infra Secrets

Set up, configure, and audit secrets management for infrastructure deployments. This skill scans the project for secrets exposure, recommends a secrets management provider, guides setup, configures injection into deployments, and produces a secrets audit report.

This skill addresses the complete secrets lifecycle: discovery of existing patterns, provider selection, configuration, injection into applications and CI/CD, and ongoing audit verification.

Prerequisites

Read `## Arness` from the project's CLAUDE.md. If no `## Arness` section exists or Arness Infra fields are missing, inform the user: "Arness Infra is not configured for this project yet. Run `/arn-infra-wizard` to get started — it will set everything up automatically." Do not proceed without it.

Check the **Deferred** field. If `Deferred: yes`, inform the user: "Infrastructure is in deferred mode. Secrets management is not available until infrastructure is fully configured. Run `/arn-infra-assess` to un-defer." Stop.

Extract:

• **Experience level** -- derived from user profile. Read `~/.arness/user-profile.yaml` (or `.claude/arness-profile.local.md` if it exists — project override takes precedence). Apply the experience derivation mapping from `${CLAUDE_PLUGIN_ROOT}/skills/arn-infra-ensure-config/references/experience-derivation.md`. If no profile exists, check for legacy `Experience level` in `## Arness` as fallback.
• **Providers** -- cloud providers in use (determines available secrets services)
• **Providers config** -- path to `providers.md` for per-provider details
• **Default IaC tool** -- for generating secrets manager IaC
• **Environments** -- environment list for per-environment secret scoping
• **Environments config** -- path to `environments.md`
• **Tooling manifest** -- path to `tooling-manifest.json` for available scanning tools
• **CI/CD platform** -- for pipeline secret injection (github-actions, gitlab-ci, bitbucket-pipelines, none)

---

Workflow

Step 1: Scan for Existing Secrets Patterns

Invoke the `arn-infra-security-auditor` agent via the Task tool, passing the model from `.arness/agent-models/infra.md` as the `model` parameter (see `plugins/arn-infra/skills/arn-infra-ensure-config/references/ensure-config.md` "Dispatch convention" for fallback). Context:

--- FILES TO AUDIT --- Scan the entire project for secrets patterns:

• `.env` files, `.env.*` files
• Configuration files (config.*, settings.*, application.*)
• Dockerfiles and docker-compose files
• IaC files (*.tf, *.hcl, Pulumi.*, cdk.json, *.bicep)
• CI/CD pipeline files (.github/workflows/*, .gitlab-ci.yml)
• Source code files (look for hardcoded connection strings, API keys, tokens)

--- END FILES TO AUDIT ---

--- AUDIT CONTEXT --- Audit type: Secrets exposure scan Focus: Identify all secrets, credentials, API keys, tokens, connection strings, and passwords Check: .env files committed to git, secrets in Dockerfile build args, hardcoded values in IaC --- END AUDIT CONTEXT ---

--- INSTRUCTIONS --- Perform a comprehensive secrets scan: 1. Check if .env files are committed to git (vs. .gitignore'd) 2. Scan Dockerfiles for secrets in ARG, ENV, or COPY directives 3. Scan IaC files for hardcoded values (passwords, keys, connection strings) 4. Scan CI/CD pipelines for exposed secrets in logs or artifacts 5. Check for TruffleHog/Gitleaks availability and run if found 6. Identify all environment variables that contain sensitive values 7. List all secrets that need to be managed --- END INSTRUCTIONS ---

After the agent returns its scan report, present the findings to the user using this format: "I scanned your project for secrets patterns. Here is what I found:

• **Secrets found:** [count] potential secrets in [count] files
• **High risk:** [list critical findings -- e.g., committed .env files, hardcoded passwords]
• **Medium risk:** [list moderate findings]
• **Current secrets management:** [detected approach, or 'none']"

---

Step 2: Recommend Secrets Provider

> Read the local override or plugin default for `secrets-providers.md`.

Based on the configured cloud provider(s) and experience level, recommend a secrets management approach:

**Expert:** Present all options with comparison: "Here are the secrets management options for your setup:

| Provider | Cost | Integration | Features | Recommendation | |----------|------|-------------|----------|----------------| [comparison table from reference]

Which would you prefer?"

**Intermediate:** Present the top 2 recommendations:

Ask (using `AskUserQuestion`):

**"Which secrets provider do you prefer for your [provider] setup?"**

Options: 1. **[Native option]** -- Tightest integration with [provider], [cost]. Best if you're staying single-cloud. 2. **[Cross-cloud option]** -- Works across providers, [cost]. Best if you have multi-cloud plans.

**Beginner:** Make a direct recommendation: "For your setup, I recommend using [provider's native secrets manager / Doppler] because [rationale]. It is the simplest option that provides secure secrets storage."

**Provider mapping:**

• AWS --> AWS Secrets Manager (or SSM Parameter Store for simpler needs)
• GCP --> GCP Secret Manager
• Azure --> Azure Key Vault
• Multi-cloud --> HashiCorp Vault or Doppler
• PaaS (Fly.io, Railway, etc.) --> Platform-nati