A sleeping security threat: How to protect against container compromise
- Unsecured Access to the Docker API
Users added to the “docker” group can use all Docker functions that utilize images and containers. They automatically gain access to every single command: read, write and destroy.
To mitigate risk, do not add all accounts to the “docker” group. Instead, enforce least privilege policies to limit commands that can be sent by a user. For example, don’t allow a low-privileged user to spin privileged containers, because abusing the privileged container may lead to an escape to the host.
- Passing Secrets from Host to Container Using Environment Variables at Run Time
Secrets can be passed through to the Docker container at run time using the “-e” flag. These secrets have to be passed through in clear text. Any automation scripts will have to define these variables. As part of this, any user with access to the Docker API will be able to grab the secret information. It’s essential to limit commands available to the user and secure host access by monitoring privileged user sessions.
- Running Containers with the Privileged Flag
Running containers with the “--privileged” flag provides the container with direct access to host elements such as devices and other pieces of hardware. Mapping containers may provide operational benefits, but it also breaks one of the isolation pieces between the running process and the container, which has a lot of security applications.
If an attacker is able to gain access to a container – and if the container has access to the host machine – they can directly interact with everything on the host and potentially break out of the container altogether.
To minimize the risk of data breaches and outages associated with uncontrolled access, it’s important to enforce least privilege policies across your Docker hosts.
- Running Containers as Root
The default setting in Docker is to run containers as root. By not declaring a user for each container or using the “--user” flag, container users have access to the same GUID and UID as the host machine – even if the passwords are different. This can lead to the container(s) gaining access to files on the host machine if they are mapped within the container.
It’s important to always map to a known user at the end of your Dockerfile and also restrict access to Docker run time commands.
- Insecure Image Registries
All containers come from one or more registries. With unsecured access to registries, an attacker can manipulate your images to add code – without your approval or knowledge.
To prevent this from happening, you should always secure your registries with strong passwords, use SSL to encrypt access to registries, create distinct users, store user(s) and certificate information in a secure vault and regularly rotate credentials.
- Unsecured Access to the Docker Host(s)
All of your efforts to protect your Docker APIs, image registries, etc. will be for naught if an attacker can access your host machine(s). Therefore, all SSH and web page connections to your Docker/orchestration host machine should be monitored and recorded, and all root, and ‘docker’ group members accounts should be managed, stored and regularly rotated in a secure vault.