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.

Políticas contextuais

O policy-server tem a capacidade de expor informações do cluster para políticas, de modo que possam tomar decisões com base em outros recursos existentes, e não apenas com base nos detalhes fornecidos pela solicitação de admissão.

O Servidor de Políticas que hospeda a política recupera recursos do Kubernetes. Regras RBAC aplicadas à Conta de Serviço do Servidor de Políticas regulam o acesso ao Kubernetes.

O Servidor de Políticas default implantado pelos gráficos Helm SUSE Security Admission Controller tem acesso aos seguintes recursos do Kubernetes:

Namespaces
Serviços
Ingress

O servidor de políticas realiza o cache dos resultados obtidos do servidor da API do Kubernetes para reduzir a carga sobre essa parte central do Kubernetes. Isso significa que as informações podem estar desatualizadas ou ausentes.

Matriz de suporte

Tipo de política	Suporte	Notes
Linguagens de programação tradicionais	✅	-
Rego	✅	Desde o lançamento Admission Controller 1.9
WASI	✅	Desde a versão Admission Controller 1.10.0, apenas para o SDK Go

Tipo de política

Suporte

Notes

Linguagens de programação tradicionais

✅

Rego

✅

Desde o lançamento Admission Controller 1.9

WASI

✅

Desde a versão Admission Controller 1.10.0, apenas para o SDK Go

Restrições

A prioridade de Admission Controller é reduzir o número de consultas ao servidor API do Kubernetes. Admission Controller considera duas restrições:

Uso da memória: O processo do Policy Server armazena em cache os dados obtidos do Kubernetes na memória. Quanto mais dados forem obtidos, mais memória os Pods do Policy Server consomem.
Consistência: O cache mantido pelo Policy Server pode conter dados desatualizados. Novos recursos podem estar ausentes, recursos deletados podem ainda estar disponíveis e os alterados podem ter dados antigos. Isso pode afetar a avaliação de políticas.

Listando múltiplos recursos

As políticas de Admission Controller podem buscar múltiplos recursos ao mesmo tempo. Por exemplo, elas podem fazer uma consulta como "obter todos os Pods definidos dentro do namespace default que têm o rótulo color definido como green".

Com tal consulta, o Policy Server busca todos os recursos que correspondem aos critérios do usuário. A busca de recursos é feita em lotes para reduzir a carga no servidor API do Kubernetes. Antes de armazenar os recursos na memória, o Policy Server descarta o atributo managedFields de cada recurso para reduzir a quantidade de memória consumida. Esse atributo não é útil para políticas e consome uma quantidade significativa de memória.

O Policy Server então cria um watch do Kubernetes para manter a lista de objetos em cache atualizada. O Policy Server não controla a velocidade com que o servidor API do Kubernetes envia notificações sobre mudanças de recursos. Isso depende de diferentes fatores externos, como o número de watches criados contra o servidor API do Kubernetes e sua carga.

Finalmente, o código atual tem a seguinte limitação. Dadas essas duas consultas:

kubectl get pods -n default
kubectl get pods -n default -l color=green

O Policy Server cria duas watches e duplica todos os Pods da segunda consulta. Essa limitação será removida em futuras versões do Admission Controller.

Buscando um recurso específico

As políticas de Admission Controller podem obter um recurso específico definido dentro do cluster. Por exemplo, elas podem fazer uma consulta como "obter o Pod chamado psql-0 definido dentro do namespace db."

Por padrão, essa consulta busca o objeto e o armazena em um cache na memória por cinco segundos. Durante esses cinco segundos, as políticas recebem dados em cache.

O autor da política também pode decidir fazer uma consulta direta, pulando o cache. Dados frescos são sempre fornecidos. Isso causa mais carga no servidor API do Kubernetes (dependendo da frequência de acionamento da política) e introduz mais latência na avaliação de uma solicitação de admissão.

O comportamento da consulta direta ou em cache é configurado em nível de consulta pelo autor da política usando os SDKs do Admission Controller.

ClusterAdmissionPolicies

As ClusterAdmissionPolicies têm o campo spec.contextAwareResources. Esse campo fornece uma lista de recursos GroupVersionKind que a política precisa acessar. Isso permite que os autores de políticas incluam as "permissões" que a política precisa junto com a política. Além disso, isso permite que os operadores de políticas revisem as "permissões" necessárias pela política no momento da implantação.

Testando políticas contextuais localmente

Além de executar políticas em um cluster para testes de ponta a ponta, você pode usar a utilidade CLI do kwctl para executar políticas e simular solicitações contra o cluster.

Para isso, kwctl run pode primeiro registrar todas as interações com o cluster em um arquivo:

kwctl run \
    --allow-context-aware \
    -r request.json \
    --record-host-capabilities-interactions replay-session.yml \
    annotated-policy.wasm

que cria o seguinte arquivo replay-session.yml:

# replay-session.yml
---
- type: Exchange
  request: |
    !KubernetesGetResource
    api_version: /v1
    kind: Pod
    name: p-testing
    namespace: local
    disable_cache: true
  response:
    type: Success
    payload: '{"apiVersion":"","kind":"Pod", <snipped> }'

Usando a sessão de reprodução, você pode agora simular as interações do cluster sem a necessidade de um cluster, o que é ideal para testes de CI e de ponta a ponta:

kwctl run \
    --allow-context-aware \
    -r request.json \
    --replay-host-capabilities-interactions replay-session.yml \
    annotated-policy.wasm

SDKs de Linguagem

Os SDKs de Linguagem que suportam o contexto do cluster expõem funções que permitem que as políticas recuperem o estado atual do cluster.

Se você quiser mais informações sobre a função waPC usada pelos SDKs, consulte a documentação de referência capacidades do Kubernetes.

Rust

Veja as funções que expõem essa funcionalidade na https://docs.rs/kubewarden-policy-sdk/0.8.7/kubewarden_policy_sdk [documentação de referência do SDK Rust].

Ir

Veja as funções que expõem essa funcionalidade na https://pkg.go.dev/github.com/kubewarden/policy-sdk-go [documentação de referência do SDK Go].

Políticas Rego

Gatekeeper

A exposição de informações contextualmente conscientes está sob a chave data.inventory, como o Gatekeeper.

A população do inventário é feita com os recursos aos quais a política tem acesso através do campo spec.contextAwareResources.

Agente de Política Aberta

A exposição de informações contextualmente conscientes está sob a chave data.kubernetes, como kube-mgmt faz por padrão.

A população do inventário é feita com os recursos aos quais a política tem acesso através do campo spec.contextAwareResources.