Skip to main content

Admission Control

Admission control is a validation process in communication systems where a check is performed before a connection is established to see if current resources are sufficient for the proposed connection.

An admission controller is a piece of code that intercepts requests to the Kubernetes API server prior to persistence of the object, but after the request is authenticated and authorized. It can be used for a variety of purposes including checking if current resources are sufficient for the proposed operation, or if the requested resources may be in conflict with the enforced policies of the system.

Kubernetes provides multiple pluggable points for the review of authenticated API requests where a request can be inspected or even modified. This is achieved through admission control plugins.

tip

You can see the list of Kubernetes built-in admission control rules available in your Kubernetes system by clicking [Validating | Mutating] >> Rules >> Add rule drop-down menu.

Purpose​

Many advanced features in Kubernetes require an admission controller to be enabled in order to fully support the expected features. As a result, a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features you expect. Admission controllers are very useful, as they allow you to validate or modify requests to a Kubernetes API server.

Limitations​

Admission Controllers have the following limitations:

  • Request scope is limited to create, delete, modify or connect to proxy.
  • Do not support read requests.
  • Must be compiled into an API server and can be configured only on the API server startup.

Admission Webhooks​

The flexibility of admission webhooks helps solve the limitations of admission controllers. Once enabled, their behavior can be configured instantly by modifying the external application that is invoked for each request. Admission webhooks are HTTP callbacks that receive requests and operate on them. The admission control plugins are registered with the API server.

Phases of Admission Controller​

Upon submission to the Kubernetes API server, an admission request uses the following phases before being persisted to etcd.

  • A mutating phase.

  • A validating phase.

Styra allows you to use OPA policies to govern the behavior of mutation and validation phases. A Styra Kubernetes system installs two webhooks, one each of mutating and validating. You can use either one of them individually or both in combination. The rules for the webhooks can be edited and validated in the Styra UI which groups the rules in the appropriate package. Each webhook is configured to query a specific data document on the OPA service present in the cluster.

Since the mutating webhook can optionally change the input object supplied in the request, the structured decision schema for mutating rules varies from the validating rules.

Types of Webhooks​

The following shows the two types of webhooks.

  • Validating webhooks are invoked during the validation phase of the admission process. This phase allows the enforcement of invariants on particular API resources to ensure that the resource does not change again. You may reject requests to enforce custom admission policies.

  • Mutating webhooks are invoked during the mutation phase of the admission process, which allows modification of the resource content before it is persisted. You may change requests to enforce custom defaults.

Mutating admission webhooks are invoked first, and can modify objects sent to the API server to enforce custom defaults. After all object modifications are complete, and after the incoming object is validated by the API server, validating admission webhooks are invoked and can reject requests to enforce custom policies.

For more information on Kubernetes Admission Controls, read A guide to Kubernetes Admission Controllers.

Schema for Structured Decisions​

important

The webhooks are executed in the order of Mutating webhook followed by Validating webhook, in order to ease the understanding for first time readers/users.

Validating Webhook​

enforce[decision] {
    # rule body
    decision := {
        "allowed": boolean, REQUIRED
        "message": string,  OPTIONAL
    }
}

Mutating Webhook​

enforce[decision] {
    # rule body
    decision := {
        "allowed": boolean, REQUIRED
        "message": string,  OPTIONAL
        "patch": [          OPTIONAL
            {
                "op": string,
                "path": string,
                "value": string,
            }
        ]
    }
}

For example, the following shows the Mutating rule to add an example label to a pod.

add example label
enforce[decision] {
    input.request.object.kind == "Pod"
    input.request.object.metadata.labels

    decision := {
        "allowed": true,
        "message": "adding an example label",
        "patch": [
            {
                "op": "add",
                "path": "/metadata/labels/example-label-name",
                "value": "this-is-an-example-value",
            }
        ]
    }
}