What Is Kubernetes Admission Control?

Kubernetes admission control is a mechanism that validates and modifies requests to the Kubernetes API server before they are processed. Admission control can enforce policies, security rules, resource limits, default values and other elements of the cluster’s use. This mechanism can also reject requests that violate certain rules or conditions.

This post discusses Kubernetes admission control, the plugins that make it possible and how webhooks can extend the functionality of admission control with custom logic.

What is an admission controller in Kubernetes?

A Kubernetes admission controller is a piece of code (plugin) that makes it possible to govern a cluster’s configuration changes and deployments. A K8s admission controller can be considered a gatekeeper that intercepts API requests, changes the request object or denies the request altogether. The evaluation happens after the API server has authenticated and authorized the request but before the request is granted and implemented. 

Why do we need admission control for Kubernetes?

K8s admission controllers offer several benefits for managing your cluster:

• Security: A Red Hat report found that nearly 93% of respondents had experienced a Kubernetes security incident in 2022. Admission controllers provide additional protection for your Kubernetes deployments. With various security-related admission controllers available, these tools can help ensure that only trusted pods and resources can run in your cluster and reduce security risks.
• Consistent enforcement: By setting default values and policies for resources, such as storage classes, namespaces and service accounts, these controllers ensure that all resources created in your cluster adhere to the same rules and best practices. This capability can prevent mistakes or oversights that could cause downtime or other issues in your cluster.
• Customization: Admission controllers are highly customizable, making them a powerful tool for enforcing policies and requirements specific to your organization. You can use third-party dynamic admission controllers to implement custom policies and conditions or create your own. 
• Compliance and guardrails: Kubernetes admission control enables centralized enforcement of company-wide or cluster-wide compliance standards and security best practices across multiple namespaces and clusters. These plugins can ensure that all pods have labels, annotations, secrets and service accounts that comply with organizational policies.

How the admission control process works

The admission control process consists of two phases: first, all mutating admission controllers are executed in order; then, second, all validating admission controllers are executed in order. Admission controllers can act as mutating, validating or a combination of both.

The order in which admission controllers are executed matters. Some admission controllers depend on others to function properly. For example, you must run the NamespaceLifecycle admission controller before any other controller that operates on namespaced resources.

Types of Kubernetes admission controllers

Admission controllers can be divided into two types according to their function:

• Mutating admission controllers: These can modify the objects before they are stored. For example, they can add labels, annotations or default values.
• Validating admission controllers: These can validate and reject the objects if they do not meet specific criteria. A validating admission controller can check if the objects conform to a schema, policy or quota.

Admission controllers can also be classified based on how they are configured:

• Static admission controllers: These come built-in with Kubernetes and are useful for implementing mandatory policies that should consistently be enforced.
• Dynamic admission controllers: These are registered at runtime using webhooks and can be customized by the user.

Both static and dynamic controllers can be either validating or mutating.

Static Kubernetes admission controllers

Kubernetes ships with more than 30 built-in static admission controllers that are compiled into the kube-apiserver binary and can be configured by cluster administrators using command-line flags.

Here are examples of static admission plugins:

• NamespaceLifecycle: Enforces policies related to the lifecycle of Kubernetes namespaces, ensuring that system namespaces cannot be deleted and new namespaces are created with a specific set of labels.
• LimitRanger: Enforces default resource requests and limits for pods and containers based on a LimitRange object defined in that namespace. It also validates that pods with explicitly set resource requirements do not exceed those limits.
• ResourceQuota: Allows you to set quotas for resource consumption (such as CPU cores or memory bytes) per namespace. It also prevents users from creating new resources if they exceed their quota.
• DenyEscalatingExec: Prevents privilege escalation attacks by denying requests to execute commands with elevated privileges in Kubernetes pods, stopping malicious actors from gaining unauthorized access to the cluster.
• PodSecurityPolicy: Was used to enforce policies directly on the pod level, such as preventing the use of privileged containers and restricting host namespaces. However, PodSecurityPolicy (PSP) has been deprecated since the release of Kubernetes 1.21. The admission controller was challenging to deploy, and even the maintainers of Kubernetes recommend using third-party admission controllers, such as Open Policy Agent (OPA), instead. 

Is PSP deprecation causing problems for your team? Learn how to navigate the PSP transition in our webinar.

Dynamic admission controllers

Built-in static admission controllers may not be enough to meet the requirements of every organization. Dynamic admission controllers provide a way to customize and extend the Kubernetes functionality by leveraging admission webhooks. 

Kubernetes admission controller webhooks are extensions that run as HTTP callbacks and receive admission requests from the API server. These plugins can implement custom logic or rules for Kubernetes resources and seamlessly integrate with third-party code. 

Types of admission webhooks 

There are three types of admission webhooks:

• ImagePolicyWebhook: Controls container image admission.
• MutatingAdmissionWebhook: Modifies the admission request objects.
• ValidatingAdmissionWebhook: Allows or denies admission requests.

Creating and configuring a webhook requires MutatingAdmissionWebhook and ValidatingAdmissionWebhook to be enabled in the Kubernetes cluster.

OPA: Kubernetes admission controller for custom policies

OPA is a policy engine that can be integrated with Kubernetes as a dynamic external admission controller to enforce policies without recompiling or reconfiguring the Kubernetes API server.

OPA uses a declarative language called Rego to define policies that specify the desired state and behavior of the cluster resources. For example, you can use OPA to require that all container images come from a trusted registry. An Aqua report discovered a 10% increase in malicious container images that targeted Kubernetes environments, highlighting the importance of container image security.

OPA has several other benefits for Kubernetes users and administrators as well. Using decoupled policy as code, OPA allows you to change and update policies without impacting the availability or performance of your services. OPA also enables you to write context-aware policies that use external data sources and logic to make decisions based on the current state of the cluster and environment. And last but not least, the domain-agnostic policy engine provides a unified framework for consistent policy enforcement across cloud-native technologies such as Envoy, Terraform, Kafka, SQL and Linux.

Styra DAS and OPA: Kubernetes admission control for enterprises

Styra Declarative Authorization Service (DAS) is an enterprise-grade authorization platform that manages OPA deployments across the entire cloud-native ecosystem. 

With Styra DAS and OPA, you can:

• Minimize risk by starting with pre-built policies mapped to industry standards such as PCI, MITRE ATT&CK for cloud and CIS benchmarks.
• Reduce time-to-market and improve collaboration by allowing developers to focus on building features while security and compliance teams can audit and update policies as needed.
• Ease policy management with a simple, centralized way to manage stacks of policies across dozens or hundreds of clusters. For instance, you may have stacks for base stack policies, developer stack policies and production stack policies, as well as unique policies for individual clusters.
• Shift left and see the impact of policy changes before deploying them using CI/CD integrations and policy simulations.
• Provide guardrails for your infrastructure provisioning by ensuring that your Kubernetes resources comply with security, compliance and operational requirements.
• Monitor the health and performance of your OPAs across clusters and clouds using decision logs, metrics and alerts. The majority of IT professionals consider observability critical to their business success, according to a 2022 New Relic report.  

Styra DAS provides support for a number of infrastructure and application authorization use cases. While the policies may differ across use cases, a single technology stack can be used to create, enforce and monitor them.

See Styra DAS in action with a custom demo from one of our team members!

Frequently asked questions

What is the difference between an admission webhook and an admission controller?

An admission controller is a component of the API server that intercepts requests and performs specific actions before the rest of the API server processes them. An admission webhook extends the functionality of an admission controller by allowing external services to modify or validate requests to the Kubernetes API server. 

Can I create my own Kubernetes admission controller?

Yes. You can create an admission controller in Kubernetes by writing custom code and deploying it as a Kubernetes plugin. This allows you to enforce custom policies and restrictions on objects as they are created or modified in the cluster. However, it’s important to thoroughly test and validate your admission controller before deploying it in a production environment.