Kubernetes basics: A step-by-step implementation tutorial Compare Mesos vs. Kubernetes for container federation
X
Tip

Four container security vulnerabilities and how to avoid them

Find out how container security best practices can address the four most common types of container and orchestrator vulnerabilities. Then mitigate threats with the right processes and tools.

Container use has skyrocketed, and for good reason. According to the Nemertes 2018 Cloud and Networking study, 45% of organizations reported using containers by the end of 2018, compared with just 21% in 2017.

The impetus behind that growth is that containers can turbocharge DevOps development, providing the ability to roll out code quickly with minimal defects. Containers and the cloud are also synergistic, enabling developers to shorten application development time (compared with virtual machines) while consuming fewer compute and storage resources. Containers are also highly portable, making them a crucial choice for migrating to a multi-cloud environment. As a result, container security best practices are emerging.

But for cybersecurity professionals, containers and their associated orchestration tools (called orchestrators) can introduce a host of vulnerabilities. Last year, Tesla was breached via an unsecured orchestrator console. And Shopify, an online e-commerce platform, detected and remediated a bug introduced by a white hat hacker as part of its bug bounty program, through which the company pays researchers to discover and reveal flaws. In this case, the researcher was able to fraudulently gain control of the container cluster.

Essential background on containers and orchestrators

To understand the issues with container and orchestrator security, it helps to have a basic understanding of containers and orchestrators. To review, a container is a software environment that includes an application and its associated binaries (machine-readable data files) and libraries (reusable code), but not the operating system. It operates on a shared container engine atop the OS. The container engine is typically Docker, although companies are developing Docker-like capabilities (Microsoft's Windows Server 10 includes Windows Containers, which is not Docker-based, as well as native Docker support).

If you can compromise the orchestrator, you can compromise all of its associated containers.

Like its earlier counterpart, the virtual machine (VM), a container is a software environment in which applications execute. The big difference between a container and a virtual machine is the absence of the operating system image. A VM includes a complete instance of an operating system, including the kernel, drivers and shared libraries. A container doesn't. Only the application code and any required libraries are inside the container, and the container itself provides a subset of OS services.

To deploy and manage containerized applications, developers typically rely on an orchestrator, a tool that automates deployment, scaling and management. The most common of these is Kubernetes. It's important to understand orchestrators consist of multiple components, including an API server that integrates with other applications seeking to create or distribute containers, and various monitoring and management tools to ensure the health of the container farm. Orchestrators also have the ability to create, store and manage images, which are essentially the recipes for creating specific containers.

The key point is that orchestrators are essentially the control system for containers. Therefore, they represent a major attack focus for hackers. If you can compromise the orchestrator, you can compromise all of its associated containers. It's also possible to compromise individual containers directly.

Types of container security vulnerabilities and attacks

Most container and orchestrator vulnerabilities are familiar to many cybersecurity professionals because they represent the classic vulnerabilities of operating systems and applications. These include the following four categories.

  1. Access and authorization. It's noteworthy that the Tesla and Shopify examples cited above were both due to access and authorization. In Tesla's case, Kubernetes was left unsecured due to a configuration failure. In Shopify's case, hackers were able to gain unauthorized access to the API server. The point is that as with any application or operating system, developers must pay special attention to configuring and securing all access and authorization by locking down access and keeping current with security patches.
  2. API server access. It's particularly important to focus on access and authorization to the API server because of its fundamental role. The API server is an automated front end to the orchestrator. Think of it as a front door configured to let in only certain applications that possess the right credentials. Faked or spoofed credentials can cause the door to swing wide open, opening the containers up to illicit access. So, protecting the API server should be a specific area of focus for any access and authorization initiatives.
  3. Image vulnerabilities. Images are the DNA of the orchestrator; they're the recipes from which containers are built. A clever hacker can infiltrate the images with malware, thereby generating "poisoned containers" that can cause harm. A really clever hacker can also adjust the health-monitoring components of the orchestrator so it won't detect those poisoned containers. Image registries, databases of all stored images, can also be corrupted, hiding the presence of infiltrated images. Therefore, it's important to have the ability to detect and manage changes to images as well as managing the containers themselves.
  4. Inter-container network traffic. Although they're fundamentally self-contained, as the name implies, containers communicate with one another, typically over an encrypted link. The encryption can be a double-edged sword, however. If a container is compromised, it can spread malware to another container, and the encryption will hide the malware transfer as well as legitimate data flows.
  5. Additional vulnerabilities. To understand other types of container security vulnerabilities, NIST publication SP800-190  is a good resource. As noted, though, they're all variations on standard vulnerabilities that most computer scientists learned about in school. The only novelty is that they apply to the new constructs of containers and orchestrators.

Two container security best practices

A cybersecurity professional should do two things to deal with container security vulnerabilities.

First, sit down with developers and review the state of container and orchestrator security during the entire software development lifecycle, including planning and analysis, development, deployment and ongoing management (including decommissioning). Pay special attention to the vulnerability areas called out here, and discuss protection and mitigation plans with the team. Depending on your organization, you may want to invest in bug bounty programs like the one Spotify participated in (the company reportedly pays out $1 million in bounties per year).

Second, consider investing in tools that specifically focus on ensuring container and orchestrator security. Vendors include Aqua Security Software, Capsule8, Layered Insight, NeuVector, StackRox, Tenable, Tigera and Twistlock. Regardless of which is most appropriate for your organization, you should budget for a tool in the space.

The bottom line on container security vulnerabilities

Although containers and orchestrators can deliver great value to development organizations, they also pose security risks. The best approach is to be proactive in both recognizing vulnerabilities and mitigating them. Budget for and put in place the technologies and processes that can protect your organization.

Dig Deeper on Data security and privacy

Networking
CIO
Enterprise Desktop
Cloud Computing
ComputerWeekly.com
Close