Kubernetes RBAC: controlando quem pode fazer o quê dentro do cluster 🔐☸️

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. 🔐