Secret as Volume vs Env Var

Two ways to inject secrets. The trade-offs.

Volume mount

Secret mounting vs environment variables is the choice of how secrets reach pods in Kubernetes. Each approach has trade-offs; the discipline is choosing the right one for the workload.

What volume mounting provides:

• Files in /etc/secret.: The secret is mounted as files in a directory. The application reads the files; the discipline is file-based.
• Updated when secret changes.: When the underlying Kubernetes Secret changes, the mounted files update. The application can re-read; the rotation is non-restart.
• Pod doesn't restart on update.: Unlike env vars, volume mounts can update without pod restart. The discipline supports rotation; the workload's availability is preserved.
• Application must re-read.: The application code must check for file changes. Some applications watch the file; others periodically re-read; the discipline is application-aware.
• Permissions configurable.: The mounted files have permissions. Read-only by default; specific users can be granted access; the discipline is granular.

Volume mounts are the modern approach. Rotation-friendly; the discipline is preferred.

Env var

Environment variables are the legacy approach. They work but have rotation limitations; visibility is broader; the discipline is more constrained.

• Set at start.: Environment variables are set when the pod starts. Subsequent secret changes do not affect the running pod; the value is captured at startup.
• Pod restart needed to update.: Updating the secret requires pod restart to take effect. The discipline includes restarts during rotation; the workload's availability is briefly affected.
• Visible in process listing.: Environment variables can appear in /proc/PID/environ. Other processes on the same machine may be able to read them; the discipline is concerned about this.
• Convenient for many apps.: Many applications use environment variables natively. The configuration is simple; no code changes needed; the discipline matches existing patterns.
• Logs may capture.: Some applications log their environment. Secrets in env vars can leak into logs; the discipline must be careful.

Env vars work but have limitations. The discipline is choosing them only when appropriate.

Decide

The decision depends on the workload. Volume mounts for rotation-friendly applications; env vars for legacy applications without secret management; modern is volume mounts.

• Vol for rotation-friendly.: Applications designed for secret rotation use volume mounts. The discipline supports rotation without restart; the operational story is smoother.
• Env for pre-secret-management apps.: Legacy applications that do not handle file-based secrets use env vars. The discipline is bounded by the application's design.
• Most modern: vol.: Modern applications and frameworks support volume-mounted secrets. The discipline trends toward volume mounts; new applications use this approach.
• Migrate gradually.: Applications using env vars can migrate to volume mounts. The discipline is per-application; the migration accommodates each application's pace.
• Document the choice.: The team's pod specs document which approach each application uses. New maintainers understand; the discipline is preserved.

Secret mounting vs env var is one of those Kubernetes pod-design choices that affects operational characteristics. Nova AI Ops integrates with cluster secret telemetry, surfaces patterns, and supports the team's secret discipline.