Docker Container Security Cheatsheet: Don’t Get Hacked🔐

Estimated reading time: 7 minutes

Last updated on November 8th, 2024 at 04:46 pm

Containerization has changed how we deploy and manage applications. Containers provide an abstraction, allowing applications to operate independently of their environment.

However, this doesn’t make them resilient to security threats. As we use containerized environments for almost every workload, focusing on “Docker Container Security” is essential.

This blog explores Container Security, with different types of attack surfaces and actions that make your deployments more secure.

What is Container Security?

Container security means protecting containerized applications and their infrastructure throughout their lifecycle, from development to deployment and runtime.

Involves proactive vulnerability scanning, least privilege congratulation management, role-based access controls (RBAC), and network segmentation between critical applications.

docker container security surface
Docker Container Security Threat Model – Figure by Container Security by Liz Rice

Container Security Cheatsheet:

#1. Keep Host and Docker up to date

Keeping both the host and Docker up to date protects against  Leaky Vessels – container escape vulnerabilities that lead to gaining root access to the host system.

Containers are virtualization environment that runs on the host’s kernel. Since the container shares the host’s kernel, an exploit that runs inside the isolated container can still provide access to the host system.

Always keep your host and Docker up to date including the kernel.

#2. Avoid exposing the Docker Socket

Docker follows the client-server architecture that communicates with the UNIX socket located at:

Bash
/var/run/docker.sock

Since this is the primary point for Docker API this is owned by the root user.

Sharing the Docker socket inside the container means you also provide the root access to your host system.

Do not expose the TCP Socket

By default, Docker talks with the API using the UNIX socket but if you run the docker daemon with the TCP option:

Bash
-H tcp://0.0.0.0:8080

This provides unencrypted and unauthenticated direct access to the Docker daemon by default.

If you need to expose it for remote access I strongly advise using a built-in HTTPS encrypted socket or using a secure reverse proxy in front.

Avoid UNIX Socket with Volume Mount

Mounting the Docker daemon socket via volume mount should be avoided. Mounting as read-only only makes it harder to exploit not impossible.

YAML
volumes:
    - "/var/run/docker.sock:/var/run/docker.sock"

Check out this: Docker Socket Proxy- a security-enhanced proxy for the Docker Socket

Podman Cheat Sheet

FREE EBook – Docker Defence ​Unbeatable Security

Are you leveraging Docker’s potential, but worried about security vulnerabilities? Our ebook, “Docker Defence: Unbeatable Security“, is your key to mastering container security. Packed with actionable checklists and expert tips, you’ll discover:

Don’t wait! Download your free copy and unlock the full potential of Docker!

#3. Run as an Unprivileged User

To prevent privilege escalation attacks, configure and run the container to use unprivileged users.

#1. When you’re building a Docker image, add a user in the Dockerfile

Dockerfile
FROM alpine:3.14
RUN groupadd -r testuser && useradd -r -g testuser testuser

USER testuser

#2. When running the Docker container use -u the option:

Bash
docker run -u 1000 alpine:3.14

#4. No New Privileges Escalation

Having the setuid and setgid binaries inside the container can lead to privilege escalation.

Linux kernel has a mechanism called “no-new-privileges” that prevents the child process from acquiring new privileges.

Bash
docker run --security-opt=no-new-privileges alpine:3.14

Always run the Docker container with --security-opt=no-new-privileges

#5. Use AppArmor, SELinux, and seccomp Security Modules

Seccomp: Limits what actions a container can do for better security.

AppArmor: Controls and restricts what specific applications in Docker can do.

SELinux (Security-Enhanced Linux): Manages and enforces detailed security rules for Docker containers.

Use Linux security profile seccomp or AppArmor

#6. Resource Limitation

Limit Resources: Restrict Memory and CPU usage in Docker.

Restart Control: Set a maximum number of container restarts using

Bash
--restart=on-failure

File Descriptor Limit: Cap the maximum number of file descriptors.

Bash
--ulimit nofile=100

Process Limit: Restrict the maximum number of processes.

Bash
--ulimit nproc=10
Podman Cheat Sheet

FREE EBook – Docker Defence ​Unbeatable Security

Are you leveraging Docker’s potential, but worried about security vulnerabilities? Our ebook, “Docker Defence: Unbeatable Security“, is your key to mastering container security. Packed with actionable checklists and expert tips, you’ll discover:

Don’t wait! Download your free copy and unlock the full potential of Docker!

#7. Docker Secret for Sensitive Data

You can use Docker Secrets to manage sensitive data so you don’t have to define it in the image or your code repository.

  • Username and passwords
  • SSH keys
  • TLS certificates and Private keys
  • Application credentials or Encryption keys

Avoid strong the sensitive data in container images or runtime commands instead use Docker Secret:

Let’s create the Docker Secret

Bash
printf "Super Secret" | docker secret create test_secret -

Use it to create a Docker Service

Bash
docker service  create --name nginx --secret test_secret nginx:alpine

Use it in Docker Compose

YAML
version: "3.8"
  secrets:
    test_secret:
      file: ./test-secret-data.txt 
  services:
    web:
      image: nginx:alpine
      secrets:
        - test_secret

#8. Container Network Segmentation

By default Docker allows all network traffic between containers to communicate with each other using the docker0 bridged network called Inter-Continaer Connectivity (icc).

This means each container can read all the packages across the container network on the same host.

You can restrict all Inter-Continer communication and only allow link-specific containers to communicate. Creating the custom Docker network and attaching only specific containers enables granular control.

Run the Docker daemon by passing --icc=false as an argument:

Bash
dockerd --icc=false 

For more details on the Docker network for container security and segmentation check the Official Docker Documentation.

#9. Integrate Container Scanning in CI/CD Pipeline

CI/CD pipeline important part of the Software development lifecycle. You should include various security mechanisms such as static code analysis and container vulnerability scanning.

The container vulnerability scanner detects the known vulnerabilities, secrets inside the image, and misconfiguration and provides the recommended best practices.

Check the below tools, including free, open-source, and paid options for selecting a tool depending on your needs and level of security.

Free Container Vulnerability Scanning Tools:

  1. Docker Hub Vulnerability Scanning (Free)
  2. Aqua Security Trivy (Free, Open-Source)
  3. Clair (Free, Open-Source)
  4. Grype (Free, Open-Source)
  5. ThreatMapper (Free, Open-Source)
  1. Snyk Container (Paid, Free Option Available)
  2. Qualys Container Security (Paid, Free Option Available)
  3. Docker Scout (Paid, Free Option Available)

Container Secret Detection Tools:

  1. SecretScanner (Free, Open-Source)
  2. GitGurdian ggshield (Free Option Available)

Container Security Audit Tools:

  1. Docker Bench for Security
  2. DevSec – Docker Benchmark Profile
  3. Inspec.io Docker Resource

#10. Run Docker: Rootless

Running Docker daemon in Rootless mode allows running the container as an unprivileged user or non-root user. This ensures that even if attackers exploit and try to escape the container, they will not have root access to the host system.

The rootless mode may not be suitable for all the requirements so check the known limitations of the rootless mode.

If security is your top priority this is the most recommended setting. You can also check using Podman alternative to Docker.

Podman is an open-source and daemonless engine for managing and running containers using the Open Container Initiative ( OCI ) developed by Red Hat

Podman is designed to be lightweight and secure. Podman provides Daemonless Architecture opposite to Docker Deamon which enables to use fork-exec model that allows running containers without root privileges.

Podman provides an identical CLI that works with Docker out of the box without extra configuration.

Read more on How to Use Docker Compose with Podman

Podman Cheat Sheet

FREE EBook – Docker Defence ​Unbeatable Security

Are you leveraging Docker’s potential, but worried about security vulnerabilities? Our ebook, “Docker Defence: Unbeatable Security“, is your key to mastering container security. Packed with actionable checklists and expert tips, you’ll discover:

Don’t wait! Download your free copy and unlock the full potential of Docker!

Key Takeaways

Container security is important for protecting your application and data. Following the simple yet effective best practices, you can improve the security of your Docker containers.

  1. Prioritize Regular Updates: Regularly update the Host system and Docker to apply the latest security patches.
  2. Strict Access Control: Avoid exposing Docker Socket, run as an unprivileged user, and enforce the security. Use Docker secrets for sensitive data and implement network policy for network segments.
  3. Continuous Monitoring: Integrate vulnerability scanning, secret detection, and audit tools in the CI/CD pipeline. Detect early and fix it before it’s late.

Kashyap Merai

Kashyap Merai

Kashyap Merai, a Certified Solution Architect and Public Cloud Specialist with over 7 years in IT. He helped startups in Real Estate, Media Streaming, and On-Demand industries launch successful public cloud projects.

Passionate about Space, Science, and Computers, He also mentors aspiring cloud engineers, shaping the industry's future.

Connect with him on LinkedIn to stay updated on cloud innovations.