Admission Controllers Part I – Why do you need an Admission Controller, and how to start finding a good solution for them.

A lot of companies use Kubernetes to maintain the infrastructure and access to their services. Due to the operations and comprehensive functionality, it is essential to regulate and validate API Calls against the Kubernetes Master Nodes.

Pod Security Policies (PSPs) are a common way to define regulations inside your Kubernetes cluster, such as denying the use of the root users inside the pods or allowing only specific volume types in the cluster. However, PSPs depreciate with K8s v1.21 and will be removed in K8s v1.25 [1]. So administrators must plan new methods to enforce their game rules. The K8s documentation recommends using admission controllers as a substitute for PSPs. In this Blog Post, we introduce the Admission Controller as a substitute for PSPs and provide you with handy information to implement them into your Kubernetes cluster. Due to its complexity, we divide the topic into three parts:

In the first part, we create a compact overview of this topic. How do you identify the product that you need? What do you require to consider before setting up the first admission controller? The second part describes the architecture of Gatekeeper and the Open Policy Agent as one solution for an Admission Controller. It gives you a first understanding of the Admission Controller’s advantages and productive usage. In the last part, we present their different policies and possible use cases.

An Admission Controller is a feature of K8s that allows you to manipulate or deny K8s API requests before the target resource gets created, modified, or deleted. Webhooks connect applications to specific points of the executing pipeline in the K8s API Server. We differ two types of Admission Controllers: First, the Mutating Admission Controllers change the resource before it gets deployed. Second, the Validating Admission Controllers check if the changed, deleted, or created resource in the cluster fulfills user-given policies. Figure 1 shows the overall mechanism. We underline two important points in Figure 1: First, all Admission Controller modifications happen after the user’s authentication and authorization. So the Admission Controller is not a tool to restrict access to your API Server or to define what a specific user is allowed to do or not. Second, the validation happens after the mutation. If you use a mutating Admission Controller that adds a specific resource, such as a sidecar for your pods, you can validate separately for it.

So Admission Controllers can add resources that the user did not define in their manifest or can enforce settings inside the manifest of the users. This way, they decisively define how the cluster works by validating its components after given rules. As a result, you can use the Admission Controller to solve some high-risk security gaps inside the deployment manifest, such as allowing to use of the root user inside a container. By identifying insecure field definitions or missing fields in the deployment manifest, the admission controller prevents some insecure settings of pods and containers. PSPs solved this issue until K8s v1.21. This makes using an Admission Controller in K8s almost mandatory for safety reasons.

Before you start implementing a solution after noticing the value of an Admission Controller, you should take your time to think about what your expectations are and what limitations you really need in your cluster. Additionally, you require knowledge about the allocation of rules inside the cluster. I.e., do you want to define policies only in specific namespaces? After that, you should choose your Admission Controllers corresponding to previous findings.

Currently, there are two popular Admission Controllers that we want to mention here very briefly. Kyverno is an Admission Controller that is easy to use but lacks a wide range of fine-grained implementation techniques for rules. On the other hand, Gatekeeper is a more widespread solution that comes with more possibilities to manipulate the behavior. It embeds the Open Policy Agent to validate against rules that the user himself can even write. As a result, Gatekeeper is more of an easy-to-use hard-to-master solution but comes with a high variety for different use cases. Nevertheless, Gatekeepers Mutating Admission Controller functionality is in beta, while Kyverno has a working implementation at the time of writing. After all, the right decision for an Admission Controller depends on your needs.

In the next part of this blog post, we show Gatekeeper as a possible solution for a validating Admission Controller to replace and enhance the functionality of Pod-Security Policies.