Autorização RBAC

Introdução

No Kubernetes, a autorização geralmente é gerenciada pelo RBAC (Role-Based Access Control, ou Controle de Acesso Baseado em Funções).

Usuário: um funcionário, como "Jane".
Role: um cartão de acesso com permissões específicas, por exemplo, "Pode entrar na sala dos servidores" ou "Pode ler documentos".
RoleBinding: o ato de entregar o cartão de acesso ao funcionário.

O RBAC é importante porque o acesso ao cluster não se resume à autenticação. Depois que a identidade é conhecida, o sistema ainda precisa decidir quais ações essa identidade pode executar.

Neste laboratório, você atuará como responsável pela segurança:

Crie um "crachá de visitante" (Role) que permita consultar os recursos, mas não alterá-los.
Atribua esse crachá a um usuário chamado jane.
Verifique se Jane consegue consultar os recursos, mas recebe uma rejeição ao tentar fazer alterações.

Definir a Role

Primeiro, você precisa criar o conjunto de permissões. Queremos uma Role de "somente leitura". Ela permitirá que alguém use list e get para ler Pods, mas não permitirá create nem delete.

O RBAC trata da autorização no Kubernetes, não da autenticação. A autenticação responde à pergunta "Quem é você?". A autorização responde à pergunta "O que você pode fazer?". Neste laboratório, o foco está na segunda pergunta: você definirá ações permitidas explicitamente, chamadas de verbs, para tipos específicos de recursos.

Crie um arquivo chamado role.yaml:

nano role.yaml

Cole o YAML a seguir. Essa definição cria uma Role autorizada a executar as ações "get", "watch" e "list" em "pods".

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
  - apiGroups: [""] ## "" indicates the core API group
    resources: ["pods"]
    verbs: ["get", "watch", "list"]

Salve e saia (Ctrl+X, Y, Enter).

Agora, aplique esse cartão ao cluster:

kubectl apply -f role.yaml

Verifique se ele existe:

kubectl get roles

Você deverá ver pod-reader.

Vincular a Role

Agora você tem o cartão (pod-reader) e o funcionário (jane). Mas Jane ainda não recebeu o cartão. Você precisa de um RoleBinding para conectar os dois.

Uma Role não concede nenhuma permissão por si só até ser referenciada por um binding. Essa separação é intencional. Ela permite que os administradores definam conjuntos reutilizáveis de permissões uma única vez e depois os associem a diferentes usuários, grupos ou contas de serviço conforme necessário.

Crie um arquivo chamado rolebinding.yaml:

nano rolebinding.yaml

Cole o conteúdo a seguir. Ele significa: "Vincular a Rolepod-readerao usuáriojane".

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
  - kind: User
    name: jane ## The employee
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader ## The key card
  apiGroup: rbac.authorization.k8s.io

Salve e saia (Ctrl+X, Y, Enter).

Aplique o binding:

kubectl apply -f rolebinding.yaml

Agora você concedeu oficialmente a Jane acesso somente leitura ao namespace default.

Verificar o acesso

Como testar isso? Você não precisa sair e entrar novamente como Jane. O Kubernetes permite personificar um usuário para testar permissões usando a opção --as.

Essa é uma técnica prática de administração. As verificações de permissão são muito mais seguras quando você pode simular uma identidade antes de conceder acesso a um usuário real ou a uma conta de automação. Assim, você verifica se a configuração corresponde ao objetivo sem criar efeitos colaterais desnecessários no cluster.

Verifique se Jane pode listar Pods:

kubectl auth can-i list pods --as jane

A saída deverá ser yes.

Você também pode verificar se ela consegue obter os detalhes de um Pod específico:

kubectl auth can-i get pods --as jane

A saída também deverá ser yes.

Isso confirma que o RoleBinding está funcionando. O cartão de acesso funciona nos leitores das portas!

Verificar as restrições

A segurança também envolve aquilo que você não pode fazer. Como Jane tem apenas a Role pod-reader, ela deve ser estritamente impedida de fazer alterações.

Esse é o princípio do menor privilégio em ação. Em vez de conceder amplo acesso e esperar que as pessoas ajam com cuidado, você começa com as permissões mínimas necessárias para a tarefa e só as amplia quando houver uma necessidade operacional real.

Verifique se Jane pode criar um Pod:

kubectl auth can-i create pods --as jane

A saída deverá ser no.

Verifique se Jane pode excluir um Pod:

kubectl auth can-i delete pods --as jane

A saída deverá ser no.

Se Jane tentar executar esses comandos de verdade, o servidor da API rejeitará a solicitação dela com um erro "Forbidden". Isso confirma que o cluster está protegido e segue o princípio do menor privilégio.

Resumo

Neste laboratório, você protegeu o cluster usando RBAC.

Você conseguiu:

Criar uma Role (um "cartão de acesso") com permissões limitadas e somente leitura.
Criar um RoleBinding para entregar esse cartão ao usuário jane.
Verificar que jane pode consultar os recursos, mas não pode alterá-los.

Essa é a base da segurança para vários usuários no Kubernetes. Nunca conceda acesso total de administrador a todas as pessoas!