Conceito e mecanismo
RBAC controla ações sobre recursos da API. Uma Role descreve permissões num namespace; um binding liga regras a sujeitos. Uma RoleBinding pode referenciar uma ClusterRole e conceder as permissões relevantes apenas no seu namespace. As permissões RBAC são aditivas: acrescentar uma Role mais restrita não anula uma autorização mais ampla já existente. Para suporte, identifica sujeito, verbo, recurso, subresource e âmbito necessários. Ler Pods e ler pods/log não são exatamente a mesma operação. Um erro Forbidden pode indicar autenticação válida com autorização insuficiente; não exige entregar cluster-admin nem substituir credenciais sem primeiro observar qual a ação recusada.
Aplicação guiada
NetworkPolicy trata comunicação de rede e precisa de uma implementação que a suporte. Aceitar o objeto na API não prova que o tráfego passou a ser filtrado. As permissões de políticas aplicáveis combinam-se; uma regra adicional de deny não substitui automaticamente permissões existentes. Para uma ligação entre Pods isolados, considera egress da origem e ingress do destino, assim como DNS e portas necessárias. Num exercício fictício, uma equipa autoriza consultas à base no destino mas esquece o egress da API. Analisa os dois lados e concede o fluxo específico. Permissão RBAC para ler o Service não autoriza tráfego de aplicação, e uma política de rede não concede leitura de Secrets na API. São controlos complementares com evidência diferente.
Um operador lê Pods mas recebe Forbidden para pods/log: confirma o subresource e o binding antes de alargar o acesso.
Armadilhas comuns
Role restrita como deny; objeto NetworkPolicy como enforcement; cluster-admin como diagnóstico.
Tópicos relacionados: Workloads e estado desejado · Tráfego e probes · Recursos e agendamento
Concede a operação e o fluxo necessários no âmbito correto.
Referência: RBAC roles bindings and subresources · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed