Container technology has been instrumental in the transformation of application development and deployment, and Docker has held the pole position. The reasons include Docker’s ease of installation and use, and its ability to automate common tasks so developers can focus on what matters: building great software. Overall Docker adoption has surged 35% within the last 12 months which is a clear indication that developers see its value and significance. Container technology is very agile. It’s ingrained in the DevOps pipeline and woven into various cloud architectures. However, this technology does create a cause for concern for both developers and security practitioners alike, as it presents yet another platform to secure and protect. Adopting emerging technologies often make security an afterthought, and the modern use of containerization makes no exception.
Protect the host, protect the deployment
There are many moving parts that make up the Docker platform, but in this blog, I’ll focus on the Docker Host and the importance of keeping it protected. Within the Docker Host exist three primary components: the Docker daemon, containers and 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 (see Figure 1). Most companies have defined roles within the organization that provide wide-ranging levels of access to the Docker Host for a variety of usages (e.g. managing containers, creating new images and getting real-time events from the server).
Figure 1. Docker’s client-server architecture
Now, there are more than 50 commands that can run within the Docker command-line interface. Among them include the building images from a Dockerfile (docker build), the creation of a new container (docker create), and the ability to terminate one or more running containers (docker kill). Why is this important? Well, would you want every developer, DevOps or IT operations team member within your organization to have the ability to execute some of these potentially risky commands in your container environment? Probably not. Furthermore, there’s a significant privileged escalation risk that lies at the container level. If a user were able to compromise a root account, they’d have the potential to elevate privileges to gain access to the Docker Host which can be the first step prior to rolling out a full-fledged attack that could put all of the containers at risk.
A few best practices
By implementing the principle of least privilege as well as incorporating separation of duties (SoD) controls, you can protect your modern Docker infrastructure without negatively impacting business efficiency or increasing operational costs. With the introduction of the principle of least privilege, you’re reducing the overall need for root accounts for many different use cases, which in turn, improves your organization’s security posture. Take it one step further by installing CyberArk On-Demand Privileges Manager on every Docker Host. A set of role-based permissions can be established which will run only the minimum commands required to perform the necessary tasks that each user’s job function requires – and nothing more (see Figure 2).
Figure 2. Set policies to limit the actions of privileged users on Docker Hosts
These predefined commands can be set for use by specific groups or personas such as Docker Dev, Docker Ops and Docker Security. The policies can be defined via white-listing or black-listing to provide maximum flexibility in achieving your organization’s desired restriction level. All of the elevated commands can then be audited and monitored allowing security and auditing teams to gain full visibility into your organization’s activity. What if you need to allow root user access to the Docker Host in specific scenarios? It’s a best practice to first centrally manage the root credentials and then introduce an isolation layer between root users and the Docker Host to prevent credential hijacking. You can implement approval workflows and apply further restrictions on the root user’s activities as needed.
Tracking what a root or other power user is doing once they’ve opened a privileged session to the Docker Host is critically important. CyberArk can secure all of this access, record and log all of the activity that occurs, as well as alert on potential threats to your Docker Hosts. Moreover, with CyberArk Conjur you no longer have to guess what’s happening within your Docker Host and containers. Even with many containers being brought up and down in ephemeral environments, you can gain full control and audit over which secrets each container or application can access. Based on an enterprise policy, every container/host/application is allowed access only to authorized resources, using its own machine identity. Every access is audited, and you can see the Docker role groups fall under compliance. Additionally, you can see all of your Docker users connected live to the Docker Host, so your organization never has to go blind into containerization again.
These are just a few examples of how CyberArk solutions will bolster your container platform security. Arm your security team. Empower your developers. Find out more by contacting a CyberArk expert for a full product and solution demo.
