Admission Controllers Part II – Gatekeeper, an Admission Controller as Substitute for Pod Security Policies.
As mentioned in the first blog post, PSP will be deprecated in K8s v1.21 and removed in K8s v1.25 . Gatekeeper as Admission Controller that includes the Open Policy Agent is a great new choice to solve some security-related issues in your cluster. In this blog post, we provide you with a high-level overview of its architecture and its use case in the K8s.
First, we talk about the Open Policy Agent . It is the engine behind everything that evaluates incoming requests upon given rules and data. When a service receives a message and requires a decision on how to process it, the service could use the Open Policy Agent to request a decision, as shown in Figure 1. The Open Policy Agent takes in a query from the service and returns decisions based on data and a set of rules written in a logic programming language called Rego. In our case, the API Server of K8s is the service, and the webhook initiates a deputy to call the query against the Open Policy Agent to determine if the received API call is valid.
However, learning a new programming language is not a good idea only for a specific use case in your architecture due to the additional ramp-up phase of your staff and the distribution of knowledge to keep everything working even if your DevOps Engineers are not accessible. In addition, you may have to take care of the data that the Open Policy Agent requires for the decision. As a result, we provide you Gatekeeper as an implementation of the Open Policy Agent that solves the most common problems for K8s and admission controllers, including PSPs, out of the box.
Figure 3 shows the high-level architecture of Gatekeeper. Gatekeeper rolls out pods and webhooks in the cluster itself due to forward information about incoming K8s API requests to gatekeeper controllers. Gatekeeper wraps the Open Policy Agent and feeds it with all necessary information taken from the state of the cluster to make decisions.
As we already know, the Open Policy Agent requires rules to evaluate incoming requests. Gatekeeper delivers the Open Policy Agent rules by using templates and constraints. We will take a closer look at that in the last part of this blog post. For now, we only need to know, that this approach allows generating libraries, which is good for two reasons: First, the DevOps Teams are not required to learn Rego if they stay with existing libraries and want to use the Open Policy Agent as an admission Controller in their K8s-clusters. There is a library for PSPs from the Gatekeeper Project, for instance, that implements PSPs without any deep knowledge of admission controllers or Rego. Second, they can use the same library over more than one cluster, which makes Gatekeeper good for multi-cluster environments.
Furthermore, Gatekeeper provides rich and easy-to-use auditing functionality for existing rules. Regular admission controllers check for violations through API requests when a resource is added, changed, or deleted, giving you no visibility on resources that become non-compliant through policy changes. By contrast, Gatekeepers’ audit functionality allows you to scan the current state of your cluster and report existing violations. Finally, Gatekeeper is able to make findings visible in a console or in Prometheus monitoring.
After showing you the different use cases and functions of Gatekeeper in detail, we focus on the implementation of the rules in the form of templates and constraints in the next part of the block post. We will explain the easy-to-use-hard-to-master approach of Gatekeeper and create a possible implementation of Gatekeeper as a validating admission controller in a multi-cluster setup.
If you missed it here is the first part of this Blog series: Admission Controllers Part 1