Container Security Risks and Remedies

Container technology is considered by many in the IT industry as the go-to strategy for virtualization. Like most technologies, however, containers have security risks. The National Institute of Standards and Technology (NIST) released a guide that identifies many of those risks and offers recommendations for mitigating them and achieving secure containerization. While the guide doesn’t solve all the potential problems associated with containerization, it does provide a good starting point.

In this post, we discuss the NIST’s take on some of the security issues and their recommended fixes.

Secure Containerization at the OS Level

When it comes to security risks in containerization, the host operating system (OS) is a primary target. An attack on the OS can put all the containers running on it in jeopardy. That’s why the NIST recommends running a minimalist, container-specific OS that limits the number of installed components to the least amount required. Fewer components equal fewer vulnerabilities to exploit.

That doesn’t mean a minimized OS is risk-free. Security administrators must still apply security patches immediately to all host instances in the cluster. That includes the OS kernel, the container runtime, and other system services or components recommended by the OS vendor.

Another must is proper OS configuration. The NIST recommends running the host OS as an immutable infrastructure with no data stored persistently on the host. The host shouldn’t provide any application-level dependencies other than what’s been packaged and deployed as containers.

Application Images

Application images are also security risks because they can contain vulnerabilities such as outdated versions of software or malware. The NIST recommends using vulnerability scanning tools to identify and mitigate them. There are a lot of tools on the market. Look for those that are container-aware and capable of scanning all layers of a containerized application.

Poorly configured images can be an issue as well. For example, an image might be configured to run with more user privileges than necessary. Or, the images could store secrets like authentication keys or certificates. As such, the NIST advocates using tools and processes to validate and enforce compliance with secure configuration best practices for images. This includes having centralized reporting and monitoring of the compliance state of each image and preventing non-compliant images from running.

A misconfigured registry can also be an issue when it comes to secure containerization. In that case, the NIST recommends requiring encrypted and authenticated credentials for accessing the registry. The registry should also undergo regular maintenance to identify and mitigate stale images with lingering vulnerabilities.

Orchestration and Isolation

Other potential attack targets noted by the NIST include container orchestration tools. It’s important to secure the administrative interface, especially if a single orchestrator manages multiple applications. This may include using multifactor authentication and encryption of data at rest. If you don’t limit access, a negligent or malicious user could wreak havoc.

In its guidelines, the NIST suggests configuring orchestrators to separate network traffic into discrete virtual networks, based on the sensitivity of the traffic being transmitted. The idea is that low-sensitivity workloads should be isolated from high-sensitivity workloads.

While most container platforms are effective in isolating containers from each other and from the host OS, it’s recommended to not run apps of different sensitivity levels together on the same host OS. Segmenting containers by purpose, sensitivity, and threat posture provides greater protection and the ability to achieve secure containerization.

Workloads should also be distributed so that each host runs containers of a given security level. This makes it harder for malicious actors to access sensitive data if a low-sensitivity application is compromised.

The Containers

Containers pose yet another source of security risks. Container runtimes that launch and manage containers — such as runc, rkt, frakti, and cri-containerd — may contain vulnerabilities. Left unpatched, they can lead to attackers accessing other containers or the host OS.

Also, pay attention to the configurable options available with container runtimes. A misconfiguration could enable a container to make unsafe system calls or compromise the host OS.

Change the Way You Work

One of the most important recommendations cited in the NIST guide is to change the way you work — particularly in terms of secure containerization. Container technology operates differently than server virtualization, so your development practices, patching techniques, and system upgrade processes may need to change as well.

And it’s important to remember that automation is the key to container security. The best path to success requires baking container security automation into the pipeline.

Secure Containerization – The ClearScale Difference

It also helps to work with a partner that has deep-seated experience with containerization. As an AWS Premier Consulting Partner, ClearScale has been working with containers for years. We stay on top of emerging best practices and technologies for AWS containerization, including secure containerization. To learn more about some of our specific experiences with containers, you can read case studies here.