Admission Controllers

Admission Controllers are a critical component in Kubernetes that operate as plugins within the Kubernetes API server. They intercept and modify or validate requests to the Kubernetes API before they are persisted in the etcd database. Admission controllers play a crucial role in enforcing policies, ensuring security, and managing resource usage in a Kubernetes cluster.

What are Admission Controllers?

Admission controllers are pieces of code that are executed after an API request is authenticated and authorized but before the object is persisted to the etcd database. They act as gates that can accept, reject, or modify the objects that are being created or updated in the cluster. Admission controllers are used to enforce organizational policies, validate configurations, set default values, and more.

Core Responsibilities of Admission Controllers

  1. Validation:
  • Admission controllers can validate requests to ensure they meet specific criteria before they are accepted. For example, they can enforce that Pods have resource limits defined or that images come from a trusted registry.
  1. Mutation:
  • Some admission controllers can modify or “mutate” the object in the request. This could involve adding default values, labels, or annotations to resources. For example, a controller might automatically inject a sidecar container into a Pod.
  1. Policy Enforcement:
  • Admission controllers can enforce organizational policies, such as security policies, network policies, or compliance requirements. For example, they can prevent the creation of privileged Pods or ensure that all Pods meet specific security standards.
  1. Resource Quotas:
  • Admission controllers can enforce resource quotas within namespaces, ensuring that teams or applications do not exceed their allocated CPU, memory, or storage limits.
  1. Denying Requests:
  • Admission controllers can reject requests that do not comply with predefined rules. For example, a controller might deny the creation of a Pod if it violates a security policy or exceeds resource quotas.
  1. Defaulting:
  • Some admission controllers set default values for fields that are not specified by the user. This helps in standardizing configurations across the cluster.

How Admission Controllers Work in Kubernetes

Admission controllers are executed as part of the API server’s request processing pipeline. Here’s a high-level overview of how they fit into the Kubernetes architecture:

  1. Request Flow:
  • A user submits a request to the Kubernetes API server (e.g., creating a Pod, Deployment, or Service).
  • The API server first authenticates the user and checks their authorization to perform the requested action.
  1. Admission Controller Execution:
  • After authentication and authorization, the request is passed through a series of enabled admission controllers.
  • Each admission controller can accept, reject, or modify the request based on its logic and configuration.
  1. Persistence or Rejection:
  • If all admission controllers accept the request, it is persisted in etcd and the requested object is created or updated.
  • If any admission controller rejects the request, the API server returns an error to the user, and the object is not created or modified.

Types of Admission Controllers

There are two primary types of admission controllers in Kubernetes: Validating Admission Controllers and Mutating Admission Controllers.

  1. Validating Admission Controllers:
  • These controllers perform validation checks on objects to ensure they meet certain criteria. They cannot modify the object but can accept or reject it based on validation logic.
  • Example: PodSecurityPolicy validates that Pods adhere to specific security policies, such as running with non-root user IDs or using specific AppArmor profiles.
  1. Mutating Admission Controllers:
  • These controllers can modify or “mutate” objects before they are persisted. They are commonly used to inject additional configuration or to set default values.
  • Example: MutatingWebhook can inject a sidecar container into a Pod or add labels to resources.

Commonly Used Admission Controllers

Kubernetes comes with several built-in admission controllers, some of which are enabled by default:

  1. NamespaceLifecycle:
  • Prevents the deletion of a namespace that contains resources and ensures that objects are not created in non-existent namespaces.
  1. ResourceQuota:
  • Ensures that resource quotas are respected within namespaces. If a request exceeds the quota, it is rejected.
  1. LimitRanger:
  • Enforces resource limits and request defaults on Pods. It ensures that all Pods have resource requests and limits defined.
  1. PodSecurityPolicy:
  • Enforces security policies on Pods, such as disallowing privileged containers or enforcing specific capabilities.
  1. DefaultStorageClass:
  • Automatically assigns a default storage class to PersistentVolumeClaims that do not specify one.
  1. NodeRestriction:
  • Restricts what nodes can modify Pod and Node objects, ensuring that nodes cannot elevate privileges or modify resources outside their scope.
  1. MutatingAdmissionWebhook:
  • Allows for dynamic modification of objects using external webhooks. For example, this can be used to inject sidecar containers into Pods.
  1. ValidatingAdmissionWebhook:
  • Similar to the mutating webhook but used for validation. It can reject requests that do not meet specific criteria, such as enforcing custom validation rules.

Example: Using Admission Controllers

Let’s consider an example where an organization wants to enforce a policy that all Pods must have resource limits defined. They can achieve this with the LimitRanger admission controller.

  1. Define a LimitRange:
  • The administrator defines a LimitRange object in each namespace:
   apiVersion: v1
   kind: LimitRange
   metadata:
     name: pod-limit-range
   spec:
     limits:
     - default:
         cpu: 500m
         memory: 512Mi
       defaultRequest:
         cpu: 200m
         memory: 256Mi
       type: Container
  1. Apply the LimitRange:
  • Apply the LimitRange to the namespace:
   kubectl apply -f limitrange.yaml --namespace=default
  1. Enforcement by LimitRanger:
  • When users try to create a Pod without specifying resource limits, the LimitRanger admission controller automatically applies the defaults defined in the LimitRange object.
  • If a Pod exceeds the defined limits, the request is rejected by the admission controller.

Webhooks for Custom Admission Controllers

In addition to the built-in admission controllers, Kubernetes supports Dynamic Admission Control through webhooks. These webhooks allow you to create custom admission controllers that can be triggered during the admission process.

  • MutatingAdmissionWebhook: Allows external services to modify objects before they are persisted.
  • ValidatingAdmissionWebhook: Allows external services to validate objects and reject those that do not meet custom criteria.

Example: Implementing a Validating Webhook

Suppose you want to enforce a rule that all Pods must have a specific label. You can implement this using a validating admission webhook.

  1. Webhook Server:
  • Develop a webhook server that listens for API requests and checks if Pods have the required label.
  • If a Pod is missing the label, the webhook returns a rejection response.
  1. Create a ValidatingWebhookConfiguration:
  • Define a ValidatingWebhookConfiguration resource in Kubernetes that points to your webhook server:
   apiVersion: admissionregistration.k8s.io/v1
   kind: ValidatingWebhookConfiguration
   metadata:
     name: pod-label-validator
   webhooks:
   - name: podlabel.validator.example.com
     clientConfig:
       service:
         name: pod-label-validator-service
         namespace: default
         path: "/validate-pods"
       caBundle: <base64-encoded-ca-cert>
     rules:
     - operations: ["CREATE"]
       apiGroups: [""]
       apiVersions: ["v1"]
       resources: ["pods"]
     failurePolicy: Fail
     admissionReviewVersions: ["v1"]
  1. Deployment:
  • Deploy the webhook server as a Kubernetes service and ensure it is reachable by the API server.
  • Apply the ValidatingWebhookConfiguration to register the webhook with the API server.
  1. Enforcement:
  • When a Pod is created, the API server calls the webhook to validate the request. If the Pod is missing the required label, the webhook rejects the request, preventing the Pod from being created.

Security Considerations for Admission Controllers

  • Authentication and Authorization: Ensure that webhooks are properly secured with TLS and that only authorized clients can interact with them.
  • Failure Policies: Configure failure policies (e.g., Fail, Ignore) to control how the API server should behave if a webhook is unreachable. A Fail policy can prevent objects from being created if the webhook is down, enhancing security but potentially causing availability issues.
  • Audit Logging: Admission controllers should be integrated with Kubernetes audit logging to track all decisions made during the admission process.

High Availability and Scalability

  • Webhook Availability: Ensure that webhook servers are highly available to avoid disruptions in the admission process. This typically involves running multiple replicas of the webhook server and load balancing requests.
  • Performance: Admission controllers add latency to the API request flow, so it’s essential to monitor their performance and optimize the processing time, especially in large clusters.

Summary

Admission Controllers are a vital part of Kubernetes’ extensibility and security architecture. They provide a mechanism to enforce policies, validate configurations, and modify resources before they are persisted in the cluster. By using built-in admission controllers or implementing custom ones via dynamic admission webhooks, you can enforce organizational policies, automate configurations, and enhance the security posture of your Kubernetes environment. Understanding and effectively utilizing admission controllers is crucial for maintaining control, compliance, and consistency in a Kubernetes

cluster.