How container security tools affect overall system security

Using the right container security tools

One of the biggest issues with containers is that traditional monitoring solutions lack transparency. Containers within the same host can communicate directly, leaving traditional monitoring systems blind to what's going on between the containers.

When containerizing systems, it's important to also include a monitoring system that's capable of monitoring both the system and the operational performance of containers. Prometheus is a good example of an open source monitoring solution that offers visibility into containers that tend to have a much shorter shelf life than a cloud, virtualized or physical monitoring system. This can be helpful in today's container environment where auditing processes and container security tools can help identify incidents more quickly and offer faster response times if needed.

Containers are an extremely useful technology, but like anything else, if they aren't secured properly, they can introduce additional risks into an organization.

Individual containers also typically have much shorter lifespans than typical virtual machines or on-premises systems. This means that attackers looking to use containers maliciously can do so with a lower risk of being caught. This is one reason that monitoring is so important within a highly containerized environment.

Container sprawl is also a concern -- similar to virtual machines -- and understanding how and who can create containers is important. Reducing your threat landscape is a key tenet of security no matter what technology you're using. Container sprawl can leave you open to additional risks and bring up potential compliance concerns.

Likewise, being able to track containers in motion is something organizations should consider. When containers in motion can't be tracked, blind spots are created, often leading to additional sprawl.

Container security tools for the container's host

Containers are only as secure as the container's host, and we've seen this same theory repeated many times with virtual systems. Just like when securing your hypervisor, you'll need to start looking at the security of the host first.

Taking a bottom-up approach is important because if the host is compromised, it could lead to the containers being compromised, too. Some processes in specific containers might need to be run with root privileges or given the ability to escalate privileges within the operating system or kernel. If these processes are compromised, then an attacker within the container might be able to exploit other containers hosted on that system, as the kernel is shared by the containers within the host.

Securing the container host offers a foundational level of security. By using control groups that limit the hardware resources and processes, whitelisting programs the container runs, patching and segmenting container hosts and using the principle of least privilege with application, authentication and network controls, the plumbing of the container can be locked down -- an important first step to reduce risk.

You may still need to use specialized container security tools even if the container host is completely locked down. You must understand what's running in your container and test it efficiently.

If you use anything downloaded from a public repository, then the code should be validated before you run any production data in the environment. Don't let the security of your applications and systems trust code that you got from a public source.

In addition, check that any software images you download have digital signatures -- then validate the signatures and verify that the image is what you expected. There are forgeries in public repositories, and you should determine ways to mitigate this risk.

Likewise, your images need to be immutable and subject to constant patching and vulnerability management because if one image is insecure, then each subsequent container that relies on it will also be insecure. This is a cascading issue that can quickly make your environment vulnerable if left untreated.

The problem continues when security is applied to an image, as the benefits must cover all the containers. By whitelisting and excluding things the image doesn't need, you can reduce the threat landscape. For example, web servers hosted in a container should only be allowed to communicate over the inbound TCP port 443 -- and not with each other.

Because container issues are primarily caused by misconfigurations rather than exploits, they should be reviewed to mitigate any future issues. It should also be noted that API keys and passwords are not within the container before they're released to the public.

Controlling network security between containers is important, and every container should have its own segmented network configuration that doesn't obstruct the other containers. These segmented containers should be configured so that network traffic doesn't travel between them, which could cause operational and security concerns. Tools such as Kubernetes offer orchestration and automation for containers to assist with deployment and management from both an operational and security perspective.

The use of containers is growing rapidly, and being educated on how they work and what needs to be done to secure them is important. Using other open source frameworks, like the CIS Docker Benchmark, offers a continuous method to keep track of your security to protect deployments and improve your security posture.