In late January, the White House published a memo that lays the groundwork for creating a zero-trust architecture for federal agencies. With renewed attention from the US government, zero-trust networking is an area that many organizations are focusing on to improve their security posture. With that focus, it makes sense to understand where these principles can be applied to cloud native environments and, specifically, Kubernetes clusters.
A brief history of zero trust
Before getting into the specifics of how zero trust applies to Kubernetes, it’s worth looking at the history of this type of approach to securing networked systems, because it’s far from new.
In the early 2000s, the Jericho Forum in the UK advanced the concept of de-perimeterization of network resources, which suggested that organizations shouldn’t rely on perimeter controls, like network firewalls, to protect their applications and systems. Instead, each system should be properly secured and directly accessed.
In 2014, Google published “BeyondCorp: A New Approach to Enterprise Security,” which similarly looked at how an enterprise could move away from perimeter security and ensure that users and applications could make certain that callers were appropriately authenticated and authorized.
Now this year, we have the memo “Moving the U.S. Government Towards Zero Trust Cybersecurity Principles” from the White House, which again recommends that organizations shouldn’t depend on network perimeter defenses to protect critical data and systems.
As we see, for almost 20 years now, there’s been a consensus that organizations need to move away from a reliance on perimeter security. An obvious question might be, “Why are we not all already using zero trust networks?” There are a couple of answers here.
The first is that, in many cases, now we’re accessing things in a more de-perimeterized way than we did 20 years ago. The advent of cloud native systems and the heavy reliance on software as a service essentially have reduced the prominence of the traditional enterprise network and its associated perimeter firewalls.
But the fact that we keep seeing new initiatives makes it clear that we’re not at the end of this transformation yet. That is, at least in part, because it’s not as simple as it might seem to move to this kind of environment. Adapting systems that weren’t designed to be used in this way is a time-consuming task that must compete for limited engineering and security resources. Maya Kaczorowski’s recent article “BeyondCorp Is Dead, Long Live BeyondCorp” goes deeper into some of the reasons why this transition is so challenging.
A move to zero trust is not a binary prospect, and we can look at ways to move the dial away from reliance on perimeter networks and the concept of security not being important because services are connected to a “trusted” network.
Applying zero-trust principles to Kubernetes
Now that we’ve established the goal — reduced reliance on network perimeter controls — and some of the challenges in implementing it, what practical steps can organizations take to introduce zero-trust concepts into Kubernetes environments?
Service-to-service networking
The first obvious example is to look at the container network. By default, every Kubernetes cluster will provide a flat network where every container can communicate directly with every other container, with no restrictions. This container network is often treated as a trusted network by applications running in it, with services sometimes not requiring any authentication for requests that originate from within that network.
In the diagram below, we’ve got a range of services all connected to a cluster network. Not all of these will need to directly contact the others, but by default they can access each other at a network level.
There are a couple of approaches to improving this, from a security standpoint. The first is to enable Kubernetes network policies to apply default deny rules to both ingress and egress traffic in the cluster. Because network policies apply to workloads based on logical parameters (e.g., the namespace they’re deployed in and the labels applied to the workload), we can ensure that only associated workloads can communicate with each other.
So, in the example below, we might restrict the external website to only access the database server and logging service.
Even with those restrictions, our zero trust Kubernetes container will also need to do service-to-service authentication and authorization to ensure that only required resources are made available. For this, it’s likely that a combination of workload identity projects (like SPIFFE) and service mesh projects (like Linkerd) will be needed to have a fully zero trust environment for service-to-service communications.
User-to-service access
Of course, there’s another aspect to zero-trust Kubernetes that needs to be accounted for as well, which is user-to-cluster communications. Because Kubernetes itself doesn’t provide production-grade authentication options, external solutions will be needed again to fully realize a zero-trust vision.
One option would be to have a similar model to a service mesh, where user access effectively goes through some kind of a proxy service before hitting the Kubernetes API, where that proxy could apply controls based on things like device posture and request sensitivity. A recent example of this approach was shown by Kudelski Security Research, which leverages Cloudflare’s services and tunnel connections into its clusters via SSH.
Conclusion
It’s clear that the direction for many organizations is toward adopting a more zero-trust approach to network security. The bad old days when many organizations took the “warm Smartie” approach to networking (or “warm M&M” for those not in the UK), with a hardened perimeter combined with a soft interior, are numbered.
However, this will be a long process. While things like micro-segmentation and fine-grained authorization will help, as with any set of security controls, they’re only part of the overall picture. Implementing them doesn’t mean companies can stop considering all the other less visible parts of the security puzzle.