Zero Trust Architecture in Kubernetes

Chapter 4. Minimal Access in Size

Now let’s discuss how to reduce your cyberattack surfaces as much as possible. A useful paradigm is the principle of least privilege. Every single user, application, and machine within a computer network must only have access to what’s absolutely necessary for operation and nothing more. For example, in a role-based access control (RBAC) system, only the financial user groups can access the financial data servers, only administrators can modify configuration files, and so on.

RBAC isn’t merely an effective security control in computer networks in general. It’s strongly recommended in Kubernetes networks specifically. Sometimes accounts for human users will be assigned roles. But in Kubernetes, you’ll also be focused on the roles assigned to Pods, applications, machines, and other nonhuman entities. I’ll get into RBAC implementation in Kubernetes in greater detail soon. For now, let’s get back to the basics.

Granting any entity more access than is absolutely necessary increases the possible cyberattack surface if a malicious agent acquires unauthorized control of said entity. In addition to malicious activity, security incidents can be caused by human error and application bugs. Therefore, we design our systems so that if something goes wrong, as little damage as possible will result. And every experienced network administrator and application developer knows that lots of things will inevitably go wrong.

Reducing Access in Size

In implementing zero trust architecture (ZTA) for your Kubernetes-based applications, one important way to ensure the least amount of damage from a security incident is to allow access to the smallest amount of data as possible. The most fundamental way to do this is to limit access to hardware resources. Namespaces are an instrument for this. In Kubernetes, namespaces are used to delegate hardware resources to clusters. A cluster can have multiple namespaces if necessary. If your Kubernetes deployment needs to serve lots of users spread among multiple projects or teams, your clusters will need more than one namespace.

Namespaces aren’t only for hardware resource management. They are also used as a fundamental unit of isolation for name collisions, authorizations, and the like. Make sure your namespaces have a defined limit for how much memory they can access. Memory footprints will grow and shrink frequently, and you don’t want them to completely take over your hardware. Imagine if something went haywire in one of your clusters. It could happen!

You can create namespaces for your clusters by using kubectl at the command line. Kubectl is one of the most important programs for managing all Kubernetes deployments. Keep in mind that each node in your cluster must have at least 2 GB of memory. Don’t be too stingy!

Kubernetes uses YAML for all configuration files. LimitRange is a Kubernetes object that can be defined in a YAML file to restrict memory usage. It’s also prudent to limit the CPU usage of your namespaces. LimitRange can be used in a YAML file for that purpose as well.

Those are the basics of restricting the size of what can be accessed as far as your clusters and their hardware usage is concerned. Next, we’ll talk about limiting the amount of data through RBAC.

Role-Based Access Control

You can limit the amount of data that can be accessed at the filesystem and application levels through effective implementation of RBAC as it’s defined in the Kubernetes API. There’s an API group within the Kubernetes API specifically for making authorization decisions through RBAC: rbac.authorization.k8s.io. In order to use RBAC, it must be included in a list in the authorization mode flag when you start the API server at the command line.

Four types of Kubernetes objects are declared in the RBAC API: Role, ClusterRole, RoleBinding, and ClusterRoleBinding. The Role object is used to set permissions to namespaces, of which a cluster can have one or many. The ClusterRole object sets permissions for—you guessed it—the clusters themselves.

Permissions associated with those objects are defined by combining verbs (get, create, delete) with resources (Pods, services, nodes). Kubernetes comes with a set of out-of-the-box roles that can be used for common Kubernetes RBAC needs, but you may also need to set up your own custom roles. Remember that you’ll have to set up node authorizers in addition to authorizers of your roles in the Kubernetes API.

The RoleBinding and ClusterRoleBinding objects work with the Role and ClusterRole objects to grant the permissions defined by the latter two objects to users or groups of users.

As with authentication, simple and broad roles may be appropriate for smaller clusters, but as more users interact with the cluster, it may become necessary to separate teams into distinct namespaces with more limited roles. As a general rule, the fewer users you have, the broader the permissions granted to your clusters and namespaces can be. But if your Kubernetes implementation has a large number of users, clusters, and namespaces, you will need to define roles with more specific permissions and restrictions. No matter what, the principle of least privilege applies: no user, cluster, or namespace should have permission to access more than is necessary for proper operation.

To complement RBAC in Kubernetes, it also helps to understand Pod Security admission. It’s possible and often necessary to define different isolation levels for Kubernetes Pods.

Pod Security admission is based on three security levels defined by the Pod Security Standards: privileged, baseline, and restricted. The privileged level is unrestricted; use this level as sparingly as possible, because threat actors can exploit privileged Pods for privilege escalation attacks. The baseline level applies the default privileges as defined in the Pods’ parent security policies. The restricted level is often the best to use as long as it doesn’t conflict with your application’s needs. This level assigns heavily restricted privileges following current Pod-hardening best practices.

Exemptions in your Pod Security admission can be applied to Usernames, RuntimeClassNames, and Namespaces in your Admission Controller configuration. Refer to the official Kubernetes documentation for more help with applying RBAC to Pods.

Let’s Review

RBAC is possibly the most straightforward way to design the principle of least privilege in a computer network. Fortunately, Kubernetes has RBAC support built in. Understanding how you can assign privileges to Pods, users, and other Kubernetes entities is key.

Here are some things to consider:

• Have you reviewed your use of resources? Not only can you use LimitRanges, but there are resource limits for each Pod in the pod spec and ResourceQuotas to explore.

• Pods can also be assigned various levels of isolation. The original Pod Security Policies were deprecated in v1.21. Familiarize yourself with Pod Security admission and refer to Kubernetes documentation for further help.