Adoption of containers as a means to package and run applications continues to surge. There are many benefits driving this trend, first and foremost for developers, but also extending across the entire application lifecycle.
While container adoption continues to soar, organizations face a number of critical challenges in protecting the secrets and credentials necessary for a containerized workflow.
In a recent On the Front Lines Webinar, we explored several container-specific security vulnerabilities and the techniques to address them, which are applicable to Docker, Kubernetes and popular platforms such as OpenShift and Cloud Foundry.
To set the stage, we examined a typical Docker workflow. This includes the initial client request to the host (which comprises the Docker daemon, containers and images) and the registries that house all of the images. The Docker daemon is a service that runs on the host OS and manages both the containers and images. It looks out for API requests from Docker and also acts as the communication layer to manage other services within Docker. (You can read more about this here).
There are six specific points throughout this Docker ecosystem that could be breached at any given point in time and lead to either malicious or unintended consequences. Following is a look at each of these steps, along with best practices to mitigate risk.
- Unsecured access to the Docker API. Users added to the “Docker” group can use all Docker functions that utilize images and containers. To mitigate risk, do not add all accounts to the “Docker” group and enforce least privilege policies to limit commands that can be sent by a user.
- 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. 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. 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 SSL/TSL, 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 accounts should be managed, stored and regularly rotated in a secure vault.
While there’s no question that containers are here to stay, they have introduced a host of new security challenges that must be addressed. Now is the time to assess your container environment and begin protecting privileged access.
For tips on getting started, tune in to the full webinar, check out CyberArk Conjur and its comprehensive integrations with leading container platforms or contact your CyberArk team for a full evaluation.
