Resumo

  • Uma ValidatingAdmissionPolicyBinding liga política, escopo, parâmetros opcionais e ações declaradas; não é um comprovante de resultado para uma solicitação concreta.
  • A documentação do Kubernetes separa correspondência, resolução de parâmetros, avaliação, tratamento de falhas, ação e resposta.
  • Uma trilha responsável conserva a configuração observada e a evidência da solicitação como registros diferentes, com autores e tempos próprios.

Uma política vinculada pode parecer uma decisão concluída. Há um nome de política, condições que delimitam recursos e ações como Deny, Warn e Audit. A leitura rápida transforma essa combinação em “o cluster bloqueia isto”. Mas a vinculação fala antes de uma possibilidade configurada: liga a lógica de uma política a um recorte de recursos e, se for o caso, a parâmetros. Não identifica uma solicitação, não demonstra que ela atingiu a camada de admissão e não mostra a resposta que o servidor devolveu.

O primeiro limite aparece na própria referência da API. Uma ValidatingAdmissionPolicyBinding liga uma política a recursos parametrizados; seus matchResources são cruzados com os matchConstraints da política. A solicitação precisa satisfazer o lado da política antes de ser selecionada pela vinculação. Isso desenha uma rota possível. Não prova que um recurso específico atravessou a interseção. Pode não ter chegado solicitação alguma; uma solicitação pode ter ficado fora do escopo; outro controlador pode ter alterado ou recusado a operação mais adiante.

Os parâmetros acrescentam outra decisão que não pode ser presumida. A vinculação pode referenciar o recurso usado para parametrizar a política. Kubernetes diferencia uma referência resolvida de uma referência inexistente; a ausência pode tornar a vinculação mal configurada e tornar relevante a política de falhas. Política, vinculação, recurso de parâmetro e configuração de falha são superfícies distintas. Registrar cada uma melhora o controle, mas não transforma sua presença em prova de que uma carga foi aceita, negada ou protegida.

Também é incorreto usar failurePolicy como se fosse a ação diante de qualquer validação falsa. Kubernetes reserva esse campo para falhas de análise, tipagem, execução ou configuração. A reação quando uma validação avalia como falsa vem das validationActions da vinculação. Deny resulta em solicitação negada nessa situação; Warn comunica um aviso ao cliente; Audit inclui a falha no evento de auditoria da solicitação. Cada termo pertence a uma etapa diferente: erro, resultado de expressão, ação configurada e efeito visível. Nenhum, sozinho, demonstra o destino de um objeto real.

O momento do controle amplia a cautela. A documentação situa a admissão depois de autenticação e autorização, antes da persistência. Há fases mutante e validante, e uma recusa em qualquer uma delas encerra a solicitação. A vinculação não informa quem enviou a solicitação, se a autorização anterior permitiu a operação, se uma mutação alterou o objeto, se outro mecanismo decidiu pela recusa ou se houve persistência. Operações de leitura não passam pela admissão. Por isso, um inventário de vinculações não é uma narrativa completa do que um cluster fez.

Há uma forma mais forte, embora mais limitada, de evidência. Para falhas de validação, Kubernetes documenta uma anotação de auditoria associada à solicitação que identifica política, vinculação, expressão e ações. Ela pode sustentar uma afirmação sobre aquela solicitação. Não permite concluir, sem outros registros, que todas as solicitações semelhantes tiveram igual resposta ou que o objetivo de segurança foi atingido. A delimitação é justamente o que impede a prova de se tornar propaganda.

O método proposto é conservar dois recibos. O de configuração registra identidades e versões observadas, escopo, parâmetros, política de falhas, ações e tempo de coleta. O de resultado registra a solicitação, instante, critérios que combinaram ou excluiram, estado dos parâmetros, avaliação, ação, resposta e indício de persistência ou recusa. Não é um modelo obrigatório do Kubernetes. É uma maneira de não deixar que uma declaração limpa assuma a autoridade de um acontecimento que não registrou.

Fontes

  1. Referência da API Kubernetes — ValidatingAdmissionPolicyBinding
  2. Referência da API Kubernetes — ValidatingAdmissionPolicy
  3. Tutorial Kubernetes — Políticas de admissão
  4. Documentação Kubernetes — Controladores de admissão
  5. Documentação Kubernetes — Anotações de auditoria