Docker

Docker Security Best Practices

Docker containers provide a consistent environment for applications, ensuring they run reliably across different computing environments. However, securing Docker containers involves various best practices, whether deploying in AWS, using Elastic Container Registry (ECR), Kubernetes, or working locally with Docker Compose and Dockerfiles. Below are comprehensive security guidelines for different Docker use cases.

General Docker Security

Docker Engine Configuration:

• User Privileges: Avoid running Docker containers as the root user. Use the USER directive in Dockerfiles to specify a non-root user.
• Docker Daemon: Secure the Docker daemon by enabling TLS for communication and ensuring only trusted users can access it.
• Logging: Enable Docker logging driver to capture logs and integrate with centralized logging systems like AWS CloudWatch.

Dockerfile Best Practices

Image Creation:

• Base Images: Use official and minimal base images to reduce the attack surface. Consider using Docker Hardened Images (DHI) for enhanced security with near-zero CVEs, transparent SBOMs, and SLSA Level 3 provenance. Regularly update base images to include security patches.
• Layer Management: Minimize the number of layers in Dockerfiles to reduce image size and potential vulnerabilities.
• Copying Files: Use the COPY instruction instead of ADD unless adding tar files. COPY is more predictable and secure.
• Secrets Management: Avoid hardcoding secrets or credentials in Dockerfiles. Use environment variables or secret management tools.

Dockerfile Example:

FROM ubuntu:20.04  
# Install dependencies 
RUN apt-get update && apt-get install -y \     curl \     vim \     && rm -rf /var/lib/apt/lists/*  
# Create non-root user 
RUN useradd -m appuser USER appuser  
# Copy application files 
COPY --chown=appuser:appuser . /app  
# Set the working directory 
WORKDIR /app  
# Run the application 
CMD ["./myapp"]

Local Development with Docker Compose

docker-compose.yml Best Practices:

• Versioning: Specify the Docker Compose file version to ensure compatibility with the Docker Engine.
• Networking: Use Docker networks to isolate containers and control communication between them.
• Volume Management: Use named volumes to persist data and manage storage securely.
• Environment Variables: Store environment variables in a .env file and avoid committing it to version control.

docker-compose.yml Example:

version: "3.8"

services:
  web:
    image: myapp:latest
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "8080:80"
    environment:
      - APP_ENV=development
    networks:
      - app-network
    volumes:
      - app-data:/var/lib/myapp

  database:
    image: postgres:12
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
    networks:
      - app-network
    volumes:
      - db-data:/var/lib/postgresql/data

networks:
  app-network:
    driver: bridge

volumes:
  app-data:
  db-data:

Deploying Docker on AWS

AWS Elastic Container Registry (ECR):

• Repository Policies: Use ECR repository policies to control access to your container images. Restrict access using IAM roles and policies.
• Scanning for Vulnerabilities: Enable image scanning to detect vulnerabilities in container images stored in ECR.
• Lifecycle Policies: Implement lifecycle policies to manage the lifecycle of images in ECR, removing old and unused images.

Elastic Kubernetes Service (EKS):

• RBAC: Implement Role-Based Access Control (RBAC) to manage permissions for Kubernetes resources.
• Pod Security Policies: Use Pod Security Policies to enforce security standards for pod creation.
• IAM Roles for Service Accounts: Associate IAM roles with Kubernetes service accounts for secure and fine-grained access control.

Fargate and ECS

Task Definition:

• IAM Roles: Assign IAM roles to ECS tasks for secure and limited access to AWS services.
• Network Configuration: Use VPC and security groups to control network access to ECS tasks.
• Secrets Management: Use AWS Secrets Manager or AWS Systems Manager Parameter Store to manage sensitive information securely.

Kubernetes Security Best Practices

Cluster Configuration:

• RBAC: Implement RBAC to manage access to Kubernetes resources based on roles assigned to users and service accounts.
• Network Policies: Use network policies to control traffic between pods and restrict unnecessary communication.
• Secrets Management: Use Kubernetes Secrets to manage sensitive information. Ensure secrets are encrypted at rest.

Pod Security:

• Security Context: Define security contexts in pod specifications to set user privileges, capabilities, and other security settings.
• Read-Only Filesystem: Run containers with a read-only filesystem whenever possible to prevent tampering.
• Resource Limits: Set resource requests and limits to prevent resource exhaustion and ensure fair resource allocation.

Additional Security Measures

Image Management:

• Image Scanning: Regularly scan images for vulnerabilities using tools like Clair, Anchore, or AWS ECR image scanning.
• Signature Verification: Verify the integrity and authenticity of images using Docker Content Trust (DCT) and signed images.

Runtime Security:

• Container Runtime Security: Use runtime security tools like Falco or Aqua Security to monitor container activities and detect suspicious behavior.
• Immutable Infrastructure: Treat containers as immutable and replace them with new versions rather than modifying them in place.

By adhering to these best practices, you can enhance the security of Docker containers across various environments, ensuring robust protection for your applications and data.

Docker Hardened Images (DHI)

Docker Hardened Images provide a secure, enterprise-ready foundation for containerized applications. These images are now free and open source under Apache 2.0 license, making secure base images accessible to all developers.

Key Features

Security & Transparency:

• Near-zero CVEs: Minimal, hardened images with significantly reduced vulnerability surface
• Multi-distro compatibility: Available for Alpine and Debian distributions
• Transparent SBOMs: Signed Software Bill of Materials (SBOMs) for complete visibility
• SLSA Level 3 Provenance: Verifiable build provenance you can trust
• Full CVE visibility: Complete, unsuppressed CVE data (no hidden vulnerabilities)

Developer Experience:

• Drop-in adoption: Swap your base image with minimal workflow changes
• Open source: Apache 2.0 license - migrate to and from freely
• 1000+ images available: Extensive catalog covering popular technologies (Python, Node.js, PostgreSQL, Neo4j, Helm, .NET, and more)

DHI Tiers

DHI (Free)

• Hardened, minimal images
• Near-zero CVEs
• Verifiable SBOMs & SLSA Level 3 provenance
• Full, unsuppressed CVE visibility
• Drop-in adoption, no workflow changes
• Open source under Apache 2.0

DHI Enterprise

Includes everything in DHI, plus:

• Critical CVE fixes <7 days: SLA-backed rapid remediation
• FIPS/STIG variants: Compliance-ready images for regulated environments
• Image lifecycle management: Secure customization without breaking provenance
• Built on Docker's secure build system: Enterprise-grade build infrastructure

DHI ELS (Extended Lifecycle Support)

Requires Enterprise subscription:

• +5 years of hardened updates: Security patches beyond upstream EOL
• Updated SBOMs & provenance: Maintained documentation for long-lived workloads
• Maintains compliance post-EOL: Protection for legacy applications
• Protects long-lived workloads: Extended security for applications that can't migrate immediately

Benefits

Supply Chain Security:

• Minimal attack surface with hardened, non-root images by default
• Event-driven build system keeps images continuously updated
• Secure customization allows tailoring without breaking provenance
• When upstream stops, your protection continues (with ELS)

Operational Advantages:

• Reduced security toil: Less time spent on base image vulnerabilities
• Transparent security model: Know exactly what's in your images
• Easy migration: Drop-in replacement for existing base images
• No vendor lock-in: Apache 2.0 license ensures freedom

Usage

Docker Hardened Images are designed as drop-in replacements for standard base images. Simply update your Dockerfile:

# Before
FROM python:3.11

# After - using Docker Hardened Image
FROM docker.io/docker/dhi-python:3.11

Migration:

• Minimal code changes required
• Browse 1000+ available images in the Docker Hub catalog
• Documentation and migration guides available
• GitHub discussions for community support

Comparison with Alternatives

When to Use Docker Hardened Images

• Starting new projects: Begin with a secure foundation from day one
• Migrating existing applications: Drop-in replacement for improved security posture
• Regulated environments: FIPS/STIG variants for compliance requirements
• Long-lived applications: ELS support for applications that can't migrate immediately
• Supply chain security: Organizations prioritizing software supply chain security

Resources:

• Docker Hardened Images Documentation
• Browse 1000+ images in Docker Hub
• Migration guides and GitHub discussions available

--privileged flag

do not use the **--privileged** flag or mount a Docker socket inside the container. The docker socket allows for spawning containers, so it is an easy way to take full control of the host, for example, by running another container with the --privileged flag.