Container technology continues to grow in popularity. It’s considered by many in the IT industry as the go-to strategy for virtualization. In fact, we get a lot of requests here at ClearScale by customers who are interested in using the technology to meet their project needs.
Like most technologies, however, containers have security risks. In 2017, the National Institute of Standards and Technology (NIST) released a guide that identifies many of those risks and offers recommendations for mitigating them. While the guide doesn’t solve all the potential risks associated with containerization, it does provide a good starting point.
Our development teams have spent a lot of time studying the NIST’s recommendations for mitigating container security risks — and implementing them when appropriate. In this blog post, we discuss the NIST’s take on where some of the security issues are and their recommended fixes for them.
At the OS Level
When it comes to security risks in containerization, the host OS is a primary attack target and an attack on it can put all the containers running on it at risk. 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. Administrators must still apply any and all 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 uniquely and 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 are also security risks because they can contain vulnerabilities such as outdated versions of software, libraries, 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 multi-layer 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 also recommends 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 poorly configured registry can be a security issue as well. 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 two-factor 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 recommends 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.
Workloads should also be distributed so 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.
Containers pose yet another source of security risks. For example, 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 security. Container technology works differently than server virtualization, so your development practices, patching techniques, and system upgrade processes may need to change as well. Education and training everyone involved in the software development lifecycle will help.
The ClearScale Difference
It also helps to work with a partner with deep-seated experience working with containerization. ClearScale has been working with containers for years, even before Docker came on the scene in 2013. We stay on top of emerging best practices and technologies and continue to develop and test our own solutions. We’ve used most of the various tools on the market, so we know which ones work and what they work best for.
If you’re interested in learning about some of our specific experience with containers, you can read additional blog posts on the topic here.
And if you’re ready to talk about your specific project, whether it involves containers or not, get in touch with us today.