APRENDER. PRATICAR. EVOLUIR.Testar a identidade que vai operar
O administrador do cluster descartável cria uma ServiceAccount support e pede um token temporário através de TokenRequest. Um kubeconfig privado usa esse token para executar os pedidos de suporte. O guião não usa impersonation e não apresenta o token nos relatórios. Antes dos grants, um get ao Pod worker recebe Forbidden, mostrando que a credencial autenticada não tem a autorização pedida. As credenciais administrativas ficam limitadas à preparação e às alterações de política do ensaio. Num ambiente real, o acesso humano pode depender de SSO e grupos; este laboratório não valida essa integração nem substitui os testes da identidade que será usada pela equipa.
Ler o objeto não permite todas as operações
O primeiro Role permite get, list e watch sobre pods e é associado à ServiceAccount por um RoleBinding no namespace do ensaio. O pedido ao Pod e a listagem passam a funcionar. A tentativa de obter logs continua recusada porque usa o subrecurso pods/log. O laboratório acrescenta um Role para get desse subrecurso, restrito ao nome worker. Os logs de worker passam a estar disponíveis, enquanto os de placement continuam recusados. A regra precisa de refletir a tarefa e o recurso correto. Para workloads cujos nomes mudam, a restrição por nome exige um desenho de suporte compatível com essa renovação.
Âmbito e testes negativos
A mesma ServiceAccount tenta ler um Pod no namespace de quotas e recebe Forbidden. Também não consegue listar Secrets, executar um comando no contentor ou pedir uma eliminação de Pod em dry-run server. O Pod worker mantém-se em execução. Estes testes distinguem acesso de diagnóstico de capacidade para executar ou alterar trabalho. A recusa de dry-run é relevante porque pedir ausência de persistência não elimina a autorização necessária à operação. O ensaio não concede permissões globais nem modifica políticas de outros namespaces existentes. Para aceitação, conserva exemplos de ações permitidas e recusadas, com identidade, âmbito e resultado observável.
Consultar autorização e executar a tarefa
Com os grants ativos, auth can-i confirma leitura de Pods, leitura dos logs de worker e recusa de Secrets. O laboratório complementa a consulta com pedidos reais: leitura de Pods e logs e tentativa de listar Secrets. A consulta de autorização ajuda a localizar uma recusa, mas não demonstra que a aplicação produz logs úteis, que a rede está disponível ou que o processo está saudável. Um resultado yes deve ser interpretado com o recurso, verbo, subrecurso, nome e namespace usados na pergunta. Regista a consulta exata e evita extrapolar de get pods para exec ou de um namespace para todos. A aceitação completa liga a permissão ao fluxo de suporte que precisa de funcionar.
Grants aditivos e revogação parcial
O ensaio cria dois RoleBindings que concedem o mesmo acesso aos logs. Depois de remover o primeiro, o pedido continua autorizado através do segundo. Isto não é uma falha de revogação nem uma regra deny ignorada: as permissões RBAC são aditivas. Retirar uma origem de acesso não apaga as restantes. O guião remove então o segundo binding e confirma que os logs são recusados, enquanto a leitura do Pod continua permitida pelo Role reader. Só depois retira reader e confirma a recusa do get. Num incidente de acesso excessivo, identifica todos os grants aplicáveis e valida o resultado após cada alteração autorizada.
Encerrar credenciais e preservar os limites
O guião remove os namespaces que criou e apaga o diretório privado com a credencial de suporte e caches locais. O token não é guardado na evidência. A execução usa um cluster de um node, uma aplicação sintética e permissões criadas apenas para o ensaio. Não cobre SSO empresarial, gestão de grupos externos, políticas de rede, resiliência distribuída, carga ou revisão humana. No handover fictício para APS, entrega a matriz de operações, os resultados positivos e negativos e os procedimentos de revogação. A revisão especializada deve avaliar se essa matriz é adequada às responsabilidades reais e como será mantida quando os workloads e equipas mudarem.
# Use a dedicated temporary support kubeconfig; never put tokens in reports.
kubectl --kubeconfig SUPPORT_CONFIG -n LAB get pod worker
kubectl --kubeconfig SUPPORT_CONFIG -n LAB logs worker
kubectl --kubeconfig SUPPORT_CONFIG -n LAB auth can-i get pods/worker --subresource=log
# Also test expected denials and revoke every applicable grant at closure.Ler Pods não permitiu ler logs; um Role separado autorizou apenas pods/log do Pod worker e deixou exec, Secrets e outro namespace recusados.
Armadilhas comuns
Ler Pods como acesso a logs ou exec; RoleBinding como permissão global; retirar um binding como revogação de todos os caminhos.
Tópicos relacionados: Recursos e agendamento · Acesso mínimo para suporte
Valida o acesso efetivo com a identidade prevista e repete as verificações depois de conceder ou retirar permissões.
Referência: Using RBAC authorization · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed