Zero Trust Architecture in Kubernetes

Chapter 1. Authentication and Authorization

Zero trust is about making sure all data transmissions and interactions are authenticated at all possible vectors within your network. In order to deploy zero trust architecture (ZTA) for Kubernetes, we must understand how authentication and authorization work within the containerization platform.

A user in a Kubernetes cluster is defined as any user account that has authentication credentials and is granted a certificate that is controlled by either a human or a machine. A Kubernetes cluster can have two types of users: service accounts and normal users. Service accounts usually originate from within a Kubernetes-based system for use by internal services and are managed by Kubernetes; normal users are managed by an outside service. But because Kubernetes doesn’t have an object to represent normal user accounts, these accounts cannot be added to a cluster through an API call. A Kubernetes object is any entity that can be defined or configured with a YAML configuration file. I’ll expand on YAML configuration files in Chapter 3.

Authentication of Normal Users

You can set up Kubernetes to verify machine identities external to its cluster. Consumers will indirectly interact with machine identities (such as TLS certificates) wherever they go on the web, within and outside of Kubernetes. So external machine identity verification makes it possible for a consumer of your enterprise’s services to use your application securely.

Normal users can be authenticated through machine identities, meaning that if they have a valid certificate signed by the cluster’s certificate authority (CA), they are considered authenticated. This works much the same way CAs work in web apps without Kubernetes, through TLS and HTTP port 443 by default. When Kubernetes doesn’t manage a normal user, it’s assumed that the internal network has a cluster-independent service (a third-party service originating from outside the Kubernetes cluster) that manages a list of usernames and passwords, private keys from an administrator, and a user store such as Google Accounts.

Authentication of Kubernetes-Managed Users

Conversely, applications originating from within a cluster will authenticate with service accounts managed by Kubernetes and therefore can make calls to the API if they’re authenticated properly. API requests by Kubernetes-managed service accounts can use multiple authentication methods, such as bootstrap tokens, JSON Web Tokens, or client certificates. Each authentication module will be tried in sequence until one succeeds. This makes Kubernetes’ API compatible with a variety of different applications.

If a user fails authentication (regardless of its origin), it’s rejected with HTTP status code 401. If a user is authenticated, the next step is authorization. We know who you are. Now let’s determine what you’re allowed to do!

Authorization

To determine what a user is authorized to do, Kubernetes expects attributes that are common to REST API requests. This makes Kubernetes compatible with external access control systems that may handle APIs other than the Kubernetes API. Examples of API request attributes that work with Kubernetes include user, group, request path, and namespace, among others.

Once attributes are reviewed, it’s time to determine what the API request wants to do—POST, GET, and DELETE are examples of common API requests. With that, the Kubernetes API server can authorize a request with a particular authorization mode that suits your network’s security needs. Kubernetes supports role-based access control (RBAC) mode, attribute-based access control (ABAC) mode, Webhook mode (an HTTP callback), and node authorization mode, which grants permissions to kubelets based on the Pods they are scheduled to run.

Zero Trust Authentication and Authorization

In order for zero trust authentication and authorization to run properly in Kubernetes, your network needs service meshes and Ingress controllers. These components manage authentication through machine identities and are used to authorize requests to the Kubernetes API rather than delegate those security controls to the containerized applications and API server. There are also other useful functions that Ingress controllers and service meshes provide as a segment between the application and the API, including (but not limited to) service discovery, traffic management, and reading the state of your Kubernetes deployment.

Assuming that your Kubernetes system handles interactions between applications and from external networks (such as the internet), both service meshes and Ingress controllers are needed. The service mesh manages the east-west traffic between applications, and the Ingress controller manages the north-south traffic from your internal Kubernetes network to external networks.

Service meshes are designed to be used with Kubernetes to implement zero trust security. East-west traffic between applications within your Kubernetes cluster is often governed by a control plane, which in turn manages sets of data planes (otherwise known as sidecars in many implementations), which are responsible for traffic delivery.

Proper configuration of your service mesh, Ingress controller, CAs, and overall public key infrastructure (PKI) is crucial for automating authentication and authorization in Kubernetes effectively. It’s integral to your ZTA, facilitating robust security.

By acting as a gateway between other networks, your application, and the Kubernetes API, Ingress controllers and service meshes provide lots of useful functionality that makes cloud-driven applications run more smoothly and securely. By modifying the settings in your Ingress controllers and service meshes, you can change how your application manages network traffic, access control (more about that in Chapter 4), and authentication without having to change any application code. Developers can really appreciate that, because changing code in one script may mean having to change code in lots of other places and update the codebases of multiple services. Smaller application deployments may only use meshes and controllers for authentication, but there are a lot of additional automation features that can be very useful, even to the most complex DevOps.

Proper authentication and authorization management is crucial to effective application and network security. Controllers and meshes can make these functions much more effectively when implemented properly.

Let’s Review

Establishing effective authentication and authorization functionality is crucial to securing all computer systems, and Kubernetes is no exception. Zero trust architecture requires robust authentication and authorization at as many vectors as possible, regardless of the origin of users and traffic. Here are some tips to keep in mind:

• Review your current authentication contexts and roles. The principle of least privilege must apply whenever privileges are assigned to any human- or machine-controlled account. That means accounts have only the privileges they require in order to perform their work.

• Once your cluster’s API server is secured, make sure your application endpoints are secured. Review access via service NodePorts (an open port on every node of your cluster), port forwarding, or insecure Ingress routes. Kubernetes roles can secure the cluster but not necessarily your application.