How to Configure Environment Variables Securely in a Docker Container?

Introduction

Environment variables are commonly used in Docker containers to store configuration values such as database URLs, API keys, and application settings. While they make applications flexible, they can also create security risks if not handled properly.

In simple terms, environment variables should make configuration easier without exposing sensitive data. In this article, you will learn how to configure environment variables securely in a Docker container using easy explanations and real-world examples.

What Are Environment Variables in Docker?

Environment variables are key-value pairs that applications read at runtime. In Docker, you can configure containers without changing application code.

Common uses include:

• Database connection strings

• API keys and tokens

• Application environment settings

Example:

ENV APP_ENV=production

This makes the application aware that it is running in a production environment.

Why Security Matters for Environment Variables

Environment variables often contain sensitive information. If they are exposed, attackers can gain access to databases, APIs, or internal systems.

Common risks include:

• Hardcoding secrets in Dockerfiles

• Committing environment files to source control

• Logging environment variables accidentally

Understanding these risks helps you apply the right security practices.

Avoid Hardcoding Secrets in Dockerfiles

Hardcoding secrets directly in a Dockerfile is a major security risk.

Bad example:

ENV DB_PASSWORD=MySecretPassword

Why this is risky:

• Secrets become part of the image

• Anyone with image access can view them

Instead, secrets should be injected at runtime.

Use Environment Variables at Runtime

The safest basic approach is passing environment variables when running the container.

Example:

docker run -e DB_USER=admin -e DB_PASSWORD=secret myapp

Benefits:

• Secrets are not stored in the image

• Different values can be used per environment

This method is simple and suitable for development or small deployments.

Use .env Files Carefully

Docker supports loading environment variables from a file.

Example:

docker run --env-file .env myapp

Example .env file:

DB_USER=admin
DB_PASSWORD=secret

Security tips:

• Never commit .env files to Git

• Add .env to .gitignore

• Restrict file permissions

This approach improves organization but still requires caution.

Secure Environment Variables with Docker Compose

Docker Compose makes managing environment variables easier and cleaner.

Example:

services:
  app:
    image: myapp
    env_file:
      - .env

You can also define variables directly:

environment:
  APP_ENV: production

Docker Compose helps separate configuration from application logic.

Use Docker Secrets for Sensitive Data

For production systems, Docker Secrets provide a more secure way to handle sensitive data.

Key benefits:

• Secrets are stored securely

• Accessible only by authorized containers

• Not exposed in environment variables by default

Example concept:

• Store secret securely

• Mount it inside the container at runtime

This is the recommended approach for passwords, tokens, and keys in production.

Avoid Logging Environment Variables

Be careful not to log environment variables in application logs.

Bad example:

console.log(process.env);

This can accidentally expose secrets in logs.

Instead:

• Log only required non-sensitive values

• Mask sensitive fields

Use Different Variables for Different Environments

Never reuse the same environment variables across all environments.

Best practice:

• Development: local values

• Testing: test-specific credentials

• Production: restricted access secrets

This reduces the impact of accidental exposure.

Limit Access to Container and Host

Security is not only about configuration but also access control.

Ensure:

• Only trusted users can access Docker hosts

• Images are pulled from trusted sources

• Containers run with least privileges

Even secure variables can be exposed if system access is weak.

Comparison Table: ENV vs .env vs Docker Secrets

The table below shows the differences between common ways of managing environment variables in Docker.

Docker Secrets vs Kubernetes Secrets

Both Docker and Kubernetes provide secret management, but they are used in different environments.

Docker Secrets:

• Designed for Docker Swarm

• Secrets mounted as files

• Limited to Swarm-based setups

Kubernetes Secrets:

• Used in Kubernetes clusters

• Can be mounted as files or env variables

• Integrated with RBAC and namespaces

Example use case:

• Use Docker Secrets for Swarm-based production

• Use Kubernetes Secrets for cloud-native, Kubernetes deployments

CI/CD Pipeline Security Example

In CI/CD pipelines, secrets should never be hardcoded or stored in repositories.

Best practice example:

• Store secrets in CI/CD secret vault

• Inject them during build or deployment

Example flow:

• Pipeline retrieves secret securely

• Secret is passed as environment variable at runtime

• Secret is not stored in image or logs

This ensures secrets are protected throughout the deployment process.

Secret Rotation and Auditing Strategies

Long-lived secrets increase security risks. Rotating and auditing secrets improves safety.

Best practices include:

• Rotate secrets periodically

• Revoke unused credentials

• Track who accessed secrets and when

• Use short-lived tokens where possible

Example:

• Rotate database passwords every few months

• Audit access logs regularly

These practices reduce damage if a secret is compromised.

Common Mistakes to Avoid

Many security issues happen due to simple mistakes:

• Committing .env files to repositories

• Using the same secrets everywhere

• Hardcoding secrets in Docker images

• Printing environment variables in logs

Avoiding these mistakes significantly improves security.

Summary

Configuring environment variables securely in a Docker container requires careful handling of sensitive data. Avoid hardcoding secrets, inject variables at runtime, protect .env files, and use Docker Secrets for production systems. By following these best practices and limiting access to containers, you can keep your Docker-based applications secure while maintaining flexible configuration.