You’ve moved credentials out of container images. Secrets are managed in Kubernetes secrets objects, injected via environment variables or volume mounts. The application accesses them at runtime. This is the standard pattern and it’s better than baking credentials into images.
It’s also not enough if the container image has bash installed.
The Shell-and-Secret Problem
An attacker with code execution inside a container where secrets are mounted has a direct path to those secrets. They run env to see environment variables. They run cat /var/run/secrets/… to read mounted secret files. They use the service account token to make Kubernetes API calls.
None of this requires breaking the secrets management system. The secrets are being protected in transit and at rest. They’re accessed legitimately by the application process. An attacker with the application’s execution context can access them the same way the application does.
The attack doesn’t compromise the secrets storage. It compromises the runtime context where secrets are legitimately present.
Securing how secrets are stored doesn’t help when an attacker can read them directly from the runtime environment.
How Image Hardening Reduces Secrets Exposure Risk?
Removing the extraction tools
Container security through image hardening removes the interactive tools that make secrets extraction convenient. Without bash, there’s no env command to run interactively. Without a scripting language, writing a secrets extraction script requires using whatever interface the application binary exposes.
This doesn’t eliminate secrets exposure risk—the application process itself has access to the secrets and could be exploited to expose them. But it significantly raises the bar for opportunistic attackers who rely on the tools that ship in default container images.
Establishing a secrets access baseline
Runtime profiling captures which processes access which files and environment variables during normal operation. This baseline defines what legitimate secrets access looks like: application process X reads environment variable Y at startup. Any other process accessing that environment variable is behaving anomalously.
With a behavioral baseline, detecting unexpected secrets access becomes tractable. Without one, you’re looking at process trees and environment accesses without context for what’s normal.
Limiting lateral movement after secrets extraction
Container image security that removes network utilities limits what an attacker can do with extracted secrets. A database credential is most dangerous when the attacker can connect to the database directly from within the cluster. Without curl, psql, mysql clients, or other network tools in the container image, exploitation of extracted credentials requires additional tooling that may be detectable.
Practical Steps for Secrets and Image Security Integration
Audit which images have access to secrets and their hardening status. For every Kubernetes secret with mounted volumes or environment variable injection, identify which images receive those secrets. Check the hardening status of those images. Images with secrets access and high CVE counts should be prioritized for hardening.
Remove shell binaries from images that handle sensitive data. If an image processes payment data, personal health information, or authentication credentials, it should not have an interactive shell. The application functionality doesn’t require it. The security risk is concrete.
Use CSI secrets drivers with stricter access controls for highest-sensitivity secrets. CSI-based secrets injection with access logging provides an additional audit trail beyond Kubernetes native secrets. This logging can detect unexpected secrets access that didn’t appear during baseline profiling.
Monitor for environment variable access from unexpected processes. After profiling establishes the baseline for which processes legitimately access which environment variables, alert on deviations. A process accessing a secret environment variable that wasn’t in the baseline is suspicious.
Set short rotation periods for secrets in containers with high CVE counts. If you have images that you can’t immediately harden, mitigate the risk by rotating the secrets they access frequently. A credential that rotates every 24 hours has a narrow exploitation window even if it’s extracted.
Frequently Asked Questions
What are Kubernetes secrets management best practices for protecting credentials at runtime?
The standard pattern is to store credentials as Kubernetes secrets objects and inject them via environment variables or volume mounts rather than baking them into images. However, this approach is insufficient if the container image includes a shell—an attacker with code execution can run env or cat to read the injected secrets directly. Effective secrets management requires both secure storage and image hardening that removes the interactive tools that make secrets extraction convenient.
How does removing shell binaries from container images improve Kubernetes secrets security?
Without bash or other shell interpreters, there is no simple interactive path to extract secrets from the runtime environment. An attacker with code execution must use whatever interface the application binary itself exposes, which significantly raises the bar for opportunistic secrets extraction. For images that handle sensitive data—payment credentials, authentication tokens, health information—removing the shell is a concrete security improvement with no operational downside.
How can a runtime baseline help detect unauthorized secrets access in Kubernetes?
Runtime profiling establishes what legitimate secrets access looks like for each container: which processes access which environment variables, at what point in the application lifecycle. Any process accessing a secret environment variable that wasn’t observed during baseline profiling is behaving anomalously and should trigger an alert. Without a baseline, detecting unexpected secrets access requires manually reviewing process trees and environment accesses without context for what is normal.
How should secrets access and image security requirements be linked in Kubernetes environments?
The most effective model requires images to meet a CVE threshold and be signed by the CI pipeline as a condition of receiving secret injection. This creates a direct accountability link: to get a secret mounted in your pod, your image must be hardened. This approach ties secrets management and image security together in a way that motivates hardening without requiring constant security team intervention, and makes the secure configuration the path of least resistance for development teams.
The Organizational Gap
Secrets management and image security are typically owned by different teams. The security or platform team owns secrets management. Individual application teams own their container images. This creates a gap: secrets are secured, images are not, and nobody has visibility into both dimensions simultaneously.
Closing this gap requires either a shared responsibility model where image hardening is required as a condition of receiving secret injection, or a platform team that owns both the secrets management infrastructure and the image hardening requirement.
The teams that have closed this gap are the ones that tied secrets access to image security requirements. To get a secret mounted in your pod, your image must meet the CVE threshold and be signed by the CI pipeline. This creates a direct accountability link between image security and secrets access that motivates hardening without requiring constant security team intervention.
That’s the goal: make the secure configuration the path of least resistance for development teams, rather than an additional burden they work around.