Quando falamos de segurança em Kubernetes, um dos recursos mais importantes é o RBAC.

RBAC significa Role-Based Access Control, ou seja, controle de acesso baseado em papéis.

Na prática, ele responde uma pergunta muito simples:

Quem pode fazer o quê dentro do cluster?

E isso é essencial para evitar que qualquer usuário, aplicação ou automação tenha acesso maior do que deveria.

O que o RBAC controla? 🤔

Com RBAC, conseguimos definir limites de acesso para recursos do Kubernetes, como:

✅ Pods
✅ Deployments
✅ Services
✅ ConfigMaps
✅ Secrets
✅ Namespaces
✅ Nodes
✅ Jobs
✅ Ingress
✅ Recursos customizados

Essas permissões podem ser aplicadas para:

👤 Users
👥 Groups
🤖 ServiceAccounts

Ou seja, podemos controlar tanto acessos humanos quanto acessos de aplicações que rodam dentro do cluster.

Os principais recursos do RBAC 🧩

No Kubernetes, trabalhamos principalmente com quatro recursos:

✅ Role
✅ ClusterRole
✅ RoleBinding
✅ ClusterRoleBinding

Cada um tem uma função bem específica.

Role: permissões dentro de um namespace 📦

A Role é usada para criar regras de acesso dentro de um namespace específico.

Ou seja, ela não vale para o cluster inteiro.

Exemplo de uma Role permitindo listar, visualizar, alterar e deletar Pods e Deployments dentro do namespace dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: workload-manager
namespace: dev
rules:

• apiGroups: [""]
  resources:

  • pods verbs:
  • get
  • list
  • watch
  • update
  • patch
  • delete

• apiGroups: ["apps"]
  resources:

  • deployments verbs:
  • get
  • list
  • watch
  • update
  • patch
  • delete

Nesse exemplo, estamos dizendo:

👉 Dentro do namespace dev, quem receber essa Role poderá consultar, listar, acompanhar, alterar e deletar Pods e Deployments.

ClusterRole: permissões em nível de cluster 🌎

A ClusterRole é parecida com a Role, mas ela não fica presa a um namespace.

Ela pode ser usada para permissões em nível de cluster ou para criar uma regra reutilizável em vários namespaces.

Exemplo de ClusterRole com a mesma ideia:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: workload-manager-cluster
rules:

• apiGroups: [""]
  resources:

  • pods verbs:
  • get
  • list
  • watch
  • update
  • patch
  • delete

• apiGroups: ["apps"]
  resources:

  • deployments verbs:
  • get
  • list
  • watch
  • update
  • patch
  • delete

Aqui criamos uma regra em contexto de cluster.

Mas atenção: criar uma ClusterRole não significa que alguém já tem esse acesso.

A regra fica criada, mas ainda precisa ser vinculada a alguém.

Binding: ligando a regra a alguém 🔗

Role e ClusterRole definem o que pode ser feito.

RoleBinding e ClusterRoleBinding definem quem pode fazer.

Essa é uma das partes mais importantes do RBAC.

RoleBinding: acesso limitado a um namespace 📦

Agora vamos ligar a Role workload-manager a um usuário chamado john.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: john-workload-manager
namespace: dev
subjects:

• kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: workload-manager apiGroup: rbac.authorization.k8s.io

Nesse caso, o usuário john recebe as permissões da Role workload-manager, mas somente dentro do namespace dev.

Ou seja:

✅ pode atuar no namespace dev
❌ não recebe acesso automático aos outros namespaces

Usando ClusterRole com RoleBinding 🎯

Um ponto muito interessante do RBAC é que podemos usar uma ClusterRole com um RoleBinding.

Isso permite reaproveitar uma regra criada em nível de cluster, mas limitar o acesso a um namespace específico.

Exemplo:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: john-clusterrole-limited-to-dev
namespace: dev
subjects:

• kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Aqui estamos dizendo:

👉 Use a ClusterRole workload-manager-cluster, mas aplique esse acesso somente dentro do namespace dev.

Esse modelo é muito útil quando queremos criar permissões padronizadas e reutilizar em vários namespaces.

Por exemplo:

📌 mesma permissão para times diferentes
📌 mesma regra para ambientes dev, stage e prod
📌 mesmo padrão de acesso para vários namespaces
📌 menos repetição de YAML
📌 mais controle e organização

ClusterRoleBinding: acesso em todo o cluster 🌎

Agora, se quisermos dar acesso em nível de cluster, usamos um ClusterRoleBinding.

Exemplo vinculando a ClusterRole ao usuário john:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: john-workload-manager-cluster
subjects:

• kind: User name: john apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Nesse caso, o usuário john recebe as permissões da ClusterRole em todo o cluster.

Ou seja, ele poderá atuar em todos os namespaces onde aqueles recursos existirem.

Aqui o cuidado precisa ser maior.

ClusterRoleBinding pode abrir muito acesso se for usado sem critério.

Importante ⚠️

Podemos fazer isso:

✅ Role + RoleBinding
✅ ClusterRole + RoleBinding
✅ ClusterRole + ClusterRoleBinding

Mas não usamos uma Role comum com ClusterRoleBinding.

Isso não faz sentido porque uma Role é um recurso limitado a namespace, enquanto um ClusterRoleBinding aplica acesso em nível de cluster.

Se a ideia é conceder acesso global, a regra precisa estar em uma ClusterRole.

RBAC com ServiceAccount 🤖

Até agora vimos exemplos com usuário, mas RBAC também é muito usado com ServiceAccount.

ServiceAccount é muito comum quando uma aplicação, controller, pipeline, job ou automação precisa acessar a API do Kubernetes.

Por exemplo:

📌 um controller que lista Pods
📌 um Job que precisa consultar ConfigMaps
📌 uma aplicação que precisa ler Secrets
📌 um operador que gerencia recursos customizados
📌 uma automação de deploy dentro do cluster

Criando uma ServiceAccount 👇
apiVersion: v1
kind: ServiceAccount
metadata:
name: app-manager
namespace: dev

Agora podemos vincular essa ServiceAccount a uma Role ou ClusterRole.

ServiceAccount com RoleBinding 📦

Exemplo usando a Role workload-manager no namespace dev:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-manager-rolebinding
namespace: dev
subjects:

• kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: Role name: workload-manager apiGroup: rbac.authorization.k8s.io

Nesse caso, a ServiceAccount app-manager terá acesso somente dentro do namespace dev.

Esse é um padrão bem comum quando queremos limitar uma aplicação ao próprio namespace.

ServiceAccount usando ClusterRole com RoleBinding 🎯

Também podemos usar uma ClusterRole com RoleBinding para limitar o acesso da ServiceAccount a um namespace específico.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: app-manager-clusterrole-limited-to-dev
namespace: dev
subjects:

• kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Aqui a regra vem de uma ClusterRole, mas o acesso fica limitado ao namespace dev.

Esse modelo é excelente para padronizar permissões sem liberar acesso ao cluster inteiro.

ServiceAccount com ClusterRoleBinding 🌎

Agora, se essa ServiceAccount realmente precisar atuar em todo o cluster, usamos ClusterRoleBinding.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: app-manager-clusterrolebinding
subjects:

• kind: ServiceAccount name: app-manager namespace: dev roleRef: kind: ClusterRole name: workload-manager-cluster apiGroup: rbac.authorization.k8s.io

Nesse caso, a ServiceAccount app-manager, mesmo estando no namespace dev, recebe permissão em nível de cluster.

Esse tipo de permissão deve ser usado com muito cuidado.

Verbs mais usados no RBAC 🛠️

Os verbs representam as ações que podem ser executadas nos recursos.

Alguns dos mais comuns são:

✅ get
Permite visualizar um recurso específico.

✅ list
Permite listar vários recursos.

✅ watch
Permite acompanhar mudanças nos recursos em tempo real.

✅ create
Permite criar novos recursos.

✅ update
Permite atualizar um recurso existente.

✅ patch
Permite aplicar alterações parciais em um recurso.

✅ delete
Permite deletar recursos.

✅ deletecollection
Permite deletar múltiplos recursos de uma vez.

✅ impersonate
Permite agir como outro usuário, grupo ou ServiceAccount.

✅ bind
Permite vincular roles a usuários ou ServiceAccounts.

✅ escalate
Permite criar ou modificar roles com permissões maiores.

Os verbs bind, escalate e impersonate merecem atenção especial, porque podem abrir caminho para elevação de privilégio.

Resources mais usados 📦

Os resources são os objetos do Kubernetes que queremos controlar.

Alguns exemplos comuns:

resources:

• pods
• deployments
• services
• configmaps
• secrets
• namespaces
• nodes
• jobs
• cronjobs
• ingresses
• serviceaccounts
• roles
• rolebindings
• clusterroles
• clusterrolebindings

Exemplo:

rules:

• apiGroups: [""] resources:
  • pods
  • services
  • configmaps verbs:
  • get
  • list
  • watch API Groups mais usados 🧱

No Kubernetes, os recursos são organizados por apiGroups.

Alguns exemplos:

apiGroups: [""]

Usado para recursos core, como:

pods
services
configmaps
secrets
namespaces

Exemplo:

apiGroups: [""]
resources:

• pods
• services apiGroups: ["apps"]

Usado para recursos como:

deployments
replicasets
statefulsets
daemonsets

Exemplo:

apiGroups: ["apps"]
resources:

• deployments
• statefulsets apiGroups: ["batch"]

Usado para:

jobs
cronjobs
apiGroups: ["networking.k8s.io"]

Usado para:

ingresses
networkpolicies
apiGroups: ["rbac.authorization.k8s.io"]

Usado para recursos do próprio RBAC:

roles
rolebindings
clusterroles
clusterrolebindings
Como testar permissões com kubectl 🧪

Uma forma muito útil de validar RBAC é usando:

kubectl auth can-i

Exemplo testando se o usuário john pode listar Pods no namespace dev:

kubectl auth can-i list pods -n dev --as=john

Testando se ele pode deletar Deployments no namespace dev:

kubectl auth can-i delete deployments -n dev --as=john

Testando se ele pode listar Pods em outro namespace:

kubectl auth can-i list pods -n prod --as=john

Se o acesso estiver limitado ao namespace dev, esse comando deve retornar:

no
Testando ServiceAccount 🤖

Para testar permissões de uma ServiceAccount, usamos o formato:

system:serviceaccount:namespace:nome-da-serviceaccount

Exemplo:

kubectl auth can-i list pods -n dev --as=system:serviceaccount:dev:app-manager

Testando delete em Deployments:

kubectl auth can-i delete deployments -n dev --as=system:serviceaccount:dev:app-manager

Testando acesso fora do namespace:

kubectl auth can-i list pods -n prod --as=system:serviceaccount:dev:app-manager

Esse tipo de teste ajuda muito a validar se a permissão está realmente funcionando como esperado.

Por que usar RBAC? 🚀

RBAC é essencial para segurança e organização dentro de um cluster Kubernetes.

Com ele, conseguimos aplicar o princípio do menor privilégio.

Ou seja:

cada usuário, aplicação ou automação recebe somente as permissões que realmente precisa.

Isso reduz bastante o risco de problemas.

RBAC ajuda em cenários como:

✅ separar permissões por time
✅ limitar acesso por namespace
✅ proteger recursos sensíveis como Secrets
✅ evitar alterações acidentais em produção
✅ impedir que aplicações tenham acesso excessivo
✅ controlar permissões de pipelines e automações
✅ reduzir impacto em caso de credencial comprometida
✅ melhorar governança e auditoria dentro do cluster

Conclusão 🔐☸️

RBAC é uma das bases de segurança no Kubernetes.

Ele permite controlar de forma clara:

👤 quem acessa
🛠️ o que pode fazer
📦 em qual recurso
🌎 em qual escopo

A ideia principal é simples:

Role e ClusterRole criam as regras.
RoleBinding e ClusterRoleBinding entregam essas regras para alguém.

Quando usamos RBAC bem configurado, o cluster fica mais seguro, organizado e previsível.

No fim, não é só sobre bloquear acesso.

É sobre garantir que cada pessoa, aplicação ou automação tenha exatamente o acesso necessário.

Nem mais.
Nem menos. 🔐