Why do environment variables create risk in containerised runtimes?

Why This Matters for Security Teams

Environment variables are attractive because they are simple to inject into containers, but that simplicity creates a wider exposure surface than many teams expect. Once a secret is placed in an env var, it can be read through process inspection, inherited by child processes, and accidentally captured in diagnostics, crash dumps, or build output. That means the credential is no longer limited to the workload that needs it.

For containerised runtimes, this matters because the runtime boundary is often assumed to be stronger than it really is. A compromised sidecar, debug shell, or misconfigured observability tool can reveal secrets that were only meant for the application container. NHI Management Group has documented how exposed identity material is routinely abused in the wild, including the LLMjacking pattern and broader exposure trends in the 2024 ESG Report: Managing Non-Human Identities.

Current guidance from NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls consistently points toward limiting secret exposure paths, not just protecting the container image or host. In practice, many security teams encounter credential leakage only after a runtime inspection, support session, or incident response event has already exposed the environment.

How It Works in Practice

In containers, environment variables are typically set at launch time by the orchestrator, entrypoint script, or deployment pipeline. They are then copied into the process environment of the main application and often into any child process it spawns. That makes them convenient for non-sensitive configuration, but poor for secrets because the secret lives in a place designed for process state, not secrecy.

Safer patterns reduce how many components can see the credential. File-mounted secrets, orchestration-native secret objects, and short-lived tokens all narrow exposure compared with env vars. In Kubernetes and similar platforms, the main goal is to keep the secret out of command history, image layers, and broad process visibility. For that reason, many teams now prefer runtime-mounted secret files or external secret delivery tied to workload identity rather than static environment injection. NHI Management Group’s Top 10 NHI Issues and Ultimate Guide to NHIs — Key Challenges and Risks both reflect this broader control problem: credentials should be delivered in the narrowest possible scope and for the shortest possible time.

• Use env vars only for low-risk configuration, not secrets.
• Prefer file-mounted secrets with restricted filesystem permissions.
• Issue short-lived credentials that can be rotated or revoked quickly.
• Block debug tooling and shell access in production where feasible.
• Review logging, crash reporting, and exec permissions for accidental disclosure paths.

These controls tend to break down in heavily shared clusters with broad exec access, aggressive observability tooling, or applications that dump full process state during failure handling.

Common Variations and Edge Cases

Tighter secret handling often increases operational overhead, requiring organisations to balance leak reduction against deployment complexity and developer convenience. That tradeoff becomes most visible when legacy applications assume all configuration arrives through environment variables.

Best practice is evolving, but current guidance suggests treating env vars as acceptable for non-sensitive settings and avoiding them for credentials whenever the runtime supports better options. In some platforms, secret files can still be exposed through careless volume permissions, and orchestration-native secret stores only help if access is tied to the right workload identity and rotation process. The 230 million AWS environment compromise and Massive Docker Hub Secrets Leak are reminders that credential exposure is rarely a single failure point; it is usually a chain of convenience choices.

Secrets are especially risky when containers are built for portability across dev, test, and prod, because the same injection pattern is often reused everywhere. A value that looks harmless in local testing can become a production incident if copied into a pod spec, CI job, or sidecar configuration. The practical rule is simple: if the value would be damaging when disclosed, it should not be delivered as a broadly inspectable environment variable.

Related resources from NHI Mgmt Group

• Why do CI/CD environment variables create identity risk?
• Why do ephemeral credentials still leave risk in machine access models?
• Why do AI agent runtimes create more governance risk than ordinary service accounts?
• Why do environment files create governance risk in developer tooling?