Skip to main content

Role Based Access | Kubernetes

  • Role Based Access | Kubernetes

Visão Geral No Kubernetes, o Role-Based Access Control (RBAC) é um mecanismo de controle de acesso baseado em papéis (roles). Ele permite especificar o que (quais recursos) um usuário ou um processo (como um service account) pode acessar ou modificar dentro do cluster. Dessa forma, você tem um controle mais granular sobre as permissões concedidas, evitando acessos desnecessários ou perigosos.

Conceitos Básicos​

1. Role e ClusterRole​

  • Role: Define um conjunto de permissões válidas apenas para um namespace específico. Por exemplo, você pode criar uma Role que permita apenas listar pods e criar configmaps dentro do namespace “dev”.
  • ClusterRole: Define um conjunto de permissões em nível de cluster (isto é, não está limitado a um único namespace). Por exemplo, pode-se criar uma ClusterRole que permita visualizar logs de todos os pods em todos os namespaces.

2. RoleBinding e ClusterRoleBinding​

  • RoleBinding: Associa (ou vincula) uma Role a um ou mais usuários, grupos ou contas de serviço (service accounts) dentro de um namespace. Se você quer conceder a alguém as permissões definidas por uma Role, você usa um RoleBinding.
  • ClusterRoleBinding: Associa uma ClusterRole (ou uma Role, em alguns casos) a um ou mais usuários, grupos ou contas de serviço em todo o cluster. Ou seja, as permissões concedidas valem para qualquer namespace.

3. Usuários, Grupos e ServiceAccounts​

  • Usuários: Representam identidades humanas ou externas ao cluster. O Kubernetes não gerencia usuários diretamente (como faria um sistema de autenticação de banco de dados, por exemplo). Normalmente, a autenticação de usuários é feita via certificados, tokens ou provedores externos (OIDC, etc.).
  • Grupos: Coleções de usuários. Permite centralizar o gerenciamento de permissões para vários usuários de uma só vez.
  • ServiceAccounts: São contas de acesso usadas por aplicações, pods ou processos dentro do cluster. Cada namespace já vem com a service account “default”, mas você pode criar outras para separar responsabilidades e permissões.

Como Funciona na Prática​

  1. Criar a Role ou ClusterRole
    Você primeiro define que operações quer permitir. Por exemplo, “pode listar e obter pods neste namespace”.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: pod-reader
      namespace: dev
    rules:
    - apiGroups: [""]                  # "" se refere ao core API group
      resources: ["pods"]
      verbs: ["get", "watch", "list"]  # Operações permitidas

  2. Vincular a Role ou ClusterRole
    Depois, você vincula essa Role (ou ClusterRole) a um usuário, grupo ou service account.

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: read-pods-binding
      namespace: dev
    subjects:
    - kind: User
      name: alice@example.com          # Nome do usuário no sistema de autenticação
    roleRef:
      kind: Role
      name: pod-reader                 # Refere-se à Role que definimos acima
      apiGroup: rbac.authorization.k8s.io

    Nesse exemplo, o usuário alice@example.com passa a ter permissão de listar pods somente no namespace dev.

  3. Validação
    Se RBAC estiver ativo no cluster, o Kubernetes vai validar toda solicitação de API (criação, listagem, exclusão etc.) contra as permissões atribuídas via Roles/ClusterRoles e Bindings. Se o usuário não tiver as permissões adequadas, a requisição será negada.

Boas Práticas​

  1. Princípio do Menor Privilégio
    Conceda somente as permissões mínimas necessárias para que determinado usuário ou serviço execute suas tarefas.

  2. Separe Permissões por Ambiente
    Use namespaces para separar ambientes (dev, staging, prod) e crie Roles distintas para cada um. Assim, evita-se que erros em um ambiente afetem o outro.

  3. Use Contas de Serviço (ServiceAccounts) para Aplicações
    Evite dar tokens de usuários humanos para pods ou processos. Em vez disso, crie service accounts com Roles/ClusterRoles apropriadas.

  4. Mantenha Políticas Documentadas
    É importante manter um registro ou documentação sobre quem tem acesso a quê, principalmente em ambientes corporativos sujeitos a auditorias.

Exemplo de ClusterRole e ClusterRoleBinding​

Suponha que você precise que um grupo de administradores consiga criar e deletar Deployments em qualquer namespace do cluster:

ClusterRole​

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-admin
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["create", "delete", "patch", "update"]

ClusterRoleBinding​

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: deployment-admin-binding
subjects:
- kind: Group
  name: ops-team                  # Nome do grupo no sistema de autenticação
roleRef:
  kind: ClusterRole
  name: deployment-admin
  apiGroup: rbac.authorization.k8s.io

Agora, todos os membros do grupo ops-team podem criar e deletar deployments em todos os namespaces do cluster.