APRENDER. PRATICAR. EVOLUIR.Diagnosticar a operação que o cliente efetua
Um batch pode fazer GET de configuração no arranque e depois abrir LIST e WATCH para acompanhar alterações. O primeiro sucesso não prova os outros caminhos. Quando resourceNames limita o objeto, o cliente precisa do field selector de nome nos pedidos de list ou watch correspondentes. No exercício, settlement-config existe e a conta consegue fazer GET, mas o watcher envia um pedido sem selector. Confirma a operação e o pedido efetivo antes de remover a restrição. O teste de aceitação deve usar a identidade do batch e incluir um nome que continue recusado.
Rever criação e troca de delegação
Restringir o nome de um objeto existente não resolve toda a governação da sua criação. Para create de um recurso principal, não uses resourceNames como garantia de que só aquele nome será criado. Podes separar provisionamento e manutenção ou avaliar admissão apropriada. Noutra mudança, roleRef é imutável: trocar reader por operator exige substituir o binding, revendo todos os subjects. Planeia a transição para evitar perda de acesso operacional ou sobreposição desnecessária. Uma autorização de projeto deve dizer quem recebe cada operação e qual evidência confirma o novo limite.
Distinguir apresentação e autorização
Uma tabela que apresenta nomes de Secrets não significa que list só permite ler nomes. A resposta da API pode incluir conteúdo, por isso o grant tem de ser revisto como acesso sensível. Também distingue os dois namespaces numa RoleBinding: o namespace do subject identifica a ServiceAccount e o do binding delimita o acesso concedido. No exemplo, runner de ci recebe operações em funds-prod. Escreve estas duas dimensões no handover. Evita provar acesso apenas com uma conta administrativa, pois isso pode esconder uma delegação ao principal errado.
Confirmar os controlos efetivos do processo
Um UID não root é uma parte do desenho, mas não substitui a revisão das capabilities. Num container Linux Restricted v1.35, o add-back admitido pelo padrão após drop ALL é NET_BIND_SERVICE; a necessidade deve ser justificada. RuntimeDefault também não significa que todos os runtimes fornecem perfis seccomp iguais. Uma mudança de runtime pode alterar a syscall permitida. Compara runtime, perfil e operação que falhou antes de abrir privilégios. Documenta o teste funcional e o comportamento que deve continuar bloqueado após a correção, com responsável por manter o controlo.
Mapear superfícies graváveis e handlers
readOnlyRootFilesystem não transforma automaticamente os volumes montados em superfícies só de leitura. No caso /work, revê o mount, permissões, persistência e necessidade de escrita. Para isolamento adicional, uma RuntimeClass declara um handler, mas não o instala nos nodes. Se os novos nodes falham e os antigos funcionam, compara provisionamento e elegibilidade de scheduling. Uma mitigação pode usar capacidade já preparada quando isso estiver autorizado e for suficiente. A correção deve abranger o próximo node criado, para não repetir uma reparação manual em cada expansão de capacidade.
Entregar uma matriz de aceitação a RUN
Prepara uma matriz pequena com principal, operação, objeto, âmbito, resultado esperado e evidência. Inclui GET e watcher da configuração, leitura recusada de outro objeto, comportamento no pool novo e escrita limitada ao volume previsto. Cada teste responde a uma afirmação concreta; uma captura de sucesso isolada não prova todas as linhas. Regista como reverter a mudança e como confirmar que a conta de operação continua autónoma. Os exercícios desta aula são decisões e modelos sintéticos, não uma execução de cluster nem uma verificação das políticas de um banco real.
O GET do batch funciona, mas o watcher sem selector falha; a correção do pedido conserva a restrição e permite o fecho.
Armadilhas comuns
Confundir GET com LIST; delegar à conta de outro namespace; tratar UID como revisão completa; assumir que RuntimeClass instala o handler.
Tópicos relacionados: RBAC e ServiceAccounts · Seccomp e isolamento de workloads
O acesso mínimo e o isolamento devem ser demonstrados com o pedido, processo e node que executarão o trabalho.
Referência: RBAC authorization · Kubernetes v1.35; current six-domain CKS outline