Runtime Container Security

Welcome to Runtime Container Security! Building secure images is crucial, but what happens once your container is running?

This lesson focuses on best practices to protect your applications while they are active, limiting potential damage from vulnerabilities or attacks.

A fundamental security concept is the Principle of Least Privilege. It means giving an entity (like a container or user) only the permissions absolutely necessary to perform its function, and no more.

Applying this reduces the attack surface and limits the impact if a container is compromised.

By default, processes inside a Docker container run as the root user, which has full administrative privileges within the container.

• Risk: If an attacker gains control of a root-privileged container, they could potentially exploit vulnerabilities in the Docker daemon or kernel to gain root access on the host system.
• Best Practice: Always run your container processes as a non-root user.

You can specify a user (by name or UID) for your container process using the --user flag with docker run. Here, we run the id command in an Alpine container as user 1000.

If user 1000 doesn't exist, Docker will still use that UID.

Traditional Linux systems have an 'all or nothing' root user. Linux Capabilities break down the powerful root privileges into smaller, distinct units.

This allows a process to have only the specific root-like powers it needs (e.g., binding to low ports, raw network access) without having full root.

Docker containers by default run with a large set of capabilities. You can drop unnecessary capabilities using --cap-drop to further restrict what a container can do.

Here, we drop the NET_RAW capability. The ping command, which requires NET_RAW, will then fail, demonstrating the restriction.

Containers share the host's kernel and resources. Uncontrolled resource usage by one container can lead to a Denial of Service (DoS) for other containers or even the host itself.

• CPU Limits: Prevent a container from monopolizing CPU cycles.
• Memory Limits: Stop a container from consuming all available RAM, preventing system instability.

You can set limits on CPU and memory directly with docker run. This example limits memory to 128MB and CPU usage to 0.5 (half of one CPU core).

This ensures your container behaves well and doesn't starve other processes.

Many applications don't need to write to their root filesystem after startup. By making the filesystem read-only, you gain significant security benefits:

• Prevents Tampering: An attacker cannot modify existing files or write new malicious files.
• Limits Persistence: Any changes made are ephemeral and lost upon container restart.
• Enforces Immutability: Promotes a design where containers are disposable and configuration is external.

Use the --read-only flag when running a container. Any attempt to write to the container's filesystem (outside of explicitly mounted volumes) will fail.

Try creating a file in this read-only container:

Which of the following are good practices for securing containers at runtime?

Great job! You've learned how to enhance container security while they are running:

• Least Privilege: Grant only necessary permissions.
• Non-Root Users: Avoid running processes as root.
• Capabilities: Drop unneeded Linux capabilities.
• Resource Limits: Control CPU and memory usage.
• Read-Only: Make filesystems immutable to prevent writes.

These practices significantly reduce the attack surface and impact of potential compromises. Keep practicing!