Docker has been around for six years. In that time, lots of ink has been spilled (or pixels fired) about container security.
A lot of the articles out there on container security are still helpful. But the fact is that Docker (and the broader stack of tools that you now use to deploy containers) have evolved substantially over the past six years. A list of container security tips from three or four years ago may no longer be relevant today.
That’s true especially because containerized application stacks have become increasingly complex over the past several years. They have become complex not just because they involve more tools, but also because those tools integrate and communicate with each other in ways that create a tangled, fast-changing web of dependencies and data.
With that fact in mind, here are five container security considerations that matter today — as in 2019, when this article is being written. I can’t promise you that they’ll remain the be-all, end-all of container security a year or five years or ten years from now, because I don’t know how containers will change in the future. But I am confident that these are relevant container security practices for today.
Container image security
Container images were one of the first areas that folks focused on when discussing container security. Tools for scanning images for known security vulnerabilities have been out for years.
Those tools are still important, and you should be continuing to scan your container images for security flaws. However, what’s important to keep in mind today is that container image security doesn’t end with looking for malware in the image itself.
You should also be cognizant of how data is organized inside your container images, and which processes will be run by the container. Image scanning tools that look for malware signatures won’t necessarily detect other types of issues within the container image.
Think, too, about container registry security. Make sure your registry has the proper access control settings in place, and that you perform audits to detect poor registry security settings.
Firewall and network security
Wouldn’t it be nice if your containerized application sat neatly behind a firewall and never talked to anyone on the public Internet? In that case, container network security would be pretty simple to handle. You’d just set up a firewall and call it a day.
Unfortunately, in reality, container networks are not this simple. A containerized application stack typically involves a complex web of multiple networks, with endpoints spread across local and cloud-based infrastructure.
Detailing how to secure these networks is beyond the scope of this article. But know that it starts with embracing cloud-native firewalls that are “smart” enough to understand the complex connections and dependencies within containerized infrastructure. An old-fashioned firewall that expects everything behind it to be secure no longer works for container security.
It would also be nice if your containers ran on a single server, and you could use a simple access control framework (like Unix users and groups) to help mitigate security threats.
But most containers these days don’t work that way. They run on clusters of servers. Traditional Unix access controls are one way to help secure them, but access control is often much more complicated than that, because it also involves your cloud provider’s IAM framework.
Thus, to secure containers today, you need to audit not just Unix file permissions, users and groups, but also IAM policies within the cloud.
No sane person deploys containers in production today without an orchestrator. For that reason, it’s critical to think not just about the security of your containers, but also the orchestrator that manages them.
The way you secure your orchestrator depends on which orchestrator you use, of course. You should also keep in mind that orchestrators are designed to manage containers, not secure them. So most orchestrators offer only basic built-in security features. But at a minimum, you should ensure that you use any access control features available in the orchestrator, such as pod security policies in Kubernetes.
Runtime vulnerabilities have always been a consideration for container security, and they likely always will be. The point to emphasize here is that runtime security will not cease to be something you have to pay attention to. No matter which runtime you use, you need to be aware of security issues in it, and make sure you can update it quickly when they are discovered.
Five or six years ago (or even just two or three years ago), container security was a comparatively simple affair. There was simply less to worry about. Fast forward to the present, however, and container environments have become so complex that you need to think far beyond the basics. Things like runtime security and container image scanning are still important, but so are orchestrators, cloud-native firewalls, and more.