The new engineer joins the team. Onboarding instructions: “ask Slack for the .env file.” A senior engineer DMs them a 4 KB file with database passwords, API keys, and the Stripe live secret. They paste it into 1Password “for safekeeping.” Six months later the engineer has left, the file is still in their personal vault, and nobody knows where else copies of those secrets live.
This is how every team’s secrets management starts and how most stay. The fix is not “be more careful.” It is to put secrets in a system where the answer to “who has access” is auditable, and where rotation is a button-press, not a Slack thread.
This post covers the three credible options for production secrets: HashiCorp Vault, SOPS-encrypted-in-git, and cloud-native (AWS/GCP/Azure), with the trade-offs and the rotation policy that holds up.
Five operations that any system worth using must support:
A .env file in a chat tool fails 3, 4, and 5. A “secrets manager” that requires a redeploy to rotate fails 4. A system without per-secret ACLs fails 5.
The three options below all support these operations to different degrees.
Vault is the heaviest, most flexible option. Run it as a service. Apps authenticate to Vault and request secrets at runtime.
# App authenticates with a Kubernetes service account.
$ vault read database/creds/app-readonly
Key Value
--- -----
lease_id database/creds/app-readonly/abc123
lease_duration 1h
lease_renewable true
password A1b-2C3d-...
username v-token-app-...-abcStrengths:
Costs:
Vault is the right answer for organizations large enough to have a dedicated security or platform team. It is overkill for a 5-engineer startup.
SOPS (Secrets OPerationS) encrypts the values of a YAML or JSON file using a KMS key, leaving the keys in plaintext. The encrypted file lives in Git like any other config:
# secrets.enc.yaml
database:
host: db.example.com
password: ENC[AES256_GCM,data:abc123,iv:...,tag:...,type:str]
stripe:
api_key: ENC[AES256_GCM,data:def456,...,type:str]
sops:
kms:
- arn: arn:aws:kms:us-east-1:...:key/abc-123Anyone with access to the KMS key can decrypt; the file is otherwise gibberish. Use AWS KMS, GCP KMS, Azure Key Vault, or age for a key-pair-based approach.
Strengths:
Costs:
For most teams under ~50 engineers, SOPS hits the sweet spot. The “secrets are in Git” psychology takes getting used to but the encryption is genuinely strong.
Each cloud has a managed secrets service. They look similar:
aws secretsmanager get-secret-value --secret-id prod/db/passwordStrengths:
Costs:
For teams already deep in one cloud, the cloud-native option is usually the lowest-effort credible answer.
A realistic flowchart:
Most teams start with #3 (SOPS) and migrate to #2 or #1 when scale demands it. Migration is real work; pick something you can live with for a couple of years.
Whatever tool you pick, you need a rotation policy. The realistic version:
The frequency matters less than the practice of rotating. A team that has rotated zero secrets in two years has secrets they cannot rotate (because they don’t remember which apps use them).
The “engineer leaves” checklist is the test of your secrets management. The right answer is:
If step 2 is “ask around what they had access to,” you have a problem. The secrets-management system should answer “what could this user have read in the last 90 days?” from audit logs.
A few patterns that look like secrets but aren’t:
The secrets manager is for things that are sensitive and long-lived. Anything else belongs elsewhere.
Storing secrets in environment variables in CI logs. A set -x in a shell script and you’ve leaked. Use the CI’s secret-injection mechanism (GitHub Actions secrets, GitLab masked variables) and never echo them.
Embedding secrets in container images. Multi-stage builds have helped, but a RUN apt-get && SECRET=abc... baked into a layer means anyone with the image has the secret. Use build secrets (docker build --secret) or runtime injection.
Single shared key for everything. “Master API key” with full access to everything. Should be split: read-only for analytics, write for billing, etc.
No backup of root keys. If you lose your KMS key or Vault root token, secrets become unrecoverable. Have an offline backup with a clearly-documented recovery procedure.
A .env file in 1Password is a starting point, not a destination. Pick a real secrets management system (Vault, SOPS-in-Git, cloud-native) before you have to. Establish a rotation rhythm. Make “who can read this secret” a query, not a Slack thread.
The next time an engineer leaves, the response should be one button-press, not a six-hour audit. The next time you need to rotate a database password, it should be a Friday afternoon, not a sprint.
The kind of security hygiene that turns “we know who has access to what” from a wish into a query (secrets management, rotation, audit logs) is the kind of long-haul engineering discipline Yojji’s teams put into the products they hand back to clients.
Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They specialize in the JavaScript ecosystem, cloud platforms (AWS, Azure, GCP), and full-cycle product engineering, including the security and operations work that decides whether your secrets are auditable or scattered across team chats.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。