Por que você precisa de um controlador de admissão do Kubernetes

Se você não tem experiência como operador ou administrador do Kubernetes, os controladores de admissão talvez sejam novidade. Eles funcionam principalmente em segundo plano e muitos estão disponíveis como plugins compilados, mas podem contribuir bastante para a segurança de uma implantação.

Os controladores de admissão interceptam solicitações à API antes que elas cheguem ao servidor da API e podem rejeitá-las ou modificá-las. Isso se aplica à maioria dos tipos de solicitações do Kubernetes, exceto às solicitações exclusivamente de leitura, que não passam pelos controladores. Os controladores de admissão processam as solicitações depois que elas são devidamente autenticadas e autorizadas.

Este artigo explica os motivos para incluir controladores de admissão no Kubernetes. Também destaca as vantagens de conhecer melhor o funcionamento deles.

Vários controladores de admissão são habilitados por padrão, pois a maioria das operações normais do Kubernetes depende deles. Muitos fazem parte da árvore de código-fonte do Kubernetes e são compilados como plugins. Também é possível programar e implantar controladores de admissão de terceiros. Mais adiante, apresentamos alguns exemplos. Para saber mais sobre os detalhes da implementação de controladores de admissão, consulte a documentação do Kubernetes.

Controladores de admissão padrão

O Kubernetes oferece vários controladores de admissão integrados. Um exemplo simples é o DefaultIngressClass, que aplica a classe de ingresso padrão a objetos de ingresso que ainda não têm uma classe especificada. De forma semelhante, o DefaultStorageClass aplica a classe de armazenamento padrão a PersistentVolumeClaims que ainda não têm uma. Esse controlador precisa estar habilitado para permitir o provisionamento dinâmico de armazenamento com base na classe de armazenamento.

Os controladores de admissão podem ser muito úteis para manter a segurança. Por exemplo, podem atenuar ataques de negação de serviço (DoS) em clusters multi-inquilinos. Considere o plugin LimitRanger, que, como o nome sugere, aplica limites de recursos. Esses limites definem faixas obrigatórias de consumo de recursos por namespace, impedindo que os inquilinos esgotem os recursos uns dos outros.

Outra preocupação é a chamada inundação de eventos, em que o cluster fica sobrecarregado de eventos e não consegue lidar adequadamente com outras solicitações legítimas. O controlador EventRateLimit é uma ferramenta eficaz para atenuar esse tipo de situação. Ele foi projetado para limitar a frequência de eventos por namespace ou por usuário.

Além disso, há dois controladores importantes que permitem aos desenvolvedores executar seus plugins de admissão como webhooks configurados em tempo de execução. O MutatingAdmissionWebhook permite que webhooks modifiquem os recursos enviados e costuma ser usado para aplicar padrões personalizados. Já o controlador ValidatingAdmissionWebhook permite que os webhooks registrados decidam se um recurso validado pela API, em seu estado final, deve continuar no fluxo ou ser totalmente descartado.

Objetivo dos controladores

A forma original de executar vários serviços em uma máquina física era usar máquinas virtuais no mesmo host, com um hipervisor isolando seus sistemas operacionais. Um sistema complexo de configurações de nuvem — como as definidas pela AWS — mantinha os sistemas separados e impedia que os inquilinos prejudicassem uns aos outros, por acidente ou de propósito.

Inicialmente, o Kubernetes foi projetado como um sistema colaborativo que uma única organização ou usuário poderia usar. Além disso, dependia muito mais da consideração mútua do que outros sistemas de nuvem. No entanto, à medida que o Kubernetes se expande, tanto em variedade de implantações disponíveis quanto na capacidade de lidar com clusters maiores, torna-se cada vez mais importante implementar políticas que impeçam um único usuário de interferir na operação do sistema.

Para automatizar esse processo, as organizações precisam de um sistema de políticas. O Kubernetes oferece algum suporte integrado, mas não tem os recursos de um mecanismo de políticas completo e dedicado.

Mecanismos externos de políticas

Há dois principais mecanismos de políticas de código aberto para Kubernetes: Open Policy Agent (OPA) Gatekeeper e Kyverno.

Ambos os mecanismos foram doados à Cloud Native Computing Foundation (CNCF), organização dedicada à padronização e à disseminação de tecnologias nativas da nuvem. Ela opera sob sua organização-mãe, a Linux Foundation. Vale destacar que o Kubernetes é um projeto da CNCF.

A principal vantagem do Kyverno é que ele não exige o aprendizado de uma linguagem adicional. Todas as políticas são definidas como recursos do Kubernetes. Já o Gatekeeper usa a linguagem declarativa do OPA, Rego. O Gatekeeper faz parte do ecossistema mais amplo do OPA, enquanto o Kyverno é um projeto independente para Kubernetes. Em resumo, o Gatekeeper é um projeto mais maduro, mas o Kyverno tem uma curva de aprendizado menor.

Seu controlador de admissão personalizado

Você pode usar webhooks para programar a lógica de um controlador de admissão personalizado em qualquer linguagem capaz de processar solicitações HTTP e retornar JavaScript Object Notation (JSON). Go, Python e Ruby, por exemplo, são opções válidas.

O exemplo abaixo mostra como configurar um webhook para um controlador de admissão personalizado. Ele é semelhante ao LimitRanger apresentado anteriormente, que rejeita solicitações de pods que ultrapassam os limites de recursos do namespace. Observe que este exemplo não inclui todo o código-fonte do controlador. Para conhecer o processo em detalhes, consulte a documentação do Kubernetes sobre servidores de webhook de admissão.

Primeiro, registre o webhook com um objeto de configuração:

1apiVersion: admissionregistration.k8s.io/v1beta1
2kind: ValidatingWebhookConfiguration
3metadata:
4  name: mywebhook
5webhooks:
6  - name: mywebhook
7    clientConfig:
8      service:
9        name: mywebhook
10        namespace: project1
11        path: "/hook"
12    rules:
13      - operations: ["CREATE"]
14        apiVersions: ["v1"]
15        apiGroups: [""]
16        resources: ["pods"]

Isso informa o ValidatingWebhookController sobre o webhook. Também especifica qual serviço acessar e qual caminho consultar no contêiner que executa o servidor. Além disso, identifica as regras a aplicar ao decidir se o webhook será chamado. Este exemplo se concentra na criação de novos pods.

Na prática, esse recurso seria criado no cluster por último, depois da criação de uma implantação para o servidor do webhook. A implantação inclui um serviço que corresponde à definição no arquivo acima:

1apiVersion: v1
2kind: Service
3metadata:
4  name: mywebhook
5  namespace: project1
6spec:
7  - ports:
8      name: mywebhook
9      port: 80
10      targetPort: 8000

Abaixo está um exemplo de implantação de um webhook, igual à de um aplicativo comum. Não vamos abordar como proteger as comunicações com Transport Layer Security (TLS), embora isso seja altamente recomendado.

1apiVersion: apps/v1
2kind: Deployment
3metadata:
4  name: mywebhook
5  namespace: project1
6spec:
7  selector:
8    matchLabels:
9      app: mywebhook
10  template:
11    metadata:
12      labels:
13        app: mywebhook
14    spec:
15      containers:
16        - image: webhook1:latest
17          name: mywebhook

Depois que uma nova solicitação de pod é enviada ao Kubernetes e aprovada pelo ValidatingWebhook, as informações relevantes são enviadas como uma solicitação POST ao caminho configurado. Essa solicitação contém um objeto JSON para o webhook processar. Para aprovar a solicitação, retorne uma resposta semelhante à seguinte, junto com o código de status 200 OK:

1{
2  "apiVersion": "admission.k8s.io/v1",
3  "kind": "AdmissionReview",
4  "response": {
5    "uid": "6ce7a33c-ea67-40e5-9cc8-f710d31985dc",
6    "allowed": true
7  }
8}

O campo uid vem da solicitação e serve para associar solicitações às respostas. Para impedir a criação do pod, o campo allowed deve ser definido como false e um código de erro HTTP deve ser retornado.

Um controlador de admissão personalizado pode ser tão simples quanto o exemplo acima ou muito mais complexo. Para uma visão geral mais completa, consulte a documentação de webhooks de admissão.

Conclusão

Um controlador de admissão do Kubernetes pode modificar ou rejeitar solicitações ao servidor da API antes que o objeto seja persistido. O Kubernetes tem vários controladores integrados versáteis, incluindo diversos plugins pré-compilados e dois tipos de webhooks de controle de admissão. No entanto, criar webhooks e controladores específicos pode oferecer mais flexibilidade e controle preciso.

Os controladores de admissão e os webhooks permitem que projetos como OPA Gatekeeper e Kyverno ofereçam mecanismos de políticas. Além disso, é fácil implementar um sistema de admissão personalizado por meio de webhooks HTTP em qualquer linguagem capaz de enviar respostas HTTP com um payload JSON.

Em resumo, os controladores de admissão são apenas um componente de uma estratégia abrangente de segurança do Kubernetes. Há riscos e vulnerabilidades em cada etapa do ciclo de vida de desenvolvimento de software, mas atenuá-los não precisa interromper todo o fluxo de trabalho. Uma organização com foco em segurança pode oferecer insights valiosos para ajudar você a encontrar a especialização certa.

Chris Laux desenvolve software há mais de 20 anos, usando diversas linguagens.