Introduction

Effective zero trust architecture is needed now more than ever. Even the United States government, through a White House Executive Order published in May 2021, acknowledges this:

“The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including software as a service (SaaS), infrastructure as a service (IaaS), and platform as a service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.”

What’s needed to secure the public sector is just as necessary for the private sector. Kubernetes is now essential in the ever-growing SaaS, IaaS, and PaaS spaces. So creating a zero trust architecture designed to secure Kubernetes is vital to addressing enterprise cybersecurity needs in the 2020s and beyond.

It’s time to get candid—securing Kubernetes is no walk in the park. Containers may have a lifespan of mere days. Different cloud platforms have different networking and security tools, and each platform has a unique API. Your public key infrastructure (PKI) in the cloud needs to assign and revoke machine identities at a rapid pace, most often in the form of certificates.

The State of the Cloud

The amount of cloud infrastructure your application needs can increase and decrease quickly, making scalable security solutions an absolute must. And although some developers and cybersecurity professionals have decades of experience, these technologies are still relatively new. Google Cloud Platform was launched in 2008 but has evolved immensely in the years since. The Amazon Web Services (AWS) cloud is a couple of years older, but the same applies. And Kubernetes was born in 2014. Even Craig McLuckie, Brendan Burns, and Joe Beda, Kubernetes’ creators, don’t have 10 years of experience with it as of this writing.

Perimeters, the Obsolete Way

As far as network security in general is concerned, threat boundaries used to be tied to machines. But now systems are much more complex and everyone is a potential threat actor.

In the traditional perimeter security model, your network is a collection of trusted servers, endpoints, applications, and users. Authentication vectors are set at the perimeter where your internal network ends and the internet and other external networks begin. That may have worked well enough in the 1990s, but now network computing and application design are radically different.

The Need to Adapt

The advent of the cloud and bring your own device (BYOD) was an immense sea change. Cloud platforms have made it much easier for enterprises to deploy applications and services to their end users and employees wherever they happen to be physically. The cloud has also empowered enterprises to deploy applications with scalability and agile-like flexibility.

It used to be that if an organization needed more bandwidth and capacity, it had to buy more servers and networking infrastructure, plus the building space to house all of it. And if an application needed less capacity or different hardware, an expensive number of machines and networking infrastructure would have to go unused. That’s one of the reasons why organizations seldom have entirely on-premises networks these days. Enterprise networks that are completely on the cloud or on a hybrid cloud is how things are done now. That adaptability has revolutionized everything.

Zero trust is a security model and philosophy that makes it possible to secure today’s and tomorrow’s cloud networking environments. Your data assets in the cloud and through the internet need to be just as visible and securable as your data assets on premises! Therefore, no endpoint, server, application, or service should be automatically trusted based on its location in your network. Everything must be verified and authenticated as frequently as possible. This applies as much to east-west traffic (between internal applications) as to north-south traffic (between internal and external networks). And because zero trust is applied in all directions, it improves the security management of your applications and data assets regardless of their origin. Zero trust means no machine or user is trusted by default.

The Advent of Kubernetes

Kubernetes is such an important platform because it makes it possible for enterprises to deploy their applications in a fully scalable and dynamic way through the power of containerization. Before containerization and virtualization became common in the datacenter, the usual model was to run multiple applications on the same dedicated server hardware. It was the best that could be done with technology at the time. But that use of computing resources led to frequent downtime and overall poor performance. For instance, it was easy for one server application to use far more memory and CPU cycles than other applications.

When the Kubernetes platform was introduced in 2014, it made it much more feasible for developers to deploy their applications through containerization. That way, all applications (which should ideally have maximum uptime) could be assured of the resources they need in order to run well at all times.

Once developers and networking professionals got more experience working with the cloud and Kubernetes, enterprises could deploy their applications much more effectively. The cloud and containerization provided developers not only with better uptime and reliability but also with the ability to be immediately responsive to the needs of their customers, clients, and supply chains with tremendous scalability. Given that applications can change rapidly, making sure every part of an application has as much hardware capacity and bandwidth as it needs at any given time has been nothing short of revolutionary. And an enterprise can see that in its bottom line.

How Kubernetes Works

Technological innovation has improved business, but the innovative nature of Kubernetes requires a different approach in order to secure it properly. Containerization is a relatively new technology, having only been in common use for about a decade. And Kubernetes has been a major influence in popularizing containerization. Some organizations have made mistakes, such as not integrating their PKI with as many network vectors as possible or forgetting to use security controls that cloud platforms (such as AWS) provide to developers.

While virtual machines simply virtualize a computer and run multiple applications within it, Kubernetes has a container runtime layer in which an unlimited number of containers can run. The container runtime simplifies how data is exchanged between applications. But once an external data transmission enters the network and the API, that transmission has seamless access to all the containers in the Kubernetes system. And just as that external transmission can access anything in the container runtime, so, too, can the containerized applications within the runtime interact with one another.

What makes Kubernetes so powerful also makes a completely different security philosophy absolutely necessary. You don’t want an attacker to have easy access to everything! Ransomware attacks and data breaches can cost organizations millions of dollars per incident in application downtime, reputation damage, litigation, and regulatory fines.

That’s why zero trust architecture is an absolute necessity in order to deploy Kubernetes securely. With zero trust architecture, all the components of your Kubernetes system are secured by default. Nothing interacts with anything else without proper authentication, authorization, and nonrepudiation.

The Kubernetes platform is designed to be compatible with Ingress controllers and service meshes. An Ingress controller manages network traffic between your internal network and external networks by load-balancing and authenticating the traffic. A service mesh manages network traffic internal to your network, allocating some network resources and managing authentication inside your application. These powerful tools within your Kubernetes network can manage all your machine and user identities to ensure consistent authentication of everything. Applications and APIs are freed from that work, making compliance and security policy application much more effective. Kubernetes gives enterprises the power to take full advantage of the cloud in their application deployments. And to prevent and mitigate a plethora of cyber threats in today’s rapidly evolving threat landscape, the support of zero trust architecture is essential.

The National Institute of Standards and Technology (NIST) defined how zero trust architecture (ZTA) should work in its SP 800-207 standard. Let’s summarize some of the standard’s concepts and how they apply to Kubernetes.

In Section 3.1 of the SP 800-207 document, NIST defines three requirements for ZTA. The first is that ZTA is designed using network infrastructure and software-defined perimeters when it’s applied to a Kubernetes-based application. As per the document:

“When the approach is implemented at the application network layer (i.e., layer 7), the most common deployment model is the agent/gateway (see Section 3.2.1). In this implementation, the agent and resource gateway (acting as the single PEP and configured by the PA) establish a secure channel used for communication between the client and resource.”

Kubernetes works best when Ingress controllers and service meshes manage authentication. Therefore, those components serve as the security gateways, keeping that work away from the Kubernetes API and the applications that are run from containers.

The second requirement, covered in section 3.4.1, concerns network requirements for supporting ZTA.

A fundamental requirement is basic network connectivity. Your application needs to acquire traffic through an external network and within your internal network. That usage, plus authenticating and authorizing their associated requests to the Kubernetes API, requires network connectivity. Some additional requirements, as they pertain to Kubernetes, will be covered in this report.

The third requirement is that the enterprise must be able to distinguish between what assets are owned or managed by the enterprise and the devices’ current security posture. Authentication and authorization determine the identity of users and machines and decide accordingly what they’re allowed to do. Integrity ensures that data and configuration settings within your Kubernetes application are only altered by authorized entities. And maintaining an observable state makes it possible to verify your application’s security posture.

Table I-1 summarizes how the requirements in the NIST SP 800-207 standard can be applied to your Kubernetes application.

Table I-1. NIST SP 800-207 pragmatics
Requirements Applications
“The enterprise can observe all traffic.” Maintain an observable state based on logging, metrics, and traces.
“Enterprise resources should not be reachable without accessing a PEP (policy enforcement point).” This is assured with proper Ingress controller and service mesh configuration.
“The data plane and control plane are logically separate.” This is managed by Kubernetes’ design. The Kubernetes control plane includes the API server, scheduler, and controller managers. The data plane consists of nodes and their containers.
“Enterprise assets can reach the PEP component. Enterprise subjects must be able to access the PEP component to gain access to resources.” This is managed by Ingress controllers and service meshes.
“The PEP is the only component that accesses the policy administrator as part of a business flow.” This is why your Ingress controller and service mesh should manage authentication and authorization within your ZTA Kubernetes network, not the nodes, containers, or other Kubernetes components.
“Remote enterprise assets should be able to access enterprise resources without
needing to traverse enterprise network infrastructure first.”
This is taken care of with a properly configured Ingress controller.
“The infrastructure used to support the ZTA access decision process should be made scalable to account for changes in process load.” This is another reason why the Ingress controller and service mesh should manage security in your Kubernetes system.
“Enterprise assets may not be able to reach certain PEPs due to policy or observable factors.” This can be assured with proper Ingress controller and service mesh configuration, and by assuring an observable state.

So let’s get started!

Get Zero Trust Architecture in Kubernetes now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.