I recently attended a webinar in which one of the speakers said that a ‘container is never going to be as secure as a virtual machine.’ I beg to differ. Docker containers are not inherently less secure than running applications without them -- in fact, the opposite is true. But they need to be used correctly. Looking at several security disclosures from the past year (IBM Privilege Escalation Flaw and Vine's Docker registry "hack"), they were caused by human error stemming from ignorance, not from any security flaws or vulnerabilities in Docker itself or the containerized application.
Lead by large enterprises, container adoption is growing rapidly, almost 40% since March 2016 according to Datadog, a cloud monitoring platform. Moreover, Puppet’s recent survey shows that DevOps teams, which are the largest group to embrace Docker, increased from 16% in 2014 to 19% in 2015 to 22% in 2016 to 27% in 2017. With that in mind, there are plenty of opportunities and challenges, one of which is getting security right.
Airplanes are a pretty safe way to travel - but only if your plane is flown by a licensed pilot and maintained by licensed technicians. Similarly, you shouldn’t play with containers without understanding some of the basic best practices. By adhering to best practices, such as those laid out in Forrester’s container security report, organizations can enjoy the benefits of containerization without compromising security, and even improving it.
Four Best Practices to Get Started
As a first step towards comprehensive adoption of container security, review the following tips and ensure your efforts are in-line with them:
1. Use Trusted Images
Developers often assemble Docker images rather than build them from scratch. Be sure to set up a trusted registry of base images, which are the only images developers would be allowed to use. Use both education and enforcement controls to prevent the use of untrusted images, which may introduce vulnerabilities and configuration issues into your environment.
2. Manage Secrets
Putting secrets in the container image exposes it to many users and processes and puts it in jeopardy of being misused. You want to provide the container with access to the secrets it needs as it’s running, and not before. The secret should only be accessible to the relevant containers, and should not be stored on a disk or be exposed at the host level. Once the container is stopped, the secret disappears. When a secret is updated, like a database password, for example, you’ll want to make sure your system knows to update all containers using that secret with the new value.
3. Secure Your Runtime Environment
Apply namespace and cgroups permissions to isolate access, and control what each process can modify. Containers can connect to each other inside the same host and across clusters, thus making their communication invisible to traditional firewalls and networking tools, and limiting the ability to understand and control traffic at a granular level. Therefore, use container-level Nano-segmentation to limit the potential “blast radius” in case a container tries to do something it shouldn’t.
4. Vulnerability Scanning
Prevent images with known vulnerabilities from running in your production environment by using vulnerability scanning tools. Containers aren’t usually built from scratch, so be sure to scan images to discover any dependent base images that might have vulnerabilities. Incorporate vulnerability scanning “quality gates” in your delivery lifecycle to prevent vulnerable containers from deploying.
By taking a proactive approach, i.e. creating and implementing security policies throughout the entire container lifecycle, a containerized environment can be secured very effectively.