How to Secure Container and Kubernetes Environments

The enterprise technology space constantly changes as new solutions become available. Containers and Kubernetes have altered the development process forever. Since it runs directly on the OS kernel, it makes CI/CD possibile with fast and mobile functionality. Sometimes though, security flaws hold containers back from its true potential.

Container and Kubernetes security provider, StackRox, released a report called The State of Container Security. They talked to over 200 IT professionals to get their perspectives on container security. It intends to understand how container adoptions trends relate to modern security concerns.

We reached out to StackRox to get a deeper take on their perspectives and concepts about container security. Ali Golshan, CTO and Co-Founder, gave us his insights.

Is there a difference between security tools that take a deployment-centric perspective vs. an image-centric perspective? Why is this important?

• Why is context important in leading to stronger container security outcomes?
• What is the impact at the operational/developer level?

A lot of container security platforms understandably focus on the container and the image as the security focal point. Taking a deployment-centric view is essential for putting that container or image information into context.

For example, looking at image security, you might identify a vulnerability, and that vulnerability might have a high score. However, without the context of where that vulnerability is running, it’s impossible to assess that risk. You need to know, for example, whether that image is deployed in your environment. If it is, is the container that image launched running in test or production? Is it running in an internal application or a customer facing application? How critical is that application? Is it just a testing application or is it your payment processing application? Is the container configured to run in privileged mode? What’s the network reachability of that container – is it internal only or exposed to the Internet?

To make the contrast clearer, having an image perspective is like calling your doctor and saying “I’m dizzy.” Your doctor can’t help you much with that info. Having the deployment perspective is like calling your doctor and saying, “I’m dizzy, and I’m having issues with my balance, and my smile is lopsided, and I can’t hold my left arm up as high as my right, and my speech is slurred.” Now your doctor knows you’re having a stroke – it’s not that you just stood up too fast.

What are some of the built-in security control features in popular container platforms like Kubernetes? Why is adopting the least-privilege model important?

Kubernetes provides powerful security capabilities around secrets management and network policy enforcement. Digging into network policy enforcement, you can use Kubernetes to limit what resources each asset can reach. By default, Kubernetes allows all assets to talk to all other assets, because the premise of Kubernetes is that it’s meant to aid application development, and as developers craft the microservices that are the building blocks for applications, Kubernetes defaults to letting all those services communicate.

Because the developers are working in Kubernetes, the security team should also use Kubernetes to help tighten down the environment – to limit those communications paths to reduce the blast radius if an attacker got in. Moving to least privilege is a fundamental tenet of security – any person or asset should be allowed to do only the functions necessary to its role and no more. Look for a container security platform that simplifies the process of moving Kubernetes to a least privilege model. The platform should highlight the allowed communications between assets, simulate new network policies, and recommend updated configurations that support least privilege and harden the environment.

What are the fundamental steps one should take to start to determine if their containerized environments are secure?

First, security needs to understand the landscape of containers deployment in their organizations already. Look for a container security platform that provides an immediate asset inventory and maintains this information continuously given the dynamic nature of containers.

Second, you need to asses the risk profile of the deployed containers, Kubernetes, and other assets. Understanding relative risk, taking into account the context of the full deployment vs. just the container, will provide the greatest accuracy and relevance.

Third, enabling easy remediation of the riskiest assets is crucial to hardening the environment. The security platform should incorporate all the context needed for the development team to apply the security fix, and the platform should enable that communications to the right team automatically.

Finally, look for a container security platform that provides continuous hardening. If the platform includes a feedback loops, with input from runtime affecting build and deploy risk profiling, you’ll have the opportunity to continuously improve security in your organization.

Follow those steps and you’ll be well on your way to a more secure container environment.