Admission controllers for policy enforcement - motivation and theory

What are they?

Admission controllers are gates that validate (or mutate) incoming API requests before persisting them onto etcd.

Context
After the authentication module has established the identity of the user, the authorization module is consulted in order to determine whether the user is allowed to perform the request. The authorization module does this by asking all the authorizers configured to run inside of the module. This query, sent to each authorizer in the order they appear in the configuration, is called a SubjectAccessReview.

RBAC policies are not expressive enough to specify business rules on the requests and users identified by the AuthN agent. This is where admission controllers can help. There are two types of admission controllers in kubernetes.

Compiled-in admission controllers

These are compiled into the `kube-apiserver` binary, and may only be configured by the cluster administrator.

Enabling or disabling them is through:

kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ...
# --disable-admission-plugins to disable

Listing the currently enabled ones can be done through

kube-apiserver -h | grep enable-admission-plugins

While they are very powerful and useful, they have three limitations:

• kube-apiserver needs a restart when they are to be (re-)configured
• configurations only possible by a cluster administration who has an OS level access
• extending them is not possible

Detailed documentation

Dynamic admission controllers

These are admission plugins can be developed as extensions and run as webhooks configured at runtime. Admission webhooks are HTTP callbacks that receive admission requests and do something with them. You can define two types of admission webhooks, validating admission webhook and mutating admission webhook. 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.

Kubernetes documentation