Container technology makes
it possible to independently package and run software across computing
environments, improving software development efficiency and IT operations.
Recent advances make it easier than ever to use, but security can’t be
overlooked.Similar to the adoption of
DevOps and cloud technologies, the introduction of containers expands an
organization’s attack surface. Attackers
are eager to abuse privileged containers to bypass installed security
mechanisms, escape to the host and infect other containers that the machine may
be running. This can enable an attacker to move laterally across the corporate
network, perhaps taking over the network completely.Here’s a list of the top
security issues that containers may be prone to, with remediation methods for
each. In this article, we use
Docker as an example, since Docker technology is by far the most popular container
technology. Docker is a valuable tool and it’s our goal to educate
organizations on security risks and offer mitigation techniques to ensure
Docker security.
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.
There’s no question that containers are here to stay. Despite their benefits, they have introduced a host of new security challenges that must be addressed. Now is the time to assess your container environment, figure out what your pain points are and begin taking steps to remediate their risks.Nimrod Stoler is a cybersecurity researcher at CyberArk Labs
An In-Depth Guide to Cloud Security
Get essential knowledge and practical strategies to fortify your cloud security.
An exclusive conversation with SC Media and cybersecurity venture capitalist Bob Ackerman explores the deal’s impact on hybrid cloud, AI, and the future of M&A.
