Since Docker’s release in 2013, several vulnerabilities have been discovered that could lead to privilege escalation and arbitrary code execution. In our Docker Security and Containerization Report, we review and highlight the top 5 vulnerabilities from high to critical severity.
Based on interviews with developers who use Docker in their software deployment process, and the vulnerabilities discussed in our Docker security report (bypasses, privilege escalation, denial of service, and code execution), summarized below are the top 5 risks inherent across container deployment and maintenance in an organization’s IT environment.
By default, in some versions of Docker, all network traffic is allowed between containers on the same host. This increases the risk of unintended and unwanted disclosure of information to other containers. Developers should only allow intercommunication that is necessary by linking specific containers. This will significantly reduce attack surfaces by restricting container access.
To protect confidentiality and integrity of all network traffic, communications with Docker registries should be encrypted through TLS security protocol.
Organizations should evaluate the effectiveness of their current controls and implement Docker-specific controls to mitigate risks that may impact business objectives. In general, practicing good cyberhygiene and increasing transparency of the software development process in Docker will reduce the risk significantly.
An attacker who gains access to one container may have the capability to gain access to other containers or the host. For example, a container may have the ability to access system file directory on the host via remounting, which is critical to security enforcement.
If the attacker has root access to the container, he or she may have the ability to gain root access to the host, often through bugs in the application code. The access control best practice recommendations includes the principle of least privilege. The user namespace feature in Linux containers will allow developers to avoid root access by giving isolated containers separate user accounts, and mandate resource constraints, so users from one container do not have the capability to access other containers or exhaust all resources on the host.
However, this feature is not enabled by default. System administrators should have this feature enabled to leverage application sandboxing in Docker.
Docker is designed to have all containers share the same kernel and the host. This provides convenience but also amplifies the impact of any vulnerabilities present in the kernel. System administrators should ensure that the host environment is properly hardened and patched to reduce the likelihood of privilege escalation, arbitrary code execution, and denial of services.
They should also restrict applications that run on privileged ports besides the ones that are necessary (e.g. Apache server), since those ports have more access to the kernel.
Running an older version of Docker containers can expose internal IT environments to higher risks of breach, and potential loss of sensitive information.
New security features and bug fixes are often included in the update packages. Like any technology we run in the IT environment, a patching policy should be in place and enforced.
Developers need to make sure they are downloading Docker images from trusted sources that are curated by the Docker community or the vendor, and run vulnerability scans against those images before running them in the host environment.
To ensure integrity of a container image, content trust should be enabled to allow digital signatures for data sent to and received from remote Docker registries.
Learn more about Docker Security and Containerization. Download our free report today.
Since 1999, Jacqueline has written for corporate communications, MarCom agencies, higher education, and worked within the pharmacy, steel and retail industries. Since joining the tech industry, she has found her "home".