There are a variety of excellent reasons to use containers. They're more agile and consume fewer resources than virtual machines. They provide more flexibility and security than running applications directly on the OS. They are easy to orchestrate at massive scale using platforms like Kubernetes.
At the same time, however, containers present some significant challenges, not least in the realm of security. Although the benefits of containers outweigh the security risks in most cases, it's important to assess the security problems that containers can introduce to your software stack and take steps to remediate them.
Toward that end, this article lists the top seven security risks that containers may pose, along with tips on addressing them.
Risk 1: Running Containers from Insecure Sources
Part of the reason containers have become so popular is that admins can pull a container from a public registry and deploy it with just a few commands.
That's great from the perspective of achieving agility and speed. But from a security point of view, it can pose problems if the container images that you pull contain malware.
This risk is not just theoretical. Hackers have actively uploaded malicious container images to Docker Hub (the most widely used public container registry) and given them names intended to trick developers into believing they are images from a trusted source. Indeed, according to one source, no fewer than half of all images on Docker Hub contain at least one vulnerability, which is an astounding figure.
The lesson here is that it's absolutely vital to check and double-check the origins of container images that you pull, especially when dealing with public registries.
Risk 2: Exposing Sensitive Data through Container Images
The risks associated with container registries can run in the opposite direction, too: you could upload data to a private registry that you assume is secure, only to discover that your registry – and the sensitive data you stored in it – are actually accessible to the world at large.
That's precisely what happened to Vine in 2016. The company uploaded a container image that included source code for its entire platform into a registry that was not properly secured. The registry’s URL hadn’t been publicly shared, but anyone who could guess the URL had unfettered, no-password-required access to the images in it.
Mistakes like this are easier to make than you might imagine. When you're juggling dozens or even hundreds of container images, it's easy to fall into the trap of accidentally placing a sensitive image in an unsecured registry, or even forgetting that an image contains sensitive data in the first place.
Risk 3: Placing Too Much Faith in Image Scanning
Image scanners, which can automatically determine whether containers contain known vulnerabilities, are a vital tool for helping to secure containers.
But scanners are only one type of tool, and they're hardly a complete guarantee against all types of risks. They work by matching the contents of container images against lists of known vulnerabilities, which means they won’t discover security flaws that have not yet been publicly disclosed. Scanners may also overlook vulnerabilities if container images are structured in unusual ways or their contents are not labeled in the way the scanner expects.
The takeaway: by all means, use container scanners. But never assume that an image is secure just because your scanner deems it so. Take additional steps to secure the container, such as monitoring the runtime environment for signs of security issues.
Risk 4: Broader Attack Surface
Running containers requires more tools and software layers than running a conventional application. In this respect, containers create a broader attack surface.
When you deploy containers, you have to worry about the security not just of the application and the operating system that hosts it, but also of the container runtime, the orchestrator, and possibly a variety of plugins that the orchestrator uses to manage things like networking and storage. If you run “sidecar” containers to help with tasks like logging, those become a security risk, too.
All of the above can be managed, but it requires a deeper investment in security — and a broader set of security tooling — than you'd use with a traditional, non-containerized application stack.
Risk 5: Bloated Base Images
Container base images are images that developers use as the foundation for creating custom images. Typically, a base image is some kind of operating system, along with any common libraries or other resources required to run the types of applications you are deploying.
It can be tempting to pack more than the bare minimum into base images. You never know what you may need to run your applications in the future, so you may decide to include libraries that aren’t strictly necessary for your applications today, for instance.
But the more you include in your base images, the greater the risk of a vulnerability that allows your containers or applications to be compromised. A best practice is to build base images that are as minimal as possible, even if that means updating them periodically or maintaining different base images for different applications.
Risk 6: Lack of Rigid Isolation
Containers should isolate applications at the process level. But the fact is that they don’t always do that perfectly well. At the end of the day, containers share the same kernel, and a bug in the runtime or a misconfiguration in the environment could allow a process running inside one container to access resources that live in other containers, or even gain root access to the host.
This is why it's extra important in the case of containers to vet your configurations for security as well as monitor runtime environments for malicious activity. There is simply a greater risk of privilege escalation and similar issues with containers than there is with virtual machines.
Risk 7: Less Visibility
The harder it is to observe and monitor an environment, the harder it is to secure it. And when it comes to containers, observability and monitoring are especially difficult.
It’s not that the data you need to track containers doesn't exist. It's that that data is spread across multiple locations — inside containers, on Kubernetes worker nodes, on Kubernetes master nodes — and that it’s not always persistent (logs inside containers will disappear forever when the container instance shuts down, unless you move them somewhere else first).
Here again, these challenges are manageable. But they require a more sophisticated strategy for keeping track of what is happening inside your environment than you would typically have with a simpler type of application stack.
Conclusion: Containers Are Great, but They Are Harder to Secure
Again, none of the security risks described above are a reason not to use containers at all. But they are reminders that with the great agility that containers provide comes extra responsibility. Before you go pulling images from a random Docker Hub registry and calling it a day, be sure you know where your images came from, what's in them, and which security risks may arise when they run.
Related Blog Posts
