Admission Controllers

Antes de crear un recurso en Kubernetes seguimos por un flujo de validación:

1. Autenticación del usuario
2. Autorización para conferir si lo que él pide él puede hacer
3. Admission

El Admission Controller tiene como función hacer verificaciones, realizar operaciones o hacer cambios antes de crear el recurso.

No podemos crear un recurso en un namespace que no existe, luego es necesario rechazar la requisición.

Algunos parámetros padrón precisan ser rellenados caso el usuario no haya pasado:

• Si cuotas existieren, ellas deben ser verificadas
• Rate limits existentes deben ser aplicados o verificados
• Conferir el scheduler pasado o definir el padrón si no fue especificado
• Etc.

El admission controllers también pueden rechazar un request caso no sea posible.

Podemos habilitar un admission controller que crea el namespace automáticamente caso no exista.

Para verificar los admission controller activados en el kube-api-server podemos conferir de esta manera.

❯ 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.

Arriba mostramos admission controllers habilitados por default.

Para habilitar un admission controller podemos pasar vía parámetros para el kube-api-server esté él ejecutando como service en el sistema operativo o como pod estático.

 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

Arriba estamos habilitando el NamespaceLifecycle para que, caso no exista el namespace, este sea creado automáticamente y deshabilitando el storageclass default.

Mutating Admission Controllers and Valiating Admission Controllers

Ese tipo de admission controller hace un incremento en los manifestos cuando algo no es especificado.

Cuando declaramos un PVC por ejemplo y no especificamos el storageclass y después analizamos el yaml que fue deployado con el get -o yaml podemos observar que tendremos el storageClass: default presente. Un otro ejemplo podría ser el nombre del scheduler en los pods. No acostumbramos pasar, pero si observar el yaml deployado estará allá.

Existen plugins que solamente hacen la validación. Cuando un request llega con un manifiesto una secuencia admission controllers del tipo mutating hacen su trabajo y después los plugins del tipo validation. Algunos plugins pueden hacer los dos trabajos.

También podemos crear los nuestros propios admission controllers. Es necesario implementar una aplicación con los nuestros propios códigos y lógicas para hacer la alteración, inclusión o validación.

Una vez que pasó por todos los admission controllers será hecho una llamada para el admission webhook server que desarrollamos pasando un objeto json que debe ser revisado.

Este objeto contiene todos los detalles sobre el request, el usuario que hizo la solicitación, tipo de operación que el usuario está intentando realizar, sobre cual objeto y detalles sobre el propio objeto al recibir la solicitación.

El admission webhook server responde con un objeto de revisión de admisión con el resultado de si la solicitación es permitida o no.

Puede ser desarrollado en cualquier lenguaje desde que reciba el JSON y responda con el JSON específico. También es necesario usar TLS.

Puede ser usado el propio Kubernetes para ejecutar esta aplicación usando el deployment y el service para alcanzar el servicio.

Se crea un objeto en Kubernetes que irá especificar cuando ese admission webhook debe ser llamado baseado en reglas y cómo llegar hasta el servicio.