Extracting Hidden Environment Variables and API Keys from Docker Containers

Where a container's secrets live

A secret that a running process uses must be readable by that process, and that single fact determines where secrets live in containers. The classic place is the environment: 'docker run -e KEY=...' writes the value into the process's environment block, where it is visible to the process itself, its children, and — on Linux — to anything that can read '/proc/<pid>/environ' for the right pid. The second place is files: secrets mounted as files into '/run/secrets' or a config directory, readable to anyone with the right filesystem view. The third is baked into the image: a value written into a Dockerfile layer survives in the layer history, retrievable long after the running container forgot about it. The fourth is fetched at startup from a metadata service or a broker, then cached in memory or on disk.

Each location has a visibility radius. The environment is visible to the process tree and to same-host observers with sufficient privileges; the filesystem is visible to anything sharing the mount namespace; the image layer is visible to anyone who can pull the image; the broker-fetched secret is visible wherever the client caches it. The unifying theme is that the secret must be present at the point of use, and presence always has a radius.

The modern alternative collapses that radius. Short-lived credentials from a broker, mounted s