RBAC multi-cluster no Rancher: evitando a bagunça

Se você administra mais de três ou quatro clusters Kubernetes pelo Rancher, provavelmente já viu este padrão: alguém recebe acesso "temporário" a um projeto, o acesso nunca é revogado, e seis meses depois ninguém sabe mais quem pode fazer o quê em qual cluster. RBAC multi-cluster não vira bagunça por falta de ferramenta — o Rancher tem os controles necessários. Vira bagunça por falta de critério na hora de atribuir papéis.

Este post trata do problema estrutural: por que permissões se acumulam, onde isso costuma quebrar, e que critérios usar para manter o modelo de acesso auditável conforme o número de clusters cresce.

Premissas e escopo deste artigo

Antes de entrar no conteúdo, duas transparências importantes:

• A busca de documentação que embasou este artigo retornou apenas um aviso de redirecionamento da documentação oficial do Rancher, sem conteúdo técnico extraído sobre roles, bindings ou comandos específicos. O destino do redirecionamento é a documentação oficial em ranchermanager.docs.rancher.com/v2.15/rancher-manager — recomendo fortemente consultar essa fonte para confirmar nomes exatos de recursos, telas de UI e comportamento na versão que você usa, já que o Rancher mudou nomenclatura de RBAC entre versões maiores.
• Os conceitos de modelo de permissão (global, cluster, projeto) descritos aqui refletem a arquitetura geral conhecida do Rancher, não um teste realizado neste ambiente. Nenhum comando ou manifesto deste post foi executado ou validado — trate os exemplos como ponto de partida para adaptação, não como script pronto para produção.

Dito isso, o problema de governança de RBAC multi-cluster é independente de versão específica: ele aparece em qualquer ambiente onde o número de clusters, projetos e usuários cresce mais rápido que o processo de revisão de acesso.

Os três níveis de permissão que você precisa gerenciar

O Rancher organiza RBAC em camadas hierárquicas, e a bagunça geralmente nasce de confundir essas camadas:

• Global: papéis que valem para todo o Rancher — administração da plataforma, criação de clusters, gestão de usuários. Poucas pessoas deveriam ter acesso global de admin.
• Cluster: papéis vinculados a um cluster específico — quem pode gerenciar nodes, políticas de rede, ou objetos cluster-wide dentro daquele cluster.
• Projeto (namespace agrupado): papéis escopados a um projeto dentro de um cluster — normalmente onde times de aplicação recebem acesso para deploy, leitura de logs, gestão de workloads.

O erro mais comum é dar permissão de cluster quando o time só precisa de acesso de projeto. Isso infla o "raio de explosão" de qualquer credencial comprometida ou qualquer erro de automação: um script com acesso de cluster pode afetar namespaces que não deveria nem ver.

Por que a bagunça acontece (sintomas, não causas)

Antes de corrigir, vale separar sintoma de causa raiz:

• Sintoma: usuários acumulam múltiplos papéis em múltiplos clusters ao longo do tempo. Causa provável: não existe processo de expiração ou revisão periódica de acesso — permissão concedida nunca é revisitada.
• Sintoma: times de plataforma concedem "cluster admin" como atalho para resolver pedidos de acesso. Causa provável: falta de papéis customizados intermediários entre "leitura" e "admin total", o que empurra todo pedido para o extremo mais permissivo.
• Sintoma: auditoria não consegue responder "quem pode deletar workloads de produção" sem abrir cluster por cluster. Causa provável: ausência de uma fonte única de verdade para bindings — permissões ficam espalhadas entre UI do Rancher, grupos de IdP externo e ajustes manuais.

Esses três sintomas têm a mesma raiz: RBAC tratado como configuração pontual, não como processo contínuo de governança.

Critérios práticos para organizar RBAC multi-cluster

Use estes critérios como checklist ao desenhar ou revisar o modelo:

1. Prefira grupos de identidade externa a usuários individuais. Se o Rancher estiver integrado a um provedor de autenticação (LDAP, SAML, OIDC), vincule papéis a grupos, não a contas isoladas. Isso reduz drasticamente o trabalho de revisão — você gerencia a entrada e saída de pessoas no grupo, não binding por binding no Rancher.

2. Separe papéis por função, não por projeto. Em vez de criar um papel "acesso-projeto-x", crie papéis reutilizáveis como "deploy-readonly", "deploy-write", "debug-logs" e aplique-os onde fizer sentido. Isso facilita auditoria: você sabe exatamente o que cada papel permite, independente de onde foi aplicado.

3. Escopo mínimo por padrão. Comece no nível de projeto. Só suba para cluster ou global quando houver justificativa documentada — e essa justificativa deveria estar registrada em algum lugar rastreável (ticket, PR de infraestrutura como código), não só na memória de quem aprovou.

4. Trate bindings como código, não como clique na UI. Se você já usa GitOps para workloads, aplique o mesmo princípio para objetos de RBAC. Um exemplo conceitual de binding de papel a um grupo em um cluster específico, no modelo de recursos customizados do Rancher (confirme o nome exato do CRD na versão que você usa):

apiVersion: management.cattle.io/v3
kind: ClusterRoleTemplateBinding
metadata:
  name: deploy-write-time-plataforma
  namespace: c-xxxxx
clusterName: c-xxxxx
groupPrincipalName: "openldap_group://cn=plataforma,ou=groups,dc=exemplo,dc=com"
roleTemplateName: cluster-member

Versionar esse tipo de manifesto em um repositório permite revisão por pull request antes de qualquer concessão de acesso em produção — o mesmo rigor que você já aplica a mudanças de infraestrutura.

5. Audite por amostragem periódica, não só por incidente. Defina uma cadência (mensal ou trimestral) para listar bindings ativos por cluster e perguntar: essa pessoa ainda precisa disso? Esperar um incidente de segurança para descobrir acesso órfão é tarde demais.

Quando vale a pena investir em automação de RBAC

Se você tem menos de cinco clusters e um time pequeno, um checklist manual de revisão trimestral já resolve boa parte do problema. A partir de dez ou mais clusters, ou quando múltiplos times de plataforma concedem acesso de forma independente, considere automatizar a geração de bindings via GitOps e validar drift de permissões com alguma rotina de auditoria programática — seja um script que compara bindings aplicados contra o repositório de origem, seja uma ferramenta de terceiros voltada a postura de segurança em Kubernetes.

A linha de corte não é um número mágico de clusters: é o momento em que revisar manualmente deixa de ser viável dentro do tempo que o time de plataforma tem disponível.

Próximo passo

Antes de redesenhar todo o modelo de RBAC, faça um inventário rápido: liste os papéis globais e de cluster atualmente concedidos e marque quantos têm justificativa documentada. Esse número isolado já indica se o problema é falta de processo ou falta de ferramenta — e qual dos dois resolver primeiro.