Five Docker Security Best Practices
Docker container adoption is growing rapidly. Eighty-three percent of enterprises are using or planning to use Docker according to the latest survey by RightScale. However, security concerns remain one of the top challenges. In the latest Cloud Native Computing Foundation (CNCF) study, 43 percent of respondents identified security as the biggest hurdle in container adoption.
As container usage goes mainstream and moves into production environments, I expect that interest in Docker container security topics will only increase. In this article, I will discuss five Docker security best practices to consider as you begin your journey to adopt container infrastructure.
1. Docker Host, Application Runtime, and Code-Level Security: Take a Holistic Approach
Docker security starts with the host, as containers share the operating system kernel. If the host gets compromised, all the processes are vulnerable. Processes running inside the Docker container appear to run on an isolated Linux host, but in actuality, they are just “namespaced” processes inside a shared host. Your number one priority is to keep the host operating system properly patched and updated. Similarly, processes running inside your container should have the latest security updates, and you should start incorporating security best practices into your application code.
2.Docker Runtime Security: Know What’s in Your Container
As you build Docker container images, you need to know exactly what goes into each layer. However, doing so only at build time is insufficient. You must also ensure that containers installed by third-party vendors do not download and run anything at runtime. Everything that a Docker container runs must be declared and included in the static container image. It is especially important for third-party vendor containers. Some performance tools, for the sake of installation simplicity, deploy a minimal agent, which then downloads other language-specific agents at runtime. You deserve transparency, though. Just say no to stealth downloads at runtime.
3. Docker Image Authenticity: Do You Trust the Source?
Just as you wouldn’t download and run software on your PC from any random internet source, you must know and trust the origin and registry of your container images.
Docker Store is that trusted marketplace. Unlike Docker Hub, where anyone can push container images, Docker Store hosts containers from trusted partners. Docker does vulnerability testing for these Docker container images, too. Image provenance provides a verifiable trace of the origin and contents of the image.
The latest, digitally signed releases from AppDynamics are available from the Docker Store.
Even for your internal images, I would recommend using a PKI-based trust mechanism to ensure the authenticity of the person, team or process that publishes container images.
4. Limit the Resource Utilization: Avoid Noisy Neighbor Issues
Since Docker containers are lightweight processes, you can run many more containers than virtual machines. This increased density is beneficial, as it increases host resource utilization and allows you to optimize total cost of ownership. It also implies that a far greater number of processes are competing for host resources.
To reduce the threat of vulnerabilities such as denial-of-service attacks, and performance impacts due to noisy neighbors, you can put limits on the system resources that individual containers can consume, through container orchestration frameworks such as Kubernetes or Swarm.
AppDynamics comprehensively monitors the resources consumed by all monitored containers on the host. Be proactive in your approach by creating desired thresholds and alerts in AppDynamics so that you get alerted when any Docker container approaches its limit.
5. Running in Super-Privileged Mode? You Are Giving the Keys Away
If you follow the four recommendations above but still run your (or third-party) Docker containers in super-privileged mode, you are essentially bolting the windows but leaving the front door wide open.
Containers running as super-privileged break the basic tenet of containerization around isolation and containment. Such containers will increase the threat surface, potentially endangering the entire data center or VPC environments.
Fortunately, by default, Docker doesn’t run containers as super-privileged — you explicitly have to grant these permissions. But only do so where your Docker containers require access to protected resources.
Conclusion
By design, Docker is built with security best practices in place. But it’s critical that you never let your guard down, especially when running Docker containers from third-party vendors. It’s much better to be vigilant now than to appear on the news for all the wrong reasons.