The 4 Most Vulnerable Areas of Container Security in 2019

Software containers have become more popular in recent years as many organizations have discovered the benefits of containerization. Unfortunately, as is often the case with rapid advances in technology, container security has been a bit neglected and is often an afterthought.

Part of the problem is that some security teams fail to correctly understand containers and the challenges in keeping them secure. To understand the four most vulnerable areas of container security, one first must gain a complete understanding of how they work.

What is a Software Container?

Software containers are lightweight virtual machines that place less strain on system requirements. The packages share the host OS kernel during runtime, which makes them “light” in terms of size (only megabytes) as well as extremely fast.

Containers take only a few seconds to launch, making them a vast improvement over the minutes a VM requires to start up.

The software has been around since the early 2000s, yet most developers did not begin to fully realize their potential until recently. Containers are portable, utilizing hardware that can support an exponentially larger number of systems than VMs, thus dramatically reducing infrastructure costs.

The arrival of Docker and Kubernetes has transformed containers into a trending item, as it was reported recently that Bank Mellon and JP Morgan Chase—two massive corporations—would soon begin adopting container-based developments.

Software Container Security Flaws

While containers are replacing some more traditional cloud-based services because they are effective in running applications from one environment to another (public cloud, private data center, etc.) it does expose their security vulnerabilities.

The unique risks have not been fully realized yet by some security teams, which unfortunately exposes them to security threats. Containers were not architected with security in mind, which is a common dilemma for new technologies.

However, now that containers are becoming more popular, it is time to explore their most vulnerable areas.

Container Images

For those familiar with containers they will attest to the fact that the technology is dependent on images. They serve as the building blocks for containers. The technology enables developers to easily create their own images or download public files from providers such as Docker Hub.

However, images are not always easy to trust from a security perspective. The images must be signed and originate from a trusted registry to ensure high-quality protection. They also must get properly vetted and the code validated. If not, the images are vulnerable to cyberthreats.

Images can feature numerous “layers,” which, when incorporated into the build needed to speed up deployment, present a greater risk of open source components finding their way into production without correctly being scanned and validated beforehand.

Kernel Root Accounts

The reduction of the attack surface is a basic aspect of any security approach. It ensures that code with vulnerabilities does not enter into the environment.

However, with containers there are specialized structural and operational elements that require extra attention. Therefore, the attack surface of the container poses a serious vulnerability.

Creating a sound attack surface requires attention beyond securing the host, though that still is very important. The configurations and container profiles must be maintained consistently to minimize security threats.

The problem is unlike in virtualized environments (in which a hypervisor serves as a point of control), any user is granted access to the kernel root account related to a container. Consequently, the user is able to access all the containers shared under the Linux kernel.

There are methods to “harden” kernels and hosts, yet the best approaches to handling containers moving forward remains an issue.

User Access Control

Docker used to provide no option for its root access as it was by default “all or nothing.” Of course, this approach was not welcomed by security experts. Thankfully, Docker and other applications have worked to improve the tightening of user access control.

Access controls are now enforced to privileged accounts as well as operations for the deployment pipeline. The approach helps with accountability and operational consistency related to effective access controls. It creates methods to pinpoint who made changes to container settings or configurations. It also helps discover who downloaded an image and if anyone started a container in production.

The added emphasis on accountability is a vast improvement over the previous way of doing business, in which a generic root access basically made finding the initial source impossible.

However, it is important to note that although developers can get more access to what they need to get a job done, that does not always make it beneficial for your safety and security. Developers can get too much access to accounts, so applying centrally managed constraints on what changes or commands a user can make is essential.

The Web Host

While a huge benefit of a container is that it can isolate an application and its dependencies within a self-contained unit that can run anywhere, it does pose some security vulnerabilities.

You need to be aware of how the container can impact the actual host and what measures are appropriate to ensure its safety. For this reason, it’s safer to run container orchestration systems such as Kubernetes in the cloud, i.e., Azure, GCP or AWS. Each has tools in place that can constrain what the unit can and cannot access. In comparison, most shared web hosting services lack the same constraints, and are therefore less secure.

Such cloud tools include:

• Control groups: Define how much of the shared kernel and system resources a container may consume. They can help prevent security issues.
• Namespaces: Are another type of security for containers. They define what a container can “see” and determine what resources the container is allowed to access.

The components help protect the server when multiple services run on it. Consequently, namespaces and control groups are essential to security.

Control groups and namespaces must be configured consistently to make sure nothing is exposed. These measures are effective in limiting a container’s access to kernel resources, but not nearly as effective at isolating the container’s execution path.

Conclusion

Don’t let your container become victim to security threats. There are some unfortunate examples of containerization initiatives that were set back or shelved completely because companies failed to address the most vulnerable areas of container security.

When you become aware of the most serious risks, and then create a container vulnerability assessment program your IT team can stay ahead of the latest cyberattacks.