Security in the Linux container platform is an evolving state and, by many assessments, an incomplete one. Container technology arose from the need to run certain workloads in isolation, not so much to protect those workloads but to protect everything else from them which is driving the need for container and Docker security.
Security-related needs triggered the development trend that eventually led to Docker. Although Docker is taking steps to plug potential holes in container development platforms, experts say more work needs to be done before this is considered a mature environment.
Docker Security Risks
The greatest problem large organizations face today when assessing the potential value of adding Docker to their production environments is aligning the security controls and processes they already have in place (plus the compliance mechanisms that pertain to them) with the processes of managing and maintaining a Docker container environment. Compliance guidelines have been made to “mesh” with VMware environments and with private cloud platforms based around Linux. Container environments are so new that adaptation of these guidelines has yet to be fully developed.
From the perspective of a risk manager or insurance analyst, adopting Docker in production is risky enough to be considered potentially insecure – not for any architectural reasons but because such assessors have yet to completely understand Docker or containers.
For now, some organizations have concluded that Docker is too risky to adopt beyond development environments. For its part, Docker Inc. has made efforts to respond to risk managers and skeptics through public demonstrations of how its latest tools and add-ons directly combat known threats, such as container spoofing.
Docker has no inherent “security mechanism.” This does not mean Docker is inherently insecure. It does mean that security practices that pertain to running workloads on operating systems still need to be adapted to apply to Docker.
The greatest concern among security engineers is that the connection between containers and the kernel of the operating system that hosts their daemon is theoretically exploitable. An exploit delivered by way of a container could conceivably attack the kernel of its host, which, if it is not virtualized itself, renders the operating system — and thus the server — vulnerable. Demonstrations of such exploits have been conducted on systems that were left unprotected in the first place by the most basic of security measures, such as stateful inspection firewalls.
Many organizations deploy their Docker environments on virtual machines — rendering the containers’ host kernels virtualized, and thus partitioned exclusively from the processor’s native OS. While this eliminates the threat from one known exploit vector, it also diminishes the performance of containers in production.
Even virtualizing the host kernel may not necessarily protect data centers from another theoretical threat: Since containers communicate with other containers through networking (either through Docker’s native IP port mapping or through SDN network overlays), a container is theoretically capable of executing a denial-of-service attack. A properly implemented SDN could limit the extent of such an attack to the local subnet, although this would assume that the application being hosted by containers has no need to connect to the outside world.
Image Forgery Resistance – Docker Security
Encryption-Based Solutions
Docker Inc. has responded to the need for extra protection in these areas by creating a system called Content Trust, which encrypts and digitally signs containers (and all other content) pushed to its Docker Hub registry, as well as other Docker registries, including private registries.
Organizations can use this mechanism to automatically constrain any container running in a production environment to be based on an image whose constituent parts, including its master pulled from the registry, are digitally signed and verifiable (see Figure 1). This way, they know they’re not running containers that have been tampered with from the outside, and they can rely upon the good standing of the institutions that signed their images to begin with.
Some security experts have warned against relying on this method, or on any method so highly leveraged on encryption, as a full solution to the broader issue of container security. They say it can merely shift the single point of failure to whatever organizations choose for their key management systems. However, there is little or no argument against the use of any encryption whatsoever.
In November 2015, Docker Inc. addressed the issue of key management by announcing support of YubiKey, a physical, USB-based digital key manufactured by Yubico. YubiKey can be used in conjunction with an access control system that verifies the physical presence of the user logged in at a particular terminal. Operations involving the acquisition, composition, and deployment of containers may be restricted to individuals whose YubiKey is accessible to the host kernel. YubiKey is one more example of the types of vigilance-based methods upon which modern container security currently relies.
