Visão Geral do RBAC

No Kubernetes, o mecanismo de autorização oferece vários modos, incluindo ABAC (Controle de Acesso Baseado em Atributos), RBAC (Controle de Acesso Baseado em Funções), Webhook, Node, AlwaysDeny (sempre nega) e AlwaysAllow (sempre permite). A partir da versão 1.6, o RBAC tornou-se o padrão habilitado. Para ativar explicitamente o RBAC, utiliza-se o parâmetro de inicialização --authorization-mode=RBAC. O processo de autorização via API do RBAC envolve dois passos principais: primiero, definir funções que especificam permissões sobre recursos; segundo, vincular esses funções a sujeitos (como usuários ou contas de serviço).

Conceitos Fundamentais

Funções e Funções de Cluster

As funções no RBAC definem conjuntos de permissões, concedendo acesso sem possibilidade de negação explícita. Existem dois tipos:

• Função (Role): Definida dentro de um namespace, concede acesso apenas a recursos nesse namespace específico. Exemplo de uma função que permite visualizar pods:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-viewer
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

• Função de Cluster (ClusterRole): Aplicável em todo o cluster, pode ser usada para recursos não-namespaced (como Nodes), endpoints não-recursos (como "/healthz"), ou recursos em todos os namespaces. Exemplo para acesso de leitura a secrets:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: secrets-access
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

Vinculação de Funções

A vinculação associa funções a sujeitos (usuários, grupos ou contas de serviço), implementando a autorização.

• Vinculação de Função (RoleBinding): Vincula uma função a sujeitos dentro do mesmo namespace. Pode referenciar tanto Roles quanto ClusterRoles, mas o acesso fica restrito ao namespace da vinculação. Exemplo vinculando o usuário "maria" à função "pod-viewer" no namespace default:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bind-pod-viewer
  namespace: default
subjects:
- kind: User
  name: maria
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-viewer
  apiGroup: rbac.authorization.k8s.io

Outro exemplo usando um ClusterRole em um RoleBinding para conceder acesso a secrets apenas no namespace "production":

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bind-secrets-production
  namespace: production
subjects:
- kind: User
  name: maria
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secrets-access
  apiGroup: rbac.authorization.k8s.io

• Vinculação de Função de Cluster (ClusterRoleBinding): Concede acesso em todo o cluster ou em todos os namespaces. Exemplo permitindo que o grupo "dev-team" acesse secrets em todos os namespaces:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: bind-secrets-global
subjects:
- kind: Group
  name: dev-team
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secrets-access
  apiGroup: rbac.authorization.k8s.io

Recursos e Sub-recursos

Recursos no Kubernetes incluem Pods, Services, Deployments, Secrets, entre outros. Alguns recrusos possuem sub-recursos, como os logs de um Pod. Exemplo de uma função para acesso a pods e seus logs:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-log-viewer
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

Para restringir o acesso a instâncias específicas, utiliza-se o campo resourceNames. Exemplo para atualizar apenas um ConfigMap nomeado "app-config":

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["app-config"]
  verbs: ["update", "get"]

Sujeitos

Os sujeitos em vinculações RBAC podem ser usuários, grupos ou contas de serviço. Usuários são identificados por strings, enquanto grupos seguem formatos definidos pelos módulos de autenticação. Exemplos de configuração em subjects:

• Usuário "carlos": - kind: User\n name: "carlos"\n apiGroup: rbac.authorization.k8s.io
• Grupo "developers": - kind: Group\n name: "developers"\n apiGroup: rbac.authorization.k8s.io
• Conta de serviço "backend-sa" no namespace "app": - kind: ServiceAccount\n name: backend-sa\n namespace: app
• Todas as contas de serviço no namespace "monitoring": - kind: Group\n name: system:serviceaccounts:monitoring\n apiGroup: rbac.authorization.k8s.io
• Todos os usuários autenticados: - kind: Group\n name: system:authenticated\n apiGroup: rbac.authorization.k8s.io