Mutating Admission Controllers

1. Purpose:

   Mutating Admission Controllers intercept incoming requests to the Kubernetes API server and can modify the objects being submitted. Their primary purpose is to make automatic changes or additions to resources before they are persisted in the cluster.

2. Examples of Use Cases:

   • Default Values: You can use a mutating admission controller to automatically set default values for fields in resource configurations. For instance, you might want to set a default container image, environment variable, or labels for Pods if they are not explicitly defined by users.

   • Injection of Sidecar Containers: Mutating controllers are often used to inject sidecar containers into Pods. For example, an Istio sidecar for service mesh functionality can be automatically injected into Pods without requiring the user to specify it explicitly.

   • Automated Certificates: In a security context, a mutating controller can automatically generate and inject TLS certificates into pods for secure communication.

Validating Admission Controllers

1. Purpose:

   Validating Admission Controllers intercept incoming requests and validate them against predefined policies or rules. They can either approve or deny a request based on whether it conforms to the established criteria.

2. Examples of Use Cases:

   • Resource Quotas: Validating controllers can enforce resource quotas, ensuring that users or namespaces do not exceed allocated CPU, memory, or other resource limits.

   • Pod Security Policies: You can use validating controllers to enforce security policies on Pods. For example, a policy might require that Pods run with non-root user privileges or disallow the use of host networking.

   • Network Policies: Network policies can be enforced using validating controllers to ensure that network communication between Pods adheres to specified rules, such as allowing or denying traffic based on labels and namespaces.

Key Differences

1. Mutation vs. Validation:

   • Mutating controllers modify or mutate the object being submitted while validating controllers only validate and either approve or deny the request without making changes.

2. Order of Execution:

   • Mutating controllers run before validating controllers in the admission control chain. This means they can modify objects before validation occurs.

3. Effect on Requests:

   • Mutating controllers can transform requests into a different state by adding or changing values, making them compliant with certain policies.

   • Validating controllers primarily enforce policies and constraints, rejecting requests that do not meet criteria.

4. Examples:

   • Mutating Controller Example: Let's say you have a mutating controller that automatically adds an annotation to every Pod resource to track the creator. When a user creates a Pod, this controller intercepts the request and adds an annotation like "created-by: <username>" to the Pod specification before it's persisted in the cluster.

   • Validating Controller Example: Consider a validating controller that enforces a policy requiring all Pods to have a label specifying their environment (e.g., "dev," "staging," or "prod"). If a user tries to create a Pod without this label, the controller will deny the request, ensuring that all Pods adhere to the labeling policy.

In summary, Mutating Admission Controllers modify objects before they are stored in the cluster, often for automation and policy enforcement purposes. Validating Admission Controllers, on the other hand, validate requests against policies and enforce constraints without changing the objects. Together, these controllers allow you to implement a wide range of custom policies and automation in your Kubernetes cluster to ensure it runs securely and efficiently.