|
Este documento foi traduzido usando tecnologia de tradução automática de máquina. Sempre trabalhamos para apresentar traduções precisas, mas não oferecemos nenhuma garantia em relação à integridade, precisão ou confiabilidade do conteúdo traduzido. Em caso de qualquer discrepância, a versão original em inglês prevalecerá e constituirá o texto official. |
|
Esta é uma documentação não divulgada para Admission Controller 1.34-dev. |
Rego
|
O suporte ao Rego está disponível a partir dessas versões:
As políticas Rego suportam dados sensíveis ao contexto disponíveis a partir da versão SUSE Security Admission Controller 1.9. |
A linguagem Rego é uma linguagem de domínio específico para habilitar políticas como código. Rego é uma linguagem inspirada em Datalog.
Existem duas maneiras de escrever políticas Rego para implementar políticas como código no Kubernetes, Agente de Política Aberta e Gatekeeper.
As próximas seções mostram como os dois frameworks são diferentes, mesmo usando a mesma linguagem. Se você estiver mais interessado na implementação Admission Controller, pode visitar diretamente a documentação específica do framework vinculada abaixo.
Uma linguagem, dois frameworks
Agente de Política Aberta (OPA)
O Agente de Política Aberta é um projeto que permite implementar políticas como código em qualquer projeto. Você pode usar OPA para qualquer verificação baseada em políticas que seu aplicativo precisar.
Nesse contexto, escrever políticas para o Kubernetes é simplesmente usar o OPA. Usando webhooks de admissão do Kubernetes, é possível avaliar solicitações usando OPA, que executa as políticas escritas em Rego.
OPA tem integração opcional com Kubernetes através de seu kube-mgmt sidecar.
Quando implantado no Kubernetes, e com o servidor OPA avaliando as políticas Rego,
ele é capaz de replicar os recursos configurados do Kubernetes em Rego.
Assim, esses recursos do Kubernetes são visíveis para todas as políticas.
Com OPA, você pode definir políticas dentro dos objetos ConfigMap do Kubernetes.
Você pode ler mais sobre isso na página do projeto.
Analisando as diferenças
Tanto as políticas do OPA quanto as do Gatekeeper usam Rego para descrever políticas como código. Cada solução tem diferenças quando se trata de escrever políticas em Rego, como mostrado nas próximas seções.
Ponto de entrada
O ponto de entrada é o nome de uma regra dentro de um pacote, e é a regra invocada pelo runtime quando a política é executada.
Limitações atuais
Políticas contextuais
Políticas contextuais são políticas que não avaliam a solicitação de entrada de forma isolada.
Elas levam outros fatores em consideração para tomar uma decisão.
Por exemplo, uma política que avalia recursos com namespace, e usa uma anotação, no namespace pai para configurar algo na política.
Outro exemplo seria uma política que avalia Ingress recursos, mas para tomar uma decisão também possui a lista dos Ingress recursos existentes.
A ideia de políticas contextuais também pode se estender a recursos personalizados, então sua política pode querer avaliar uma solicitação com base nos recursos personalizados atualmente utilizados também.
Tanto o OPA quanto o Gatekeeper suportam políticas contextuais a partir da versão Admission Controller 1.9.
Mais detalhes sobre políticas contextuais estão aqui.
Políticas de mutação
O Gatekeeper tem suporte para políticas de mutação, mas Admission Controller ainda não implementou políticas de mutação com compatibilidade com o Gatekeeper. Você pode usar políticas que utilizam o SDK Admission Controller para escrever políticas de mutação, mas atualmente, você não pode executar políticas de mutação do Gatekeeper em Admission Controller.