Kubernetes Secret Management Guide — From Environment Variables to External Secret Stores

Why Secret Management Is Hard

Kubernetes provides a Secret resource, but the real question is:

• where is the secret stored?
• how is it delivered?
• who can access it?
• how is it rotated?

Common operational problems:

• plaintext secrets committed to Git
• no distinction between ConfigMaps and Secrets
• changes not being rolled out safely
• poor environment separation

ConfigMap vs Secret

ConfigMap:

• for non-sensitive configuration
• feature flags, general settings, endpoints

Secret:

• passwords
• API keys
• tokens
• certificates

Also remember that Kubernetes Secrets are base64-encoded objects, not full security systems by themselves.

Common Injection Methods

Environment Variables

Simple but process-visible.

Mounted Files

Better for certificates and structured key material.

External Secret Providers

Often the best long-term operational model.

How to Store Secrets With GitOps

Avoid plaintext in Git.

Common alternatives:

• Sealed Secrets
• SOPS
• External Secrets Operator
• Vault
• AWS Secrets Manager / Parameter Store

Rotation Matters

Secrets are often created once and forgotten.

That is risky for:

• DB credentials
• external API keys
• OAuth secrets
• TLS certificates

Rotation design should consider:

• whether app restart is needed
• connection refresh behavior
• rollout sequencing
• overlap period between old and new values

RBAC Matters Too

Secret access should be constrained carefully:

• namespace boundaries
• narrow service account permissions
• controlled operator access
• CI/CD write scope limits

get secrets is more sensitive than many teams assume.

Closing Thoughts

Kubernetes Secret management is not only about how to inject values. It is about how ownership, storage, rotation, and access are controlled.

That is what turns secrets from YAML objects into a safe operating model.