curiositech/secret-management-expert

Secret Management Expert

Expert in secret lifecycle management — storage, rotation, injection, and audit — across cloud and self-hosted infrastructure.

Activation Triggers

Activate on: "secret management", "Vault setup", "AWS Secrets Manager", "secret rotation", "SOPS encryption", "sealed secrets", "credential storage", "API key management", "least privilege secrets"

NOT for: Application auth flows → oauth-oidc-implementer | Network security → security-auditor | Encryption at rest → devops-automator

Quick Start

1. Inventory secrets — catalog all credentials, API keys, certificates, and tokens
2. Choose a backend — Vault for self-hosted, AWS Secrets Manager/GCP Secret Manager for cloud-native
3. Implement injection — sidecar (Vault Agent), CSI driver, or init container pattern
4. Enable rotation — automated rotation with zero-downtime credential swaps
5. Audit and alert — log all secret access, alert on anomalous patterns

Core Capabilities

| Domain | Technologies | |--------|-------------| | Secret Stores | HashiCorp Vault 1.18, AWS Secrets Manager, GCP Secret Manager, Azure Key Vault | | Encryption | SOPS 3.9, age, AWS KMS, GCP Cloud KMS, sealed-secrets | | K8s Integration | External Secrets Operator, Vault CSI Provider, Sealed Secrets controller | | Rotation | Vault dynamic secrets, AWS Lambda rotation, custom rotation functions | | Audit | Vault audit log, CloudTrail, access anomaly detection |

Architecture Patterns

External Secrets Operator (K8s Best Practice, 2026)

# ExternalSecret pulls from AWS Secrets Manager into K8s Secret
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: database-credentials
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: aws-secrets-manager
    kind: ClusterSecretStore
  target:
    name: db-credentials        # K8s Secret name
    creationPolicy: Owner
  data:
    - secretKey: DB_PASSWORD
      remoteRef:
        key: prod/database/postgres
        property: password
    - secretKey: DB_USERNAME
      remoteRef:
        key: prod/database/postgres
        property: username

Vault Dynamic Secrets (Zero Standing Credentials)

App requests credential → Vault generates ephemeral DB credential
  ├─ Credential has TTL (e.g., 1 hour)
  ├─ Vault creates DB user with scoped permissions
  ├─ App uses credential until near expiry
  ├─ Vault Agent auto-renews or rotates
  └─ On expiry: Vault revokes DB user automatically

Result: No long-lived credentials exist. Every credential is:
  - Unique to the requester
  - Time-bounded
  - Automatically revoked
  - Fully audited

SOPS for Git-Encrypted Secrets

# Encrypt secrets file with age key (developer workflow)
sops --encrypt --age age1... secrets.yaml > secrets.enc.yaml

# Decrypt in CI/CD pipeline
export SOPS_AGE_KEY=$(vault kv get -field=age-key secret/ci/sops)
sops --decrypt secrets.enc.yaml > secrets.yaml

# .sops.yaml — defines encryption rules per path
creation_rules:
  - path_regex: secrets\.yaml$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p
  - path_regex: \.env\..*$
    age: age1ql3z7hjy54pw3hyww5ayyfg7zqgvc7w3j2elw8zmrj2kg5sfn9aqmcac8p

Anti-Patterns

1. Secrets in environment variables at build time — Docker ARG and ENV persist in image layers. Use runtime injection via sidecar, CSI driver, or entrypoint script.
2. Shared service accounts — one credential used by multiple services. Use per-service identities with scoped permissions so compromise is isolated.
3. No rotation — static credentials that never change. Implement automated rotation with overlap periods so active credentials always work.
4. Secrets in Git — even in .env.example with placeholder values that get real values committed. Use SOPS, sealed-secrets, or External Secrets Operator. Add .env* to .gitignore.
5. Manual secret distribution — passing credentials via Slack, email, or shared drives. Use a secret store with RBAC and audit logging.

Quality Checklist

[ ] All secrets stored in a dedicated secret store (not config files)
[ ] No secrets in Docker image layers, Git history, or CI logs
[ ] Automated rotation enabled for database credentials
[ ] Secret access logged and auditable (Vault audit, CloudTrail)
[ ] Least privilege: each service has scoped access to only its secrets
[ ] SOPS or sealed-secrets used for any secrets committed to Git
[ ] Dynamic secrets preferred over static credentials
[ ] Secret TTLs set — no indefinite credentials
[ ] Emergency revocation procedure documented and tested
[ ] CI/CD uses short-lived tokens (OIDC federation), not long-lived keys
[ ] Developers cannot access production secrets from local machines
[ ] Secret sprawl inventory maintained and reviewed quarterly