Admission Controllers

Before creating a resource in Kubernetes, we go through a validation flow:

1. User authentication
2. Authorization to check if what they're requesting they can do
3. Admission

The Admission Controller's function is to perform checks, carry out operations, or make changes before creating the resource.

We can't create a resource in a namespace that doesn't exist, so the request needs to be rejected.

Some default parameters need to be filled if the user hasn't provided them:

• If quotas exist, they must be checked
• Existing rate limits must be applied or checked
• Check the specified scheduler or define the default if not specified
• Etc.

Admission controllers can also reject a request if it's not possible.

We can enable an admission controller that automatically creates the namespace if it doesn't exist.

To verify the admission controllers activated in the kube-api-server, we can check this way:

❯ kubectl exec -n kube-system kube-apiserver-kind-cluster-control-plane -- kube-apiserver -h | grep "enable-admission-plugins strings"
      --enable-admission-plugins strings       admission plugins that should be enabled in addition to default enabled ones (NamespaceLifecycle, LimitRanger, ServiceAccount, TaintNodesByCondition, PodSecurity, Priority, DefaultTolerationSeconds, DefaultStorageClass, StorageObjectInUseProtection, PersistentVolumeClaimResize, RuntimeClass, CertificateApproval, CertificateSigning, ClusterTrustBundleAttest, CertificateSubjectRestriction, DefaultIngressClass, MutatingAdmissionWebhook, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook, ResourceQuota). Comma-delimited list of admission plugins: AlwaysAdmit, AlwaysDeny, AlwaysPullImages, CertificateApproval, CertificateSigning, CertificateSubjectRestriction, ClusterTrustBundleAttest, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, DenyServiceExternalIPs, EventRateLimit, ExtendedResourceToleration, ImagePolicyWebhook, LimitPodHardAntiAffinityTopology, LimitRanger, MutatingAdmissionWebhook, NamespaceAutoProvision, NamespaceExists, NamespaceLifecycle, NodeRestriction, OwnerReferencesPermissionEnforcement, PersistentVolumeClaimResize, PersistentVolumeLabel, PodNodeSelector, PodSecurity, PodTolerationRestriction, Priority, ResourceQuota, RuntimeClass, SecurityContextDeny, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionPolicy, ValidatingAdmissionWebhook. The order of plugins in this flag does not matter.

Above we show admission controllers enabled by default.

To enable an admission controller, we can pass it via parameters to the kube-api-server whether it's running as a service in the operating system or as a static pod.

 k get pods -n kube-system kube-apiserver-kind-cluster-control-plane -o yaml | grep admission
    - --enable-admission-plugins=NodeRestriction,NamespaceLifecycle
    - --disable-admission-plugins=DefaultStorageClass

Above we're enabling NamespaceLifecycle so that if the namespace doesn't exist, it will be automatically created, and disabling the default storageclass.

Mutating Admission Controllers and Validating Admission Controllers

This type of admission controller makes increments to manifests when something isn't specified.

When we declare a PVC for example and don't specify the storageclass, and then analyze the yaml that was deployed with get -o yaml, we can observe that we'll have storageClass: default present. Another example could be the scheduler name in pods. We don't usually pass it, but if you observe the deployed yaml, it will be there.

There are plugins that only do validation. When a request arrives with a manifest, a sequence of mutating-type admission controllers do their work and then the validation-type plugins. Some plugins can do both jobs.

We can also create our own admission controllers. It's necessary to implement an application with our own codes and logic to make the change, inclusion, or validation.

Once it's passed through all admission controllers, a call will be made to the admission webhook server we developed, passing a JSON object that should be reviewed.

This object contains all the details about the request, the user who made the request, the type of operation the user is trying to perform, which object, and details about the object itself when receiving the request.

The admission webhook server responds with an admission review object with the result of whether the request is allowed or not.

It can be developed in any language as long as it receives the JSON and responds with the specific JSON. It's also necessary to use TLS.

Kubernetes itself can be used to run this application using deployment and service to reach the service.

An object is created in Kubernetes that will specify when this admission webhook should be called based on rules and how to reach the service.