How to Close Kubernetes’ Network Security Gap

To take full advantage of Kubernetes and microservices-based application architectures, enterprises must transform the way they implement security. This transformation often reveals gaps and silos between development and operations teams and processes. Example: the gap between developers and the network security team.

Based on the results of a survey of over 300 DevOps, engineering, and security professionals, the “State of Kubernetes 2022 Security Report” (PDF) shows that security is one of the top concerns around the adoption of containers and Kubernetes, with respondents noting that security concerns have caused delays in deploying applications into production.

Almost all survey respondents, 93%, said they had experienced at least one security incident in their Kubernetes environment in the past 12 months, with 31% reporting a loss of revenue or customers due to a security incident. security.

Most of these incidents are due to human error, with more than half (53%) of respondents saying they’ve detected a misconfiguration in Kubernetes in the past 12 months. There are many best practices for avoiding Kubernetes misconfigurations, but the reality is that Kubernetes is large and has some complexity. Gaps in roles, responsibilities, and skill sets — common, especially for companies refactoring legacy applications — leave the door open for vulnerabilities.

For example, developers and the network security team can work, if not at cross purposes, at least in silos. Historically, developers haven’t been the ones to implement network security – they just throw apps over the wall and rely on the security team to take care of network configuration.

In a Kubernetes world, however, the responsibility for security lies with DevOps – or, at least, that is the perception. And, it makes sense for people to think like this: the whole notion of “shifting left” is that security is addressed as early in the development cycle as possible.

Indeed, according to the survey, DevOps is the role most often cited as responsible for securing containers and Kubernetes: 15% of respondents consider developers to be the primary owners of Kubernetes security, with only 18% identifying security teams as the most responsible.

But moving left isn’t enough, especially when zero-day exploits are relatively common. Only close collaboration between development teams, IT operations, network and other security teams can reasonably secure applications against attackers, especially those looking for entry points from which they can move the most. far as possible along the chain of destruction.

Organizations probably understand all of this in theory, but in reality, there’s a bit of a no-man’s land when it comes to network security and Kubernetes: who manages, understands, and reviews network configuration within the cluster? Who identifies and corrects configuration errors?

The gap between developers and the network security team can widen as organizations move toward a zero-trust model. With zero trust, of course, nothing is trustworthy. But businesses can’t operate that way. At some point, someone has to provide permissions to specific apps and services to communicate with each other.

The Kubernetes NetSec Conundrum

By default, Kubernetes deployments do not apply network policy to Kubernetes pods. Without network rules, any pod can communicate with any other pod or network endpoint, the equivalent of a computer without a firewall. Someone needs to go in and set ingress and egress network policies that limit pod communication to defined assets.

In the past, developers specified which communication paths should be made available, and network administrators made those paths available through traditional firewall configurations.

The problem is that network security engineers don’t speak the Kubernetes language. In a Kube world, everything you do around network security has to be written in YAML, a data serialization language, but network security engineers think in terms of IP addresses and IP tables. The NetSec team doesn’t really understand the language the policies are written in and the tools are unfamiliar to them.

One tool that fills network security and other gaps is StackRox, a cloud-based open source project that provides organizations with tools, training, and a community of shared experiences with building Kubernetes security implemented as security policies that can be used to monitor Kubernetes clusters and the workloads running on those clusters.

When it comes to network configuration, StackRox allows developers and security teams to view existing network traffic versus allowed network traffic. With native Kubernetes controls, NetSec teams can then more effectively enforce network policies and stricter segmentation. StackRox recently added a new feature to help developers set network policies before deploying their application to Kubernetes. This was developed in partnership with the developers of the np-guard project. StackRox roxctl now has the ability to call np-guard to generate network policies by scanning YAML resources.

With the StackRox project, organizations can address all important security use cases throughout the application lifecycle. About what I mentioned above, StackRox makes the process of applying and managing network isolation and access controls for applications easier. Other use cases include:

Vulnerability management: StackRox helps organizations protect against known vulnerabilities by identifying vulnerabilities in images and running containers.

Security configuration management: Organizations can leverage StackRox to ensure Kubernetes is configured according to security best practices.

Risk profiling: StackRox provides the context needed to prioritize security issues in Kubernetes clusters by analyzing various data about deployments.

Compliance: Organizations can leverage StackRox compliance policies to meet contractual and regulatory requirements.

Detection and response: StackRox provides incident response capabilities, enabling organizations to respond to active threats in their environments.

In general, using native Kubernetes controls such as StackRox – in other words, using the same infrastructure and its controls for application development and security – allows companies to move from moving from security left to a 360 degree cycle, while extending Kubernetes automation and scalability benefits.

You can download StackRox from GitHub here. You’ll also find related projects like KubeLinter, a static analysis tool that allows developers to easily check Kubernetes YAML files, and Helm charts to identify configuration errors and enforce security best practices.