Securing Kubernetes as it becomes mainstream

In this interview with Help Net Security, Shauli Rozen, CEO at ARMO, talks about securing Kubernetes (K8s) systems, what makes them susceptible to cyberattacks and what should organizations expect when deploying them.

As every other platform, Kubernetes is susceptible to cyberattacks. What drives cybercriminals to target Kubernetes and what do they hope to gain?

That’s a question that is best answered from an attacker’s point of view. So, what are attackers looking for? They are looking for targets. And how do they choose their target? By a combination of two key parameters: 1) the value of the target 2) how easy it is to attack it.

High value targets – as Kubernetes becomes more mainstream, used by more companies, in more environments, it is now placed in places with high value, it is no longer just in a small workload somewhere, a test application, or a “software playground” – it is right there in the core of production environment and in an extremely fast rising number of organizations.

Easy to attack – the biggest factor in the potential ease of attacking Kubernetes-based system is not in the underlying technology vulnerabilities, it is in the mere fact that it is new. Attackers love new systems, which organizations do not yet know how to configure in a secure way, that organization are adopting quickly and maybe security is not keeping up with the tech change.

To top that, Kubernetes is a pretty complex system, and it is usually running microservices-based architectures, which by nature are more complicated, have more APIs and a proliferation of software artifacts that are continously changing – which naturally increases the attack surface.

In its Spring 2021 report on the state of Kubernetes security, RedHat notes that 94% of survey respondents had experienced a security incident in their Kubernetes environment. And that the main cause of these incidents was misconfigurations and vulnerabilities. This is largely because alongside its rapid adoption, K8s is still evolving.

What does the process of building Kubernetes security look like?

The first advice I would give a company building a process of securing Kubernetes is this: let the people who know the ins and outs of Kubernetes be in charge of the process. Sounds trivial but it is not always the case. Kubernetes-based environments require more than ever to separate policy from technology and making security an engineering policy more than anything else.

Then, the process should be focused on two main aspects of security and operation. First – Kubernetes security posture management (KSPM) – the process, methods and controls of scanning, finding and fixing software vulnerabilities as early as possible (during the CI pipeline), to prevent them from reaching production. The objective here is to minimize the attack surface and to harden the K8s environment as much as a possible. Second – runtime protection – the process, methods and controls of detecting and preventing cyberattacks when they happen (in most cases – during production). The objective here is to maximize the resiliency of the K8s environment to cyberattacks.

I see most companies starting from the KSPM part, and I think it makes sense, it is faster to do, closes a gap, and requires less impact on production environments. When looking into the security configuration of Kubernetes and getting guidance on how to do it right, there are a few frameworks and documents that were published by strong organization that could be used, and several open-source tools that have been created to make testing against these frameworks easier.

What’s the difference between managed and on-premise Kubernetes? Would you recommend one over the other and why?

On-premise Kubernetes is a good option for organization who are not in the public cloud but do want to experience the benefits of cloud technologies and microservices architectures. It basically means that you need to deploy your own Kubernetes system, manage it, configure all aspects of it, update it, patch it, etc. Honestly, this is not easy to do and I have seen several organizations starting the process and never finishing it.

Managed Kubernetes puts much of that burden on the managed Kubernetes supplier and lets you, as an organization, focus on your workloads rather than the infrastructure. I personally would opt to those options if I did not have other limiting factors (like an organizational policy not to use public clouds).

What are the essential processes required to guarantee a secure Kubernetes deployment?

As a DevOps and automation advocate, it is hard for me to define organizational processes, I think the future is not there, so I will refer more to CI/CD processes and automations that are required rather than organizational processes. The most essential part of any process is to connect security requirements into the CI/CD process and make them easily available to developers and DevOps professionals.

When a new security requirement comes up, it should be added in a central place and propagate automatically down the CI/CD to help the Dev organization figure out as early as possible the impact of that requirement on their processes and help them comply with it without needing to continuously change and update their automation processes.

What are the realistic improvements for Kubernetes security we could expect in the near future?

I believe the most dramatic impact on the security of Kubernetes will not be technical, but behavioral, as Kubernetes becomes more mainstream the configurations of clusters will go through more scrutiny, developers, DevOps and architects will be more aware of the potential risks they can add to the system. This will result in less configuration mistakes, and a significant reduction to the attack surface.

In terms of technology, I am expecting more native security controls and guidelines coming from the Kubernetes SIG Security group that will be aligned with the recent advancements like the changes in the POD Security Policy to make it more usable and friendly.