Env Secrets Manager
.env management, leak detection, and rotation workflows.
$skillfish add ~skills/env-secrets-manager Real Conversations
See how the Env Secrets Manager skill responds to actual requests. These are representative examples of what your AI agent will produce.
A security scan flagged that we might have secrets in our git history. We have 5 .env files across environments and a 3-year git history. How do I check what's been committed?
This skill includes executable scripts — I'll need your permission before running them.
The leak scanner checks both current files and full git history:
python scripts/env_scanner.py --repo . --scan-history --format text
What it scans:
- Current
.env*files for patterns: API keys, tokens, passwords, connection strings git log --all --full-history -- '*.env*'for historical commits- All branches for patterns matching known secret formats (AWS, Stripe, GitHub, etc.)
Sample findings:
Leak Scan Report
════════════════
Files scanned: 5 | Commits scanned: 1,847
CRITICAL — Active secret in git history
Commit: a3b7c2d (2023-08-14) — "Add staging config"
File: .env.staging
Match: STRIPE_SECRET_KEY=sk_live_4xT...
Status: Key may still be valid — ROTATE IMMEDIATELY
HIGH — .env.local tracked by git
.gitignore missing .env.local
Contains: OPENAI_API_KEY, DATABASE_URL
Action: Remove from tracking + add to .gitignore
INFO — .env.example is clean (expected)
Immediate response for the Stripe key:
- Rotate in Stripe dashboard → Developers → API Keys (30 seconds)
- Update the new key in your secrets manager
- Scrub from git history:
git filter-repo --path .env.staging --invert-paths - Force-push all branches (coordinate with the team first)
Prevent recurrence:
# .gitignore
.env
.env.*
!.env.example
Get Started
How to install and use this skill in your preferred environment.
Skills are designed for AI coding agents (Claude Code, Cursor, Windsurf) and IDE-based workflows where the agent can read files, run scripts, and act on your codebase. Web-based AI can use the knowledge and frameworks, but won't have tool access.
Models & Context
Which AI models and context windows work best with this skill.
Recommended Models
Larger models produce more detailed, production-ready outputs.
Context Window
This skill's SKILL.md is typically 3–10 KB — fits in any modern context window.
All current frontier models (Claude, GPT, Gemini) support 100K+ context. Use the full window for complex multi-service work.
Pro tips for best results
Be specific
Include numbers — users, budget, RPS — so the skill can size the architecture.
Share constraints
Compliance needs, team size, and existing stack all improve the output.
Iterate
Start with a high-level design, then ask follow-ups for IaC, cost analysis, or security review.
Combine skills
Pair with companion skills below for end-to-end coverage.
Good to Know
Advanced guide and reference material for Env Secrets Manager. Background, edge cases, and patterns worth understanding.
Contents
Secret Classification and Rotation Cadence
Not all secrets have the same risk profile. Treat them differently:
| Type | Examples | Rotation cadence | Risk on exposure |
|---|---|---|---|
| Static credentials | DB passwords, SSH keys | 90 days minimum; 30 days for critical | Full access until rotated |
| Short-lived tokens | AWS STS, OIDC JWT, Vault leases | Minutes to hours (auto-expires) | Minimal — expires on its own |
| API keys | Stripe, Twilio, SendGrid | 180 days or on personnel change | Service-level blast radius |
| TLS certificates | mTLS certs, internal CA | Before expiry; automate with cert-manager | Service disruption on expiry |
Short-lived tokens via workload identity are the goal. Everything else is a compromise you're accepting because migration hasn't happened yet.
Zero-Trust Secret Access Patterns
Long-lived API keys are the path of least resistance and the highest risk. A key in an environment variable is one printenv away from leaking. Any process that can read the environment can steal it.
Workload identity replaces this with cryptographic proof of identity:
- AWS IRSA (IAM Roles for Service Accounts): Pod's service account is annotated with an IAM role ARN. AWS SDK exchanges a projected service account token for temporary STS credentials. No secrets stored anywhere.
- GCP Workload Identity: Same model — Kubernetes service account mapped to a GCP service account. Credentials are fetched automatically by the metadata server.
- Azure Managed Identity: VM or pod is assigned an identity; applications call the IMDS endpoint at
169.254.169.254to get tokens. Zero config in application code.
# IRSA example — verify your pod is using workload identity correctly:
aws sts get-caller-identity
# Should return the role ARN from your annotation, not a long-lived key
If get-caller-identity returns a user ARN instead of a role ARN, a long-lived key is in the environment and bypassing IRSA.
Rotation Strategies Without Downtime
The dual-active (blue/green credential) pattern:
- Create new credential (
db_password_v2) alongside existing (db_password_v1) - Grant both credentials access to the database simultaneously
- Deploy application update to read
v2— both work during rollout - Confirm all instances are using
v2(check access logs) - Revoke
v1
This gives you a safe rollback window. The failure mode of immediate rotation (create new, delete old, deploy) is that any pods that haven't restarted yet start failing at step 3.
Minimum dual-active window: Greater than your longest pod startup time plus your deployment rollout window. For most teams, 15–30 minutes.
Common Audit Findings
| Finding | How it happens | Remediation |
|---|---|---|
| Secrets in git history | .env committed before .gitignore was set up |
git filter-repo --path .env --invert-paths; rotate all exposed secrets immediately |
.env baked into Docker image |
COPY . . before RUN in Dockerfile, .env not in .dockerignore |
Add .env* to .dockerignore; rotate; rebuild without layer cache |
| Secrets in CI logs | echo $SECRET in debug step, or a tool that prints env on error |
Mask variables in CI (GitHub: echo "::add-mask::$VALUE"); audit log retention |
| No rotation policy | "We'll do it when something breaks" | Automate rotation via Secrets Manager events or Vault's dynamic secrets |
| Shared credentials | One DB user for all services, or one API key across teams | Per-service credentials; audit trail becomes meaningful only with isolation |
Tool Comparison
| AWS Secrets Manager | HashiCorp Vault | Doppler | 1Password Secrets Automation | |
|---|---|---|---|---|
| Dynamic secrets | No (rotation via Lambda) | Yes — native for Postgres, MySQL, AWS, etc. | No | No |
| Self-hosted | No | Yes (OSS) / No (HCP) | No | No |
| Cost model | $0.40/secret/month + API calls | Free OSS; HCP ~$0.03/hour/cluster | Per-seat SaaS | Per-seat SaaS |
| Best for | AWS-native teams already using IAM | Complex multi-cloud, dynamic secrets, fine-grained policy | Dev teams wanting a simple Heroku-style DX | Teams already on 1Password for password management |
| Secret injection | SDK or sidecar (ASCP) | Agent, sidecar, or vault env |
CLI or native integrations | CLI or SDKs |
Vault's dynamic secrets are the gold standard for database credentials — each application gets its own short-lived credential issued on demand, audited to the service identity.
Ready to try Env Secrets Manager?
Install the skill and start getting expert-level guidance in your workflow — any agent, any IDE.
$skillfish add ~skills/env-secrets-manager