Lab 011 - Docker Security & Trust¶

• This lab covers advanced Docker security features and best practices for container security and privilege management.
• You’ll learn about reducing the attack surface, implementing the Principle of Least Privilege, and using Docker’s security mechanisms to protect your containers.
• Topics include non-root user execution, Linux capabilities, security options, and mandatory access control.
• By the end of this lab, you’ll understand how to build and run secure Docker containers.

Table of Contents¶

• 🛡️ Non-Root User Execution with the USER Instruction
• How to Use USER
• 🔒 Advanced Security Issues and Features
• 1. Privileged Containers (--privileged)
• 2. Linux Capabilities (--cap-drop, --cap-add)
• 3. Preventing Privilege Escalation
• 4. Mandatory Access Control (MAC)
• 5. User Namespace Remapping (UserNS)
• 🔑 Summary of Security Best Practices

• Docker’s advanced features offer critical mechanisms for container security and privilege management, primarily revolving around reducing the attack surface.
• The key is to adhere to the Principle of Least Privilege (PoLP).

🛡️ Non-Root User Execution with the USER Instruction¶

• By default, the process inside a Docker container runs as the root user (UID 0), which is a major security risk.
• If an attacker successfully exploits a vulnerability in the application, they gain root access inside the container.
• Depending on the container’s configuration and any underlying kernel vulnerabilities, this could potentially lead to a container breakout and root access to the host machine.
• The USER instruction in a Dockerfile is essential for mitigating this risk:

How to Use USER¶

1. Create a Non-Root User
2. Use a RUN instruction to create a dedicated user and group before switching the user.

   # Create an unprivileged user (e.g., 'appuser' with UID 1001)
   RUN adduser -D appuser
   
   # Set the ownership of the application directory to the new user
   RUN mkdir /app && chown -R appuser:appuser /app
   
   # Switch to the non-root user for all subsequent instructions and runtime
   USER appuser 
   
   WORKDIR /app
   # ... rest of your application commands (e.g., CMD)
   

Best Practices for Permissions:¶

🔒 Advanced Security Issues and Features¶

• Beyond running as a non-root user, Docker provides several advanced features to lock down container security:

1. Privileged Containers (--privileged)¶

• A privileged container is the most dangerous security configuration and should be avoided at all costs unless absolutely necessary (e.g., for running Docker-in-Docker or a tool that needs to interact directly with the host kernel).

• Security Issue:

  • Running a container with the --privileged flag grants it all Linux Capabilities (see below) and allows it to access all devices on the host. In a privileged container, the root user inside the container is essentially equivalent to the root user on the host machine. A container breakout is almost guaranteed.
  • Mitigation: NEVER use --privileged in production.
    Instead, identify the specific capabilities your application needs and grant only those using the --cap-add flag.

2. Linux Capabilities (--cap-drop, --cap-add)¶

• Linux Capabilities are a finer-grained way to manage root permissions.
• Traditional Unix divides processes into two categories: root (UID 0) and unprivileged.

• Capabilities break down the powers of the root user into discrete units.

• By default, Docker grants a set of “safe” capabilities and drops dangerous ones.

• Best Practice: Use the --cap-drop=ALL flag to remove all capabilities, then use --cap-add to grant only the handful that the application truly requires (PoLP).

  # Runs the container with no capabilities except NET_BIND_SERVICE
  # A container that needs to bind to a low-numbered port (e.g., port 80) 
  # only needs the `NET_BIND_SERVICE` capability.
  docker run --cap-drop=ALL --cap-add=NET_BIND_SERVICE my-image
  

3. Preventing Privilege Escalation¶

• Even if a container starts as non-root, a malicious process could attempt to escalate its privileges.

• no-new-privileges: Use the --security-opt=no-new-privileges flag to prevent a process from gaining new privileges via mechanisms like setuid or setgid binaries. This is a crucial security layer.

4. Mandatory Access Control (MAC)¶

• Docker integrates with two major Linux security modules for deeper kernel-level protection:

5. User Namespace Remapping (UserNS)¶

• This is one of the strongest isolation features for mitigating the risk of a container breakout.

• How it Works: It maps the root user (UID 0) inside the container to an unprivileged user (a high UID, e.g., 100000) on the host machine.

• Security Benefit: If an attacker does manage to escape the container, they only have the privileges of the unprivileged mapped user on the host, not actual root access. This significantly reduces the potential for host compromise. This feature can be enabled at the Docker daemon level.

🔑 Summary of Security Best Practices¶

Running the Demos¶

This lab includes individual demo scripts for each security topic:

To run a demo:

chmod +x demo1-nonroot.sh
./demo1-nonroot.sh

Each demo is self-contained with automatic cleanup.