Docker Secrets vs Environment Variables for Sensitive Config

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

Never embed secrets in images. Environment variables are the standard approach but are visible in docker inspect and process listings. Docker Secrets (Swarm) or Kubernetes Secrets mount secrets as files into the container. For production, use a secrets manager (HashiCorp Vault, AWS Secrets Manager) with Spring Cloud Vault or AWS SDK for zero-knowledge secret injection.

Interview Answer3 min

Environment variables and Docker secrets both inject configuration into containers, but they solve different problems. Environment variables are for non-sensitive configuration; secrets are for credentials, API keys, and anything that should not appear in docker inspect.

Why environment variables are not safe for secrets

Environment variables are visible in docker inspect , in process listings like /proc/1/environ, in CI logs if printed, and in any crash dump — they are not encrypted at rest or in transit
Container orchestrators (Kubernetes, Swarm) expose environment variables through their APIs; a misconfigured RBAC policy that allows get pods can return the full environment variable list including embedded secrets
The correct mental model: environment variables are for configuration that you would not mind seeing in a debug log; secrets are for anything you would rotate if it appeared in a log

Docker secrets — how they work

Docker Swarm secrets mount as files in /run/secrets/ inside the container — the application reads the file, not an environment variable; the secret value never appears in the process environment or docker inspect output
Spring Boot reads secret files with spring.config.import=optional:configtree:/run/secrets/ — each file in the directory becomes a property, so spring.datasource.password in a Spring config maps to the file at /run/secrets/spring.datasource.password
Secrets are encrypted at rest in Swarm's Raft log and transmitted encrypted to the container — the only plaintext exposure is the in-memory mount inside the container's filesystem namespace

Production secret management

In Kubernetes, use external secret operators (External Secrets Operator, Sealed Secrets, AWS Secrets Manager) to inject secrets from a central secret store — Kubernetes Secrets are only base64-encoded by default, not encrypted; the external operator adds real encryption and audit trails
In AWS ECS, use Task IAM roles to fetch from Secrets Manager or Parameter Store at container startup — no secrets embedded in the task definition or container image
Never put secrets in Dockerfiles, Docker Compose files, or .env files committed to version control — .env must be in .gitignore the moment the project is created

Interview-ready guide

Interview answer

Why environment variables are not safe for secrets

Environment variables are visible in docker inspect , in process listings like /proc/1/environ, in CI logs if printed, and in any crash dump — they are not encrypted at rest or in transit
Container orchestrators (Kubernetes, Swarm) expose environment variables through their APIs; a misconfigured RBAC policy that allows get pods can return the full environment variable list including embedded secrets
The correct mental model: environment variables are for configuration that you would not mind seeing in a debug log; secrets are for anything you would rotate if it appeared in a log

Docker secrets — how they work

Docker Swarm secrets mount as files in /run/secrets/ inside the container — the application reads the file, not an environment variable; the secret value never appears in the process environment or docker inspect output
Spring Boot reads secret files with spring.config.import=optional:configtree:/run/secrets/ — each file in the directory becomes a property, so spring.datasource.password in a Spring config maps to the file at /run/secrets/spring.datasource.password
Secrets are encrypted at rest in Swarm's Raft log and transmitted encrypted to the container — the only plaintext exposure is the in-memory mount inside the container's filesystem namespace

Production secret management

In Kubernetes, use external secret operators (External Secrets Operator, Sealed Secrets, AWS Secrets Manager) to inject secrets from a central secret store — Kubernetes Secrets are only base64-encoded by default, not encrypted; the external operator adds real encryption and audit trails
In AWS ECS, use Task IAM roles to fetch from Secrets Manager or Parameter Store at container startup — no secrets embedded in the task definition or container image
Never put secrets in Dockerfiles, Docker Compose files, or .env files committed to version control — .env must be in .gitignore the moment the project is created

03 · Deep dive