Red Hat: Human Error a Leading Cause of Kubernetes Security Mishaps

When Red Hat acquired StackRox, you might have wondered whether StackRox’s semiannual report on the state of Kubernetes security would survive. Worry no longer, Red Hat will continue to produce the State of Kubernetes Security Report. Worry instead about how often we stumble over Kubernetes and container security incidents.

How bad is it? It’s awfully bad. 94% of respondents stated they have experienced a Kubernetes and container environments security incident in the last 12 months. Worse still, more than half of respondents, 55%, ended up delaying Kubernetes application production developments due to security screw-ups over the last 12 months.

Can you say “Ow!” I can.

What’s the root cause of all these failures? It’s not nasty old hackers attacking. Oh no. We’re doing it more often to ourselves. Nearly 60% of those surveyed said human error was the cause of data breaches and failures. In particular, most have experienced a misconfiguration incident within the last 12 months.

We simply don’t have anything like enough people who really understand how to deploy Kubernetes properly, never mind enough professionals who know how to secure it. As Charlie Fiskeaux, UX leader at monitoring company Circonus recently observed, “Kubernetes monitoring is … complicated. Knowing metrics on cluster health, identifying issues, and figuring out how to remediate problems are common obstacles organizations face, making it difficult to fully realize the benefits and value of their Kubernetes deployment.”

The reason for this is that configuration management poses a uniquely difficult challenge for security experts. While there’s a host of tools available for vulnerability scanning of container images, configuration management requires you to juggle many balls. Sure, people know that they should avoid deploying the Kubernetes dashboard — you do know that right?  But configuring a pod’s security context or implementing Kubernetes role-based access control (RBAC)? That’s not so easy.

In addition, those misconfigurations have resulted in major vulnerabilities being discovered nearly a third of the time. While another third said they’ve suffered a runtime security incident. And, mind you, these are only the problems a company’s cloud-native developers and administrators found before the programs were deployed. We shudder to think what security holes may exist out in the wild waiting for a hacker to find them.

Organizations worry the most though about runtime problems. At first glance, this seems counter to the overwhelming majority of respondents identifying misconfigurations as the source of the most common and biggest security risks. However, it makes more sense when you consider that runtime security issues show up because runtime security lapses are the result of those self-same build or deployment misconfigurations. And, of course, only your team may know about a problem at those earlier stages. But everyone can see when there’s a foul-up once an application is running in production.

Nevertheless, only 47% of survey respondents worry about exposures due to misconfigurations in their container and Kubernetes environments. I’d be worried sick myself.

The answer to this? Red Hat suggests, and I agree, “The best way to address this challenge is to automate configuration management as much as possible so that security tools — rather than humans — provide the guardrails that help developers and DevOps teams configure containers and Kubernetes securely.” There’s simply no way ordinary mortals — or extraordinary ones for that matter — can manually stay on top of an ever-evolving and changing cloud native application and its environment.

Whose job is this? A plurality of people put the onus of managing security squarely on DevOps shoulders. 15% of respondents consider developers as the primary owners of Kubernetes security, with only 18% identifying security teams as being most responsible.

If you think about it, this makes sense. DevOps are usually the ones driving containers and Kubernetes adoption so they get the responsibility for securing them as well.

Mind you there is one little problem. Developers and administrators aren’t security pros. Red Hat believes that to truly secure a Kubernetes environment, “it takes a village.” By that, they mean “container and Kubernetes security tooling must facilitate close collaboration among different teams — from Developers to DevOps to Ops to Security — instead of perpetuating the silos that may plague organizations.”

May? Perhaps you work at a Shangri-La of a company where all of IT works in perfect harmony. I’ve just never seen it myself. Still, at the very least, whoever’s in charge of Kubernetes at your company needs to make friends with security. You’ll be much better at it. The survey found the vast majority of respondents have some form of DevSecOps initiative underway. You should follow their example.