SUSE Security Admission Controller vs OPA Gatekeeper

Tanto o OPA Gatekeeper quanto o Kubernetes podem escrever políticas de validação e mutação.

Essas políticas podem direcionar qualquer tipo de recurso do Kubernetes, incluindo Recursos Personalizados.

Você escreve políticas do OPA Gatekeeper usando Rego. Rego é uma linguagem de consulta criada pelo projeto Open Policy Agent.

Você pode escrever Admission Controller políticas usando diferentes paradigmas. Os autores de políticas podem usar tanto linguagens de programação tradicionais (como Go, Rust e outras) quanto Linguagens Específicas de Domínio como Rego e CEL. Nos Admission Controller’s você escreve políticas de validação e mutação da mesma forma.

Às vezes, uma política precisa de dados sobre o estado atual do cluster para tomar uma decisão de validação ou mutação. Por exemplo, uma política que valida recursos de Ingress pode precisar saber sobre outros recursos de Ingress já definidos no cluster para garantir que não ocorram conflitos. Admission Controller chama essas políticas de "conscientes do contexto".

Tanto OPA Gatekeeper quanto Admission Controller suportam esses tipos de políticas.

Ao implantar o OPA Gatekeeper, um administrador do Kubernetes decide qual tipo de dados do cluster disponibilizar para as políticas no momento da avaliação.

É importante destacar como esses dados são então acessíveis por todas as políticas implantadas.

Por exemplo, se uma política do OPA Gatekeeper requer acesso a Segredos do Kubernetes, todas as outras políticas implantadas também conseguem ler esses dados.

Por outro lado, Admission Controller fornece um acesso granular aos recursos do cluster. Cada política tem acesso apenas aos recursos que o administrador do Kubernetes especifica. Tentar ler dados não autorizados é imediatamente bloqueado e reportado aos administradores do cluster.

OPA Gatekeeper possui um Recurso Personalizado em todo o cluster, permitindo a definição de políticas e como e onde aplicá-las.

Admission Controller possui dois tipos diferentes de Recursos Personalizados usados para declarar políticas. Um funciona no nível do cluster, o outro é com namespace. O nome do Recurso Personalizado com namespace é AdmissionPolicy.

As políticas implantadas via um recurso AdmissionPolicy afetam apenas os recursos criados dentro do namespace ao qual pertencem. Por causa disso, você pode permitir que usuários do Kubernetes que não são administradores tenham os privilégios RBAC necessários para gerenciar AdmissionPolicy recursos, nos namespaces que podem acessar.

Isso permite que administradores do Kubernetes deleguem trabalho relacionado a políticas.

OPA Gatekeeper e Admission Controller políticas têm código-fonte de política (Rego para OPA Gatekeeper, CEL para Admission Controller) no Recurso Personalizado que define uma política no Kubernetes.

Além disso, Admission Controller políticas podem ter o código-fonte da política gerenciado como imagens de contêiner (para Rego, Go, Rust, …​). Uma vez construídas, elas são enviadas para registros de contêiner como artefatos OCI.

Você pode assinar e verificar Admission Controller políticas usando ferramentas de imagem de contêiner como cosign, do projeto Sigstore project.

Você pode distribuir políticas Admission Controller entre registros de contêiner geograficamente distribuídos usando as ferramentas e processos tradicionais adotados para imagens de contêiner.

Tanto OPA Gatekeeper quanto Admission Controller são gerenciados usando metodologias GitOps.

No entanto, para OPA Gatekeeper, há um acoplamento entre o código Rego da política e o Recurso Personalizado usado para implantá-la no Kubernetes. Isso introduz etapas extras nos pipelines de CI/CD.

Rego possui ferramentas de teste que permitem a criação de suítes de testes unitários. Escrever testes e executá-los em um pipeline de CI/CD é essencial para garantir que as políticas se comportem como esperado.

Para usar essas ferramentas de teste, o código-fonte da política deve estar disponível em arquivos de texto dedicados. É impossível ler o código-fonte dos arquivos YAML usados para declarar a política do OPA Gatekeeper. O pipeline de CI/CD deve sincronizar o código-fonte Rego para testar com o código definido no Recurso Personalizado do OPA Gatekeeper. Você pode fazer isso usando ferramentas de terceiros.

Admission Controller políticas têm pipelines de CI/CD como microserviços tradicionais. Normalmente, seu código-fonte reside em um repositório Git e, em seguida, usando sistemas tradicionais de CI/CD, testes unitários são executados contra ele. Você escreve testes unitários usando os frameworks de teste da linguagem utilizada para escrever a política. Uma vez que todos os testes passam, você compila a política para WebAssembly e a envia para um registro de contêiner. Esse tipo de pipeline é geralmente mantido pelo autor da política.

Administradores do Kubernetes normalmente mantêm outros pipelines de automação que reagem a novas versões da política (usando ferramentas de automação como Dependabot, Renovate bot, updatecli e outras), ou a mudanças na configuração da política.

O pipeline testa a política contra diferentes tipos de solicitações. Você pode realizar os testes usando a ferramenta CLI kwctl, sem precisar de um cluster Kubernetes em execução. A ferramenta CLI kwctl usa o mesmo mecanismo de avaliação utilizado pela pilha Admission Controller implantada em um cluster Kubernetes.

Tanto o OPA Gatekeeper quanto Admission Controller podem implantar políticas usando dois modos de operação diferentes:

O mesmo servidor avalia todas as políticas do OPA Gatekeeper. Por outro lado, Admission Controller permite a definição de múltiplos servidores de avaliação. Você define esses servidores por um Recurso Personalizado chamado PolicyServer.

Ao declarar uma Admission Controller política, o administrador do Kubernetes decide qual PolicyServer a hospeda.

Isso permite cenários interessantes como os seguintes:

À medida que políticas são adicionadas, removidas e reconfiguradas, os recursos já no cluster podem se tornar não conformes.

Tanto o OPA Gatekeeper quanto Admission Controller possuem um scanner que opera em segundo plano. Esse scanner avalia os recursos já definidos no cluster e sinaliza os não conformes.

A única diferença entre o OPA Gatekeeper e Admission Controller é como os resultados do scanner são salvos.

O OPA Gatekeeper adiciona os detalhes da violação ao campo status de um dado Constraint Recurso Personalizado (veja aqui).

Admission Controller em vez disso armazena os resultados dentro de um conjunto dos Recursos Personalizados de Relatórios definidos por openreports.io.