Is the Kubernetes security deficit widening?

Despite Kubernetes adoption soaring in recent years, users are concerned security strategies haven’t kept pace. 

A significant minority (38%) feel security isn’t taken seriously enough, according to Red Hat’s latest State of Kubernetes report, or that investment in containerized operations is inadequate. This is a rise of 7% against the previous year. 

These concerns are affecting the implementation of cloud native technologies, with 67% reporting delaying deployments due to security issues. 

Kubernetes security pain points

Security pain points include tooling around signing and verification according to Jeffrey Sica, principal developer experience engineer at the Cloud Native Computing Foundation (CNCF). “If the solution to a problem is difficult to implement, developers will go out of their way to shift – or not even address – the problem,” he tells ITPro.

Policy is also an issue, not only in terms of enforcement but also definition. “Businesses need some examples or sane defaults to build off of, and it seems there’s somewhere of a gap there,” Sica says. 

More than half of Red Hat’s respondents worry about misconfiguration and vulnerabilities due to Kubernetes’ level of customization, while the focus on upgradeability also poses security risks in some people’s eyes. 

One of Kubernete’s guiding principles is backward compatibility and so a default configuration release will never break an existing deployment. This means teams must pay special attention to new security features that may be disabled by default, notes Sandy Carielli, a principal analyst at Forrester. 

She also points to the fact more organizations need to realize Kubernetes security goes far beyond the API itself. “Because Kubernetes security also extends into application security, container security, identity management, and zero trust, security professionals must have basic familiarity with all of them and be able to collaborate across the team,” she adds. 

“Kubernetes is a Venn diagram over security disciplines and organizations can’t confine their discussion of Kubernetes security to just the Kubernetes settings.”

“At its core, Kubernetes is simply an API that allows the scheduling of containers. In that sense, the attack surface is the API server, or the containers being scheduled by Kubernetes,” continues Sica, who says that as container run times and Kubernetes, itself and defaults, have become more hardened, the focus has moved to the supply chain.

Is there a Kubernetes security deficit?

To some, these issues point to a security deficit, but Sica disagrees, instead pointing out if you compare the Kubernetes security space from 2018 to now, it’s night and day. His view is that there’s never been more effort and focus on security within Kubernetes and the cloud native ecosystem, which is down to adoption and maturity. 

“Five years ago there was a proverbial gold rush to adopt Kubernetes because it was the pattern to follow in application development. People and organizations alike had to go through the growing pains of adopting what was at the time radically new technology.

“Now that there’s less of a scramble to learn about Kubernetes, there’s a greater focus on the stability of the codebase and creating secure defaults,” he explains. 

There are many examples of how the cloud native community is addressing security concerns. For example, the CNCF instigated a Kubernetes security audit. This raised concerns about network permissions and intra-component communications, which have been – or are in the process of being – resolved by the community. 

In terms of supply chain security, Sica mentions Chainguard has been working closely with the Open Source Security Foundation (Open SSF) in creating extensive tooling for the signing and verification of software artifacts. 

Another large focus in terms of security is extended Berkeley Packet Filter (eBPF). “Notably Sysdig's Falco project, which can use either a kernel module or eBPF probe to monitor/log any kernel-level calls that a container can make,” says Sica. “This is the next logical step in observing or preventing any privilege escalation or container escapes.” 

Strategies to boost Kubernetes security 

The majority of organizations with security concerns are taking steps to address them, and are seeking the services of a handful of vendors, which are focusing on some or all aspects of the security challenge.

“I don’t find that security is putting companies off going down this path, or from doing more in this area. They’re carrying on – but with a focus on having secure containers,” says Charlie Winckless, a senior director analyst at Gartner. 

Winckless recommends adopting a tool that validates the security not just of your containers, but your Kubernetes environment – and preferably a single tool that does both. 

He notes a growing number of vendors are moving into this area, with some companies including Sidero Labs and Tigera focusing specifically on container security, while ‘big picture’ cloud security posture management (CSPM) vendors such as Wiz, Aqua, Orca and Palo Alto Networks are adding container security features to their platforms.

“Some are very much focused on that bigger picture, while others are addressing those micro markets,” he says.

Beyond tapping into the market, organizations can take a number of steps internally to shore up their container security. Winckless’ top tip is to “automate, then automate, and automate some more”. “If you don’t,” he continues, “then trying to keep up with the dynamism of these environments is very difficult.”

He also recommends validating (and automating that validation) your setup in the same way you’d treat other cloud providers, and in some cases using a managed Kubernetes environment. 

“A lot of people are adopting EKS in Amazon, GKE in Google, AKS in Azure to have something where at least in my underlying Kubernetes environment, some of that security responsibility is delegated to a cloud provider.

“For the most part – exceptions include choices Microsoft made that led to the Azurescape vulnerability for example – we still see the large cloud providers able to a do a better job of it than you can.”