# Container Security

In the last few years, the use of container technology has exploded. While Docker (opens new window)
is the most popular containerization technology, various container tools and platforms have emerged to make the process of developing and running containers more efficient

The concepts around containers existed for several years before Docker, but Docker’s easy-to-use command-line tools started to popularize containers among the developer community from its launch in 2013.

From a security perspective, many things are the same in a containerized environment as they are in a traditional deployment. There are attackers out in the world who want to break into applications, steal data, or modify the way a system behaves, or use compute resources to mine cryptocurrencies. This doesn't change when you move to containers.

However, containers do change a lot about the way that applications run, and there are a different set of risks as a result.

# Container Threat Model

Risks vary greatly from one organization to another. For a bank holding money on behalf of customers, the biggest risk is almost certainly that money being stolen. An ecommerce organization will worry about the risks of fraudulent transactions.

Threat modeling is the process of using models (abstracting details) to find security problems. One way to start thinking about the threat model is to consider the actors involved:

External attackers attempting to access a deployment from outside
Internal attackers who have managed to access some part of the deployment
Malicious internal actors such as developers and administrators who have some level of privilege to access the deployment
Application processes that, while not intending to compromise your system, might have programmatic access to the system

By systematically looking at the system’s components and the possible modes of attack, a threat model can help you identify where your system is most vulnerable to attack

# Security Principal

These are general guidelines that are commonly considered to be a wise approach regardless of the details of what you’re trying to secure.

# 1. Least Privilege

The principle of least privilege states that you should limit access to the bare minimum that a person or component needs in order to do their job. You can give different containers different sets of privileges, each minimized to the smallest set of permissions it needs to fulfill its function

# 2. Defense in Depth

The principle of defense in depth tells us that you should apply layers of protection. If an attacker is able to breach one defense, another layer should prevent them from harming your deployment or exfiltrating your data. Containers give another boundary where security protections can be enforced

# 3. Reducing the Attack Surface

Eliminating complexity can make the system harder to attack

# 4. Limiting the Blast Radius

Should the worst happen, the impact should be limited. If a containerized application is compromised, security controls can help constrain the attack within the container and prevent it from affecting the rest of the system

# Security Checklist

This checklist covers some important items you should at least think about when considering how best to secure your container deployments. In your environment it might well not make sense to apply every item, but if you have thought about them, you will be off to a good start.

Are you running all containers as non-root user?
Are you running any containers with the --privileged flag? Are you dropping capabilities that aren't needed for each image?
Are you running containers as read-only where possible?
Are you checking for sensitive directories mounted from the host?
Are you running your CI/CD pipeline in your production cluster? Does it have privileged access or use the Docker socket?
Are you scanning your container images for vulnerabilities?
If your host operating system supports SELinux, is it enabled? Do your applications have the right SELinux profiles attached
What base image are you using? Can you minimize the contents of your images to reduce the attack surface
Are you setting resource limits on your containers?
Do you have admission control to make sure that only approved images can be instantiated in production?
Are you using a runtime protection tool to ensure that only expected executables are running inside containers?