Intro
Admission control is an important, Kubernetes-native option for enforcing policy on your containers and overall Kubernetes environment. But there are tons of flavors and ways to do it, and candidly, very few actually enforce admission control in their production environments because, well, it can break production. So what are the key factors to look at when evaluating the practical benefit of an admission controller?
What is an admission controller
At a glance, admission controllers provide access control to users and applications within a cluster. They allow administrators to set various policies including which users can add or delete objects in a cluster, as well as which applications can be deployed to the clusters.
Admission controllers are typically used to ensure that only safe code and configurations are allowed into the production environment. By intercepting and validating requests to the Kubernetes API before they are allowed to persist in runtime in the cluster, admission controllers mitigate risks associated with unauthorized actions, malicious entities, or erroneous configurations. This preemptive policy enforcement ensures that only safe and compliant workloads are deployed.
In practice, admission controllers wield great versatility, facilitating an array of custom policies tailored to specific organizational needs. They can be leveraged to validate resource requests, evaluate labels and annotations, assess resource quotas, and even trigger webhooks for more advanced validation scenarios. By offering this flexibility, admission controllers significantly enhance the platform's resilience and overall security posture. Kubernetes even provides Kubernetes Pod Security Admission, with three levels of restrictive policies.
Mutating Webhook Admission Controller
A mutating webhook admission controller intercepts and processes incoming requests to the Kubernetes API server before they are persisted to the cluster. The primary function of a typical mutating admission controller example in Kubernetes is to modify (mutate) the content of the resource being created or updated.
This is generally an intrusive option that does not allow for close management of what gets deployed to production, as the mutation is automatic and the enforcement of the policy in the first place has the potential to bring down production.
Kubernetes Validating Webhook Admission Controller
A Kubernetes validating admission controller, on the other hand, focuses on validating and potentially rejecting incoming requests before they are persisted to the cluster. Its primary role is to assess whether the request complies with the defined policies and standards of the cluster. This is much less intrusive than a mutating admission controller because it’s results are generally binary; deploy the workload or not.
What are the different types of admission controllers?
There are multiple platforms available for building kubernetes clusters. The platform you are using influences the way you should approach admission control.
OPA admission controller: OPA (Open Policy Agent) is based on Rego, and is used often by teams that want to amass a large, ever-changing rule-set that can be queried, QA’d, and managed separate from the Kubernetes resources themselves. Policies are not restricted to allow/deny or binary answers, and checks on a policy can result in structured output with lots of context.
Kyverno admission controller: Kyverno does not use Rego, it relies on YAML, and so it is easier to use than OPA from that perspective. However, managing Kyverno policies at scale is difficult because you cannot decouple the policies from the Kubernetes resources to which they apply.
JSPolicy admission controller: JSPolicy is a less popular choice than Kyverno and OPA, using JavaScript-based validation for resources being created on a Kubernetes cluster.
You also create your own admission controller.
Managed Admission Controllers
Let’s look at another type of Kubernetes admission controller example.
The configuration of admissions controllers differs slightly when used with managed Kubernetes offerings such as EKS and GKE. In these environments, many of the admission controllers are already pre-configured within the platform, making it easier for developers to quickly get their applications up and running on a cluster.
That being said, EKS admission controllers offer support for OPA, Kyverno, Kubewarden, JSPolicy and other similar solutions. GKE admission controllers integrate with OPA and Kyverno to provide access control policies out of the box.
Kubernetes Webhooks
Webhooks differ from admission controllers in that they are only triggered when a request is received by the cluster. A webhook enables developers to tailor specific instructions when creating new resources on a Kubernetes cluster. It acts as an interface between your application and the Kubernetes API server, allowing for custom validation rules such as resource quotas, authentication requirements, or admission control policies.
Admission controllers, however, run every time someone attempts to create or modify a resource on the cluster.
Pros and Cons of Kubernetes Admission Controllers
Admission controllers offer various benefits when it comes to providing access control to your Kubernetes clusters, including real-time validation, authentication enforcement, and policy enforcement. After all, if a resource is created without the proper authorization or validation required by an admission controller, it could create security vulnerabilities within your system.
However, most teams simply don’t turn admission controllers on, even if they have the capability to do so. Many well-meaning teams define the policies and go to enforce them, only to find that when they do, their production environments go down and their development teams are not prepared to understand the consequences of deploying containers that violate admission control policy.
Suffice it to say that using admission controllers can add complexity to the overall system architecture and may require additional resources to be allocated.
The teams best equipped to work with admission controllers in enforcement mode are those that have worked hard, between DevOps and Security, to define the policies, and who have done lots of practice and testing to understand the consequences of enforcement in any environment.
Evaluating a Kubernetes Admission Controller: the Checklist
Given this context, what do you need in an admission controller in order to be successful? Here is a checklist to help you rate vendors’ admission control options and understand whether you are getting something useful, or something you will pay for but never operationalize.
- How transparent are your admission control policies?
- Does the vendor keep the Rego policy in a black box? Is it labeled as ‘proprietary’? This can be an issue when you need to customize policies for your own environment. If you are able to transparently view - and even change - the Rego policy as you see fit, your engineers will be more comfortable with the policies you are enforcing and your most advanced teammates will feel they are in control of any downtime in production caused by admission control.
- Can you set them in the CI/CD process across multiple clusters?
- One of the issues with using the open source version of OPA (or any other admission controller) is the management and implementation across dozens (or even hundreds) of clusters. Quickly, the duplication and QA process becomes overwhelming to the point that admission control is no longer a practical option. However, if admission control policy creation can be folded directly into the regular GitOps, or CI/CD process, quickly the team will be able to scale across multiple clusters and environments, and the engineering team will have access to the policies themselves, which will reduce back-and-forth between engineering and security.
- Can you do a dry run before you enforce anything?
- Admission control will block a workload before deployment which, in some cases, can break production. It is critical to have an understand of what is going to happen before it happens. Can your vendor get a view to share with engineering of what workloads would be blocked, based on the policies in place? If not, it will be a rocky road getting to actual enforcement.
- How broad is the set of criteria available for enforcement?
- Some admission controllers are based only on one risk factor, such as critical or high-rated image CVEs. The breadth of criteria available for enforcement is something to check on ahead of time; do they take into account Kubernetes misconfigurations, at a minimum?
- How does the policy validation occur?
- Is the vendor requiring you to send data somewhere else in order to make a policy decision? This is worth checking, especially if you have a broad set of criteria you want to enforce. Do they use OPA, do they use Kyverno? This is important to understand, at a minimum in light of understanding the vulnerabilities your admission control will be subject to. For example, there was a recent Kyverno CVE that required a breaking update. You will want to know what third-party risks you are exposed to.
KSOC Admission Controller Configuration with KSOC
At KSOC, we understand the dynamic between the engineers managing Kubernetes and the security teams trying to secure it; in most cases, both teams are focused on security to some extent. KSOC’s admission controller capability is created to help security teams make Kubernetes secure by default in partnership with their engineering colleagues, with:
- Transparent policies: All Rego policies are transparent and visible in-cluster (we are OPA compliant)
- Setting policies across multiple clusters: We integrate with GitHub Actions to set policies for both detection and admission control within the CI/CD pipeline
- Dry-run: Instead of going straight to enforcement, you can get an easy list to share with engineering of policies that you would have blocked
- Criteria: We use a broad range of criteria, across Kubernetes configurations and other Kubernetes components
Our threat vector capability also allows you to immediately triage risk across your clusters, which will help tremendously in deciding which admission control policies to set in the first place. Contact us for a demo to see how you can get real-time, event-based visibility alongside admission control with the KSOC platform.
Conclusion
Admission controllers are powerful in the context of Kubernetes Security, but are difficult to implement from a practical perspective, given team dynamics and sensitive environments. Use this checklist to quickly get to the root of whether or not a vendor’s admission control capability will allow you to operationalize Kubernetes security in the way you need.