How to Close Kubernetes' Network Security Gap

To reap the full benefits of Kubernetes and microservices-based application architectures, organizations must transform how they implement security. This transformation often reveals gaps and silos across the development and operations teams and processes. Case in point: the gap between developers and the network security team.

Based on survey results from more than 300 DevOps, engineering, and security professionals, the “2022 State of Kubernetes Security Report” (PDF) shows that security is one the biggest concerns about container and Kubernetes adoption, with respondents noting that security issues have caused delays in deploying applications into production.

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

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

For example, developers and the network security team may be working, if not at cross purposes, then in silos. Developers historically haven’t been the ones to implement network security — they would just throw apps over the wall and rely on the security team to take care of network configuration.

In a Kubernetes world, however, the onus for security is on DevOps — or, at least, that’s the perception. And, it makes sense that people would think like that: The whole notion of “shift 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 as the primary owners of Kubernetes security, with only 18% identifying security teams as being most responsible.

But shifting left is not enough, especially when zero-day exploits are a relatively common occurrence. Only tight collaboration across development, IT operations, and network and other security teams can reasonably secure applications against attackers— especially those who are looking for points of entry from which they can move as far along the kill chain as possible.

Organizations likely 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 and understands and reviews network configuration within the cluster? Who is identifying and remediating misconfigurations ?

The gap between developers and the network security team can grow wider as companies move toward a zero trust model. With zero trust, of course, nothing is trusted. But businesses can’t run that way. At some point, someone has to provide permissions to specific applications and services to communicate with each other.

Kubernetes’ NetSec Conundrum

By default, Kubernetes deployments don’t apply network policy to Kubernetes pods. Without network policies, any pod can talk to any other pod or network endpoint — the equivalent of a computer without a firewall. Someone must go in and define ingress and egress network policies that limit pod communication to defined assets.

In the past, developers indicated what communications paths needed to be made available, and network administrators made those paths available via traditional firewall configurations.

The problem is that network security engineers do not speak the Kubernetes language. In a Kube world, everything you do around network security needs 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 that policies are written in, and the tools aren’t familiar to them.

One tool that bridges network security and other gaps is StackRox, a cloud-native 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 enables developers and security teams to visualize existing versus allowed network traffic. Using Kubernetes-native controls, NetSec teams can then more effectively enforce network policies and tighter segmentation. StackRox recently added a new feature to help developers define network policies prior to deploying their application to Kubernetes. This was developed in partnership with the developers of the np-guard project. StackRox roxctl now has the option to call np-guard to generate network policies by analyzing resource YAMLs.

With the StackRox project, organizations can address all significant security use cases across the entire application life cycle. Apropos of what I mentioned above, StackRox eases the process of applying and managing network isolation and access controls for applications. 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 that Kubernetes is configured according to security best practices.

Risk profiling: StackRox provides the context needed to prioritize security issues throughout Kubernetes clusters by analyzing a variety of data about deployments.

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

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

In general, using Kubernetes-native controls such as StackRox — in other words, using the same infrastructure and its controls for application development and security — enables companies to go from shifting security left to shifting it to a 360-degree cycle, all while extending Kubernetes’ automation and scalability benefits.

You can download StackRox from GitHub here. There you will also find related projects such as KubeLinter, a static analysis tool that enables developers to easily check Kubernetes YAML files, and Helm charts to identify misconfigurations and enforce security best practices.