How do I secure secrets and environment variables in deployment?

Securing secrets and environment variables in deployment comes down to one main rule:

Do not treat secrets like configuration files or code.
Store them separately, restrict access tightly, rotate them regularly, and inject them only at runtime.

Best practices

1) Never hardcode secrets

Avoid putting passwords, API keys, private keys, or tokens in:

• source code
• Docker images
• build scripts
• config files committed to git
• environment files checked into repositories

Even private repositories leak eventually.

2) Use a secrets manager

Prefer dedicated secret storage over plain environment variables for sensitive values:

• HashiCorp Vault
• AWS Secrets Manager / SSM Parameter Store
• Azure Key Vault
• Google Secret Manager
• Kubernetes Secrets plus encryption-at-rest and access controls

These provide:

• access control
• auditing
• rotation
• encryption
• versioning

3) Inject secrets at runtime

Secrets should be loaded only when the app starts or when needed:

• environment variables from the platform
• mounted files from secret volumes
• sidecar/agent that fetches secrets on demand

Avoid baking secrets into images or artifacts.

4) Limit access with least privilege

Only the app/service that needs a secret should be able to read it. Use:

• IAM roles / workload identity
• service accounts
• RBAC
• scoped tokens with short lifetimes

Do not give broad access to all environments or team members.

5) Rotate secrets regularly

Use short-lived credentials where possible:

• temporary cloud credentials
• expiring tokens
• dynamic database credentials

Rotate:

• API keys
• DB passwords
• TLS certs
• signing keys

Also plan for emergency revocation if a secret leaks.

6) Separate secrets by environment

Use different secrets for:

• development
• staging
• production

Never reuse production credentials in lower environments.

7) Protect environment variables

Environment variables are convenient, but they are not secure storage by themselves. Risks:

• can be exposed in process listings, crash dumps, logs, or debug tools
• may be inherited by child processes
• can leak through misconfigured telemetry

Use them for injection, not as the secret source of truth.

8) Secure CI/CD pipelines

CI/CD is a common leakage point.

• store secrets in the CI platform’s secret store
• avoid printing them in logs
• mask sensitive values
• use short-lived deploy tokens
• restrict who can edit pipeline definitions
• scan build logs and artifacts for leaks

9) Encrypt at rest and in transit

Ensure:

• secrets are encrypted in storage
• connections to secret stores use TLS
• backups containing secrets are encrypted
• exported configs are protected

10) Audit and monitor access

Track:

• who accessed which secret
• when it was accessed
• from where
• whether access failed unexpectedly

Alert on:

• unusual access patterns
• mass secret reads
• access from new regions or identities

Common deployment patterns

Cloud-native apps

• Store secrets in cloud secret manager
• App uses identity-based auth to retrieve them at startup
• Cache in memory only if necessary

Kubernetes

• Prefer external secret managers integrated via CSI drivers or operators
• If using Kubernetes Secrets:
  • enable encryption at rest
  • restrict RBAC
  • avoid exposing them in logs
  • mount as files when possible
• Consider external secret injection tools

Docker / containers

• Pass secrets at runtime, not build time
• Avoid ENV for sensitive values in Dockerfiles
• Use orchestration platform secret mechanisms
• Never commit .env with real values

Serverless

• Use platform secret stores or parameter stores
• Inject at invocation/runtime
• Restrict function permissions to only required secrets

Things to avoid

• committing .env files with real secrets
• putting secrets in Dockerfiles
• storing secrets in plain text config maps
• logging environment variables
• embedding secrets in frontend code
• sharing one shared secret across all services
• long-lived static credentials when dynamic ones are possible

Good practical rule

If a value is:

• sensitive,
• long-lived,
• rotated manually,
• or needs auditability,

then it should live in a secret manager, not in plain environment variables.

If you want, I can also give you:

1. a Kubernetes-specific setup,
2. an AWS/GCP/Azure example, or
3. a CI/CD pipeline checklist.