Pular para o conteúdo principal

Admission Controllers

Antes de criar um recurso no Kubernetes seguimos por um fluxo de validação:

  1. Autenticação do usuário
  2. Autorização para conferir se o que ele pede ele pode fazer
  3. Admission

O Admission Controller tem como função fazer verificações, realizar operações ou fazer mudanças antes de criar o recurso.

Não podemos criar um recurso em um namespace que não existe, logo é necessário rejeitar a requisição.

Alguns parâmetros padrão precisam ser preenchidos caso o usuário não tenha passado:

  • Se quotas existirem, elas devem ser verificadas
  • Rate limits existentes devem ser aplicados ou verificados
  • Conferir o scheduler passado ou definir o padrão se não foi especificado
  • Etc.

admissioncontrollers

O admission controllers também podem rejeitar uma request caso não seja possível.

Podemos habilitar um admission controller que cria o namespace automaticamente caso não exista.

Para verificar os admission controller ativados no kube-api-server podemos conferir desta maneira.

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

Acima mostramos admission controllers habilitados por default.

Para habilitar um admission controller podemos passar via parâmetros para o kube-api-server esteja ele rodando como service no sistema operacional ou 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

Acima estamos habilitando o NamespaceLifecycle para que, caso não exista o namespace, este seja criado automaticamente e desabilitando o storageclass default.

Mutating Admission Controllers and Valiating Admission Controllers​

Esse tipo de admission controller faz um incremento nos manifestos quando algo não é especificado.

Quando declaramos um PVC por exemplo e não especificamos o storageclass e depois analisamos o yaml que foi deployado com o get -o yaml podemos observar que teremos o storageClass: default presente. Um outro exemplo poderia ser o nome do scheduler nos pods. Não costumamos passar, mas se observar o yaml deployado estará lá.

Existem plugins que somente fazem a validação. Quando um request chega com um manifesto uma sequência admission controllers do tipo mutating fazem seu trabalho e depois os plugins do tipo validation. Alguns plugins podem fazer os dois trabalhos.

admisionorder

Também podemos criar os nossos próprios admission controllers. É necessário implementar uma aplicação com os nossos próprios códigos e lógicas para fazer a alteração, inclusão ou validação.

alt text

Uma vez que passou por todos os admission controllers será feito uma chamada para o admission webhook server que desenvolvemos passando um objeto json que deve ser revisado.

Este objeto contém todos os detalhes sobre o request, o usuário que fez a solicitação, tipo de operação que o usuário está tentando realizar, sobre qual objeto e detalhes sobre o próprio objeto ao receber a solicitação.

O admission webhook server responde com um objeto de revisão de admissão com o resultado de se a solicitação é permitida ou não.

Pode ser desenvolvido em qualquer linguagem desde que receba o JSON e responda com o JSON específico. Também é necessário usar TLS.

Pode ser usado o próprio Kubernetes para rodar esta aplicação usando o deployment e o service para alcançar o serviço.

Cria-se um objeto no Kubernetes que irá especificar quando esse admission webhook deve ser chamado baseado em regras e como chegar até o serviço.

alt text