Zero Trust Infrastructure for Kubernetes

Zero trust security is the buzzword on everyone’s lips today — and for good reason.

While the security model has been gaining traction in recent years, it quickly came to the forefront of everyone’s attention during the COVID-19 pandemic when stay-at-home orders spurred the sudden (and, for some, permanent) move to new remote and hybrid work models.

But it’s not just companies who are transitioning to remote or hybrid work that need to consider zero trust security; rather, it behooves all institutions, platforms, and infrastructures to turn their attention to these security principles. Particularly, for organizations with Kubernetes deployments, adopting a zero trust architecture will prove critical in ensuring security across all environments.

Kubernetes Security Challenges

Across industries, there’s an omnipresent cloud of pressure to be able to deliver software that can perform faster, more efficiently, and at a greater scale. Searching for robust portability and flexibility, many IT organizations have turned to Kubernetes (K8s) to help them efficiently meet these market demands.

But while K8s is a powerful solution for IT organizations to deliver their software efficiently and at scale, it is not without its own security challenges and vulnerabilities.

For one, simply because Kubernetes is a relatively new system, it is attractive prey for cyberattackers. This is compounded by the dynamic nature of its operating model, which can easily leave room open for bad actors to infiltrate if proper security measures are not taken.

Researchers from the Shadowserver Foundation found 380,000 open Kubernetes API servers that were exposed on the Internet this year alone. While these servers were only identified as exposed — not attacked — it is nonetheless a telling figure that indicates the vulnerability of and the potential danger to API servers.

In fact, Salt Security’s 2022 State of API Security reveals that 34% of examined enterprises have no API security strategy — even though 95% of them had their API security compromised in the last 12 months.

Zero Trust: Kubernetes’ Security Savior?

Faced with this frightening landscape, it’s clear that the industry needs a new solution to fortify Kubernetes deployments.

So, the question remains: How can organizations continue taking advantage of K8s’ many benefits while maintaining a strong security posture?

For many, it’s becoming clear that the answer is zero trust security.

What Is Zero Trust Security?

The zero trust security model was first developed by Forrester in 2009. At the time, it was a pioneering concept that turned the standard perspective of cybersecurity on its head.

With traditional security models, the status quo has long been “Trust, but verify.”

Zero trust security flips the script, instead, attesting, “Never trust; always verify.” This means that all users and devices must be indiscriminately checked and verified on an ongoing basis.

In the past, it was all about securing the perimeter. Once users were verified, they were granted access to the network and were generally trusted from that moment on once they were inside.

Zero trust means never establishing that moment of trust.

Instead, users and devices are always assumed to be compromised and so must be continuously authorized, authenticated, and attested in order to remain connected to the network or to take any action. This way, zero trust security’s preventative measures help organizations stay one step ahead of bad actors by always remaining cautionary and never letting their guards down.

Zero Trust Architecture for Kubernetes

The principles of zero trust security offer real solutions for Kubernetes security challenges — but achieving compliance presents a new challenge of its own.

It’s important to remember that zero trust security is simply a set of goals, not an exact tool; thusly, there are a number of different ways to achieve a zero trust architecture.

How, then, can the principles of zero trust be applied to Kubernetes?

It begins with securing the Kubernetes API server.

The server is the core of the control plane for each Kubernetes cluster. Because this API server is used to control all Kubernetes objects, ensuring secure API access is the cornerstone of securing controlled Kubernetes access and, thus, achieving zero trust Kubernetes.

In order to control and secure the API server, the first step is to moderate all incoming and outgoing traffic; this can be done via Transport Layer Security (TLS). Once all API server traffic is secured, Kubernetes provides all the necessary hooks to implement zero trust Kubernetes.

There are four main types of hooks, all of which are critical to successfully achieving zero trust architecture for Kubernetes: authentication; authorization; admission control; auditing, and logging.

Authentication

To uphold the zero trust security principles with Kubernetes, the first step is ensuring all users and services accounts are regularly authenticated. This means requiring authentication before any API call can be executed.

To achieve this authentication, organizations can turn to several available security models and plugins, e.g., client certificates, HTTP basic auth, and bearer tokens.

The zero trust model also recommends requiring multifactor authentication (MFA) to further double down security.

Authorization

Beyond having authentication, all users and services accounts must also have authorization.

This is a key principle of zero trust.

To maintain robust security, all users should remain limited in their actions — even after authentication. In other words, not all users should be allowed to do every task; rather, they should be granted just enough access to do what they need.

When it comes to zero trust Kubernetes, then, all users and services accounts who are accessing a Kubernetes cluster shouldn’t be permitted to perform just any action; instead, requests in Kubernetes should only be granted if the user (once authenticated) has explicit permission to carry out that requested task. To that end, each request should specify the requester’s username, the action that’s being requested, and the effects of that action.

Admission Control

Maintaining visibility into all users and actions is another important pillar of the zero trust model. This is why an admission controller is a key component of a zero trust architecture for Kubernetes.

With admission controllers, organizations can manage all requests that seek to create, modify, delete, or connect to any Kubernetes objects. Built-in admission controllers can help organizations implement actions and enforce their policies, while dynamic admission controllers can allow them to modify requests in real-time.

For a more refined security approach, it’s a good idea to employ multiple admission controllers in a system; there are many that are compatible with Kubernetes deployments, such as ResourceQuota and LimitRanger.

Auditing and Logging

In any genre of security posture, auditing is a foundational component of resiliency.

When it comes to zero trust for Kubernetes, auditing allows organizations to monitor all actions that are performed within Kubernetes clusters — those performed by users, applications, or even the control plane. Teams can then decide where they want to log these audited events, e.g., in the local file system or in an external logging system.

Proper auditing and logging practices also play a key role in ensuring Kubernetes infrastructures remain compliant with existing government policies.

Across diverse organizations, institutions, and platforms, zero trust security is emerging as a key player in cybersecurity health — and Kubernetes is certainly no exception.