Admission controllers are gates that validate (or mutate) incoming API requests before persisting them onto etcd.
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.
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
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.