The Evolution of Container Security
Containers have evolved substantially since Docker’s introduction in 2013. So have the security challenges and solutions that organizations should think about when designing a container security strategy.
Here’s a look at how the demands of container security have changed between Docker’s early days and the present.
Container Security Circa 2013
For the first several years following Docker’s debut, container security was not as complicated as it is today.
This was true in part simply because few people were using Docker for mission-critical production deployments. Early on, folks were experimenting with Docker and using it to help with application testing and staging.
In addition, containerized application stacks were not as complex, and the various tools that composed them didn’t offer as many security features as they do today. Orchestrators were less sophisticated than the ones available today and didn’t offer the types of container security features built into modern orchestrators.
The nature of container security threats was simpler, too, in the early days of Docker. The biggest concern was malware inside container images. This risk prompted the release of container image scanners, such as Quay and Docker Security Scanning, in 2016.
Today’s Container Security Threats
If you deploy containers today, you have much worry to think about on the security front. Not only are you probably running containers in a large-scale production environment, where the implications of a breach are more serious. You also have to contend with new types of threats.
Today, attackers can exploit a vulnerability not just in your container runtime or images, but also in many of the other tools that you use to help manage your containerized environment. Fortunately, the security features of those tools have evolved to help meet these threats. Modern image registries have robust access-control systems to help you fine-tune who can and can’t access images, and what they can do to them. Orchestrators offer security features such as Kubernetes’s pod security policies to help enforce clusterwide security best practices.
Arguably, the greatest container security threat today is not what’s running inside your containers, but instead the container runtime. The runC vulnerability announced in February is probably the biggest security vulnerability ever discovered in the Docker world, in terms of its seriousness for production environments. And it’s not the first time that that type of security problem has appeared.
For container users, this is a bit of bad news. It’s easier in most respects to protect yourself against malware inside container images or to harden your orchestrator’s security settings than it is to detect and respond to security vulnerabilities in runtime code developed by someone else. The best you can do in the face of this type of threat is to make sure to keep your runtime up to date; even this, however, won’t detect you from vulnerabilities that have not yet been disclosed publicly.
This is a way of saying that container security has become more challenging than it was in the past. For the most part, the threats of the past are easy to handle these days. But new types of threats—especially those within container runtimes—present a deeper challenge that end users are not well-equipped to address.
