RBAC no Kubernetes: o controle de acesso baseado em funções explicado

Se você roda qualquer coisa no Kubernetes, o RBAC no Kubernetes é o controle que decide quem pode ler seus Secrets, apagar seus pods ou, silenciosamente, conceder a si mesmo as chaves do cluster inteiro. O Role-Based Access Control (controle de acesso baseado em funções) é o sistema de autorização do Kubernetes que mapeia subjects — usuários, grupos e ServiceAccounts — para as ações específicas que têm permissão de executar sobre resources específicos. Acerte e um workload comprometido permanece confinado ao seu namespace. Erre e um único token vazado vira uma violação em todo o cluster. Este mergulho detalhado percorre como o RBAC realmente funciona, onde as equipes se queimam e como aplicar o controle de acesso baseado em funções no Kubernetes com menor privilégio como padrão. Faz parte do nosso guia mais amplo de segurança no Kubernetes.

O que é o RBAC e por que ele importa no Kubernetes

Toda requisição que chega ao API server do Kubernetes — venha de uma pessoa executando kubectl, de um controller ou de um pod conversando com a API — passa por três portões: autenticação (quem é você?), autorização (você tem permissão para isso?) e admission control (este objeto específico deve ser aceito?). O RBAC é o mecanismo de autorização mais usado para o portão do meio.

O que torna o RBAC tão importante é o raio de impacto por trás dele. A API do Kubernetes é o control plane de tudo: workloads, Secrets, política de rede, configuração de node. Um subject com poder de API suficiente pode ler todas as credenciais do cluster, lançar pods privilegiados ou alcançar os nodes subjacentes. O RBAC é a fronteira que mantém um trabalho restrito de fato restrito. Quando é permissivo demais, torna-se o caminho mais curto de uma brecha inicial ao comprometimento total — que é exatamente por que os atacantes o enumeram cedo.

O RBAC é o modo de autorização padrão no Kubernetes há anos e está habilitado em praticamente toda distribuição gerenciada ou self-hosted que você vai encontrar. A pergunta quase nunca é se você o usa, mas com quanto cuidado.

Objetos centrais: Roles, bindings, ServiceAccounts e subjects

O RBAC é construído a partir de quatro objetos da API, mais as identidades a que se aplicam. O modelo mental é simples assim que a ficha cai: dois objetos dizem o que é permitido, dois objetos dizem quem recebe.

Roles e ClusterRoles definem um conjunto de permissões. Elas são puramente aditivas — uma Role é apenas uma lista de coisas permitidas, sem nenhum conceito de negação.

• Uma Role é escopada a namespace. Suas permissões se aplicam apenas dentro do único namespace em que ela vive.
• Uma ClusterRole tem escopo de cluster. Ela pode conceder acesso a resources de todo o cluster (nodes, PersistentVolumes), a endpoints que não são resources (como /healthz) ou a resources de namespace em todos os namespaces.

Aqui está uma Role mínima que permite ler pods em um único namespace:

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

  namespace: team-payments

  name: pod-reader

rules:

- apiGroups: [""] # "" is the core API group

  resources: ["pods"]

  verbs: ["get", "list", "watch"]

RoleBindings e ClusterRoleBindings anexam uma Role ou ClusterRole a um conjunto de subjects.

• Um RoleBinding concede permissões dentro de um namespace específico. Ele pode referenciar uma Role naquele namespace ou — de forma útil — uma ClusterRole, caso em que as regras da ClusterRole se aplicam apenas dentro do namespace do binding.
• Um ClusterRoleBinding concede permissões por todo o cluster. Este é o objeto a tratar com mais desconfiança, porque remove por completo as fronteiras de namespace.

apiVersion: rbac.authorization.k8s.io/v1

kind: RoleBinding

metadata:

  name: read-pods

  namespace: team-payments

subjects:

- kind: ServiceAccount

  name: reporting

  namespace: team-payments

roleRef:

  kind: Role

  name: pod-reader

  apiGroup: rbac.authorization.k8s.io

Subjects são as identidades na ponta receptora. O Kubernetes reconhece três tipos:

• Users e Groups — identidades humanas ou externas. O Kubernetes não tem banco de usuários próprio; essas identidades vêm da sua camada de autenticação (certificados, OIDC e afins), e o RBAC simplesmente as referencia pelo nome.
• ServiceAccounts — identidades internas ao cluster, destinadas a workloads. Todo pod roda como um ServiceAccount, e é por essa conta que o pod se autentica no API server. Os ServiceAccounts são as identidades que você vai escopar com mais frequência, porque representam seu código em execução.

Um padrão comum e poderoso é definir conjuntos de permissões amplos e reutilizáveis como ClusterRoles e depois distribuí-los de forma restrita com RoleBindings por namespace. Isso mantém a definição DRY enquanto mantém a concessão enxuta.

Verbs e resources: a gramática de uma regra

Cada regra em uma Role ou ClusterRole responde a três perguntas: qual API group, quais resources e quais verbs.

Resources são os tipos de objeto — pods, deployments, secrets, configmaps e assim por diante. Você pode restringir ainda mais para subresources como pods/log ou pods/exec, e até para nomes de objetos específicos com resourceNames.

Verbs são as ações. Os mais comuns são get, list, watch, create, update, patch e delete (além de deletecollection). Vale internalizar que eles não são todos iguais:

• list e watch retornam o conteúdo dos objetos, não apenas os nomes. Conceder list em Secrets efetivamente concede acesso de leitura a todos os Secrets no escopo — uma surpresa frequente.
• create em pods, combinado com o namespace certo, pode bastar para executar código arbitrário no cluster.
• pods/exec e pods/attach permitem que um subject abra um shell dentro de contêineres em execução.

Curingas (*) são aceitos para apiGroups, resources e verbs, e são a maior fonte isolada de excesso acidental de permissões. verbs: ["*"] em resources: ["*"] é cluster-admin em tudo, menos no nome.

Como a autorização é avaliada: aditiva e deny-by-default

Duas regras governam como o Kubernetes transforma seus bindings em uma decisão de sim ou não, e ambas importam para raciocinar sobre segurança.

Primeiro, o RBAC é deny-by-default. Se nenhuma regra permite explicitamente uma requisição, ela é negada. Um ServiceAccount recém-criado não consegue fazer essencialmente nada até você vincular uma role a ele.

Segundo, o RBAC é puramente aditivo — não há regras de negação. Quando chega uma requisição, o autorizador verifica se alguma Role ou ClusterRole vinculada ao subject a permite. Se alguma permite, a requisição é liberada; as demais são irrelevantes. Você não pode escrever uma regra que diga "permitir tudo, exceto apagar Secrets". A única forma de reter uma permissão é nunca concedê-la de início.

A consequência prática: você não pode remendar uma concessão ampla demais com uma negação pontual. Se um subject acaba com poder demais, você precisa encontrar e corrigir o binding que o concedeu. É por isso que bindings dispersos e sobrepostos são perigosos — as permissões efetivas de um subject são a união de tudo que está vinculado a ele, e é fácil perder o controle dessa união.

Menor privilégio na prática

O menor privilégio é todo o propósito do RBAC, e no Kubernetes ele se resume a alguns hábitos concretos.

Escope para namespaces por padrão. Prefira Roles e RoleBindings a seus primos com escopo de cluster. A maioria dos workloads e das equipes opera dentro de um namespace; raramente há motivo para conceder alcance por todo o cluster. Reserve os ClusterRoleBindings para questões genuinamente de todo o cluster (um agente de monitoramento que precise ler todos os nodes, por exemplo) e revise cada um deliberadamente.

Evite curingas. Nomeie os resources e verbs específicos de que você precisa. ["get", "list", "watch"] em ["configmaps"] diz a um revisor — e a um scanner — exatamente o que uma role faz. ["*"] não lhes diz nada e esconde o avanço futuro de escopo.

Nunca distribua `cluster-admin` sem critério. A ClusterRole embutida cluster-admin é acesso irrestrito a tudo. Vinculá-la a uma pessoa "para desbloqueá-la" ou a um workload "para fazer o erro sumir" é a forma mais comum de os clusters acabarem escancarados. Se alguém realmente precisa dela, conceda de forma restrita e temporária, em vez de por um ClusterRoleBinding permanente.

Dimensione certo, não reutilize às cegas. As ClusterRoles embutidas admin, edit e view são convenientes, mas edit e admin são mais amplas do que muitas equipes supõem — elas incluem acesso a Secrets no seu namespace. Leia o que você está vinculando antes de vincular.

Para o lado do menor privilégio voltado ao workload — descartar capabilities, rodar como non-root e impor Pod Security Standards — veja nosso guia complementar de segurança de pods no Kubernetes.

Higiene de ServiceAccount

Os ServiceAccounts são onde o RBAC encontra seus workloads em execução, e alguns padrões merecem atenção.

Não confie no ServiceAccount `default`. Todo namespace vem com um chamado default, e qualquer pod que não especifique um ServiceAccount roda como ele. Por ser compartilhado, qualquer permissão que você conceda ao default vaza para todo workload sem rótulo naquele namespace. Deixe-o sem bindings e dê a cada workload sua própria conta.

Dê a cada workload seu próprio ServiceAccount. Contas por workload permitem escopar permissões exatamente para o que aquele serviço precisa, e tornam as trilhas de auditoria significativas — você consegue dizer qual workload fez qual chamada de API.

apiVersion: v1

kind: ServiceAccount

metadata:

  name: reporting

  namespace: team-payments

automountServiceAccountToken: false

Desligue o automount de token onde ele não é necessário. Por padrão, o Kubernetes monta um token de ServiceAccount em todo pod, num caminho bem conhecido. Se o workload nunca conversa com o API server, esse token é pura superfície de ataque — quem comprometer o contêiner ganha de graça uma credencial válida do cluster. Defina automountServiceAccountToken: false no ServiceAccount ou no pod spec, a menos que o workload realmente precise de acesso à API. Gerenciar os tokens e outras credenciais de que esses workloads de fato precisam é um tema à parte — veja gerenciamento de secrets no Kubernetes.

Erros de configuração comuns e caminhos de escalonamento

Os atacantes não precisam de um cluster escancarado; precisam de um subject com permissões excessivas que consigam alcançar. Estes são os padrões que vale caçar.

Bindings ao `cluster-admin` ou a outras ClusterRoles amplas. Qualquer ClusterRoleBinding ao cluster-admin é um ponto único de comprometimento total. Enumere-os e justifique cada um.

Os verbs `escalate` e `bind`. Normalmente o Kubernetes impede você de criar uma role com mais permissões do que já detém — caso contrário o RBAC seria trivial de burlar. O verb escalate remove essa proteção para Roles/ClusterRoles, e bind a remove para bindings. Um subject que pode fazer bind e referenciar o cluster-admin pode se promover a admin, mesmo que tenha começado quase do nada. Trate qualquer concessão desses verbs como equivalente a conceder o que eles destravam.

O verb `impersonate`. Ele permite que um subject aja como outro usuário, grupo ou ServiceAccount. Um subject que pode personificar system:masters ou um cluster-admin é um cluster-admin. A personificação tem usos legítimos, mas deve ser rara e rigorosamente escopada.

Acesso amplo a Secrets. get, list ou watch em Secrets é acesso de leitura a credenciais, tokens e chaves TLS. Combinado com um token de ServiceAccount montado, costuma ser o pivô de um workload para muitos. Escope o acesso a Secrets para Secrets nomeados com resourceNames sempre que puder.

`create` em pods mais um ServiceAccount privilegiado. Se um subject pode criar pods em um namespace e definir o ServiceAccount do pod, ele pode lançar um pod que roda como uma conta mais privilegiada — transformando uma permissão modesta em todo o poder daquela conta.

Auditando e revisando o RBAC

O desvio (drift) do RBAC é inevitável: roles são adicionadas sob pressão de prazo e raramente são removidas. A revisão regular é o contrapeso.

Pergunte à API o que um subject pode fazer. O kubectl auth can-i responde perguntas de autorização diretamente, inclusive em nome de outra identidade:

kubectl auth can-i list secrets \

  --as=system:serviceaccount:team-payments:reporting \

  -n team-payments

Habilite e leia os audit logs. O audit log do API server registra quem fez o quê e é a verdade fundamental para detectar um ServiceAccount usando permissões que não deveria precisar — um forte sinal de que um binding é amplo demais (ou de que algo está errado).

Use ferramentas de análise de RBAC. Além do kubectl auth can-i e do kubectl describe, a comunidade tem ferramentas open source que achatam e visualizam as permissões efetivas, sinalizam verbs arriscados e comparam bindings ao longo do tempo. Como o modelo aditivo do RBAC torna as permissões efetivas difíceis de avaliar a olho, vale adotar ferramentas que calculem a união para você.

Revise com cadência e trate todo ClusterRoleBinding e todo uso de escalate, bind, impersonate ou curingas como um item de linha que precisa justificar seu lugar.

RBAC em CI/CD e infrastructure-as-code

Aqui está o ponto de alavancagem que a maioria das equipes deixa passar: sua configuração de RBAC é YAML, e YAML pode ser verificado antes de chegar ao cluster.

Em vez de descobrir um ClusterRoleBinding com permissões excessivas durante um incidente, você pode analisar os manifests no seu repositório Git como parte do code review e do CI — do mesmo jeito que faria lint em qualquer outra infrastructure-as-code. Uma verificação no pipeline pode reprovar um merge request que introduza um verb curinga, um binding ao cluster-admin ou uma Role que conceda escalate, dando aos revisores a chance de recuar enquanto a mudança ainda é barata de corrigir.

Essa abordagem shift-left combina naturalmente com GitOps: se o estado do RBAC do cluster é definido declarativamente no Git, então analisar o Git é analisar o estado pretendido do cluster. Pegar um binding perigoso na etapa de pull request é muito menos doloroso do que pegá-lo depois de estar em produção — e constrói uma cultura em que permissões amplas precisam ser justificadas na revisão.

Como a Rainforest ajuda

A plataforma de segurança de aplicações da Rainforest inclui análise de infrastructure-as-code que examina manifests do Kubernetes e definições de IaC antes de serem aplicados, expondo padrões arriscados de RBAC — permissões curinga, bindings a ClusterRoles amplas demais, verbs perigosos e tokens de ServiceAccount expostos — como parte do seu pipeline existente. Como ela roda onde seus desenvolvedores já trabalham, os achados chegam no code review com o contexto para corrigi-los, e não semanas depois em um relatório separado. É uma peça de uma abordagem mais ampla de teste de segurança de aplicações que abrange seu código, suas dependências e sua configuração.

Se você quiser ver como isso fica contra seus próprios manifests, agende uma demonstração e vamos percorrê-la com a sua configuração.