Defense in Depth

In cybersecurity, defense in depth is a strategy that employs multiple layers of security controls throughout an IT system. This approach ensures that if one layer is compromised, additional layers continue to provide protection. Just like Gord's castle uses multiple layers of security: the dungeons, the guards, and the remote location of the castle.

In container security, defense in depth can be implemented by combining various security measures, such as:

• Put sensitive workloads in rootless containers to isolate them from the host system,
• Run those containers inside VMs for an additional layer of isolation,
• Use network policies to restrict communication between containers,
• Implement RBAC to control access to resources,
• And monitor container activity for suspicious behavior.

OWASP Secure Product Design Principles

The OWASP Secure Product Design Principles provide a framework for building secure software products. The principles include:

1. The principle of Least Privilege and Separation of Duties.
2. The principle of Defense-in-Depth.
3. The principle of Zero Trust.
4. The principle of Security-in-the-Open.

Implementing Defense in Depth in Container Security

Here is a checklist for your first step toward defense in depth for your containerized applications:

1. Use multi-stage builds to separate the build environment from the runtime environment, keeping the build tools and dependencies out of the final image.
2. Use hardened base images that have almost no security vulnerabilities. For example, you can use Docker Hardened Images (DHI) that are maintained by Docker and follow security best practices. Instead of using FROM node:24, you can use FROM dhi.io/node:24 for your production stage, and FROM dhi.io/node:24-dev for your build stage.
3. Run containers with non-root users to minimize the impact of potential breaches. In a non-root container, even if an attacker manages to compromise the application, they won't have root privileges to access the host system or other containers.
4. Use distroless images that don't have shells or package managers. So, attackers won't be able to install additional tools or dependencies inside the container if they manage to get in. DHI are examples of distroless images.
5. Create SBOM attestations for your images. They are SBOMs generated upon build and attached to the image as metadata.
6. Check your image for vulnerabilities.
7. Add CI/CD checks to ensure you didn't add new vulnerabilities to your images.
8. Use runtime security tools to monitor your containers for suspicious behavior and detect potential breaches.
9. Use network policies to restrict communication between containers and limit the attack surface. This includes blocking unnecessary ports, restricting outbound traffic, and segmenting your network to prevent lateral movement in case of a breach.
10. Use monitoring and logging to detect and respond to security incidents. In many cases, one might be hacked but not notice it for a long time. With proper monitoring and logging, you can detect suspicious activity early and take action to mitigate the damage.

If three or more of these layers are missing, you might want to consider reading Docker and Kubernetes Security.

Exercise

1. Identify the layers of security in your current containerized applications. Do they mimic a medieval fortress?