Autorizar ações em clusters usando o controle de acesso baseado em papéis

Nesta página, mostramos como autorizar ações em recursos nos clusters do Google Kubernetes Engine (GKE) usando o mecanismo integrado de controle de acesso baseado em papéis (RBAC, na sigla em inglês) no Kubernetes.

O RBAC é um recurso de segurança principal do Kubernetes, que permite criar permissões refinadas para gerenciar quais ações os usuários e cargas de trabalho podem executar nos recursos dos clusters. Como administrador de plataforma, você cria papéis do RBAC e vincula esses papéis a assuntos, que são usuários autenticados, como contas de serviço ou grupos. O RBAC do Kubernetes está ativado por padrão.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a Google Cloud CLI para essa tarefa, instale e, em seguida, inicialize a CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão mais recente executando gcloud components update.

Interação com o gerenciamento de identidade e acesso

Use o gerenciamento de identidade e acesso (IAM) e o RBAC do Kubernetes para controlar o acesso ao seu Cluster do GKE:

  • O IAM não é específico do Kubernetes. Ele fornece gerenciamento de identidade para vários produtos do Google Cloud e opera principalmente no nível do projeto.

  • O RBAC do Kubernetes é um componente essencial do Kubernetes e permite que você crie e atribua papéis (conjuntos de permissões) para qualquer objeto ou tipo de objeto dentro do cluster.

  • Para autorizar uma ação, o GKE primeiro verifica se há uma política de RBAC. Se não houver uma política de RBAC, o GKE vai verificar as permissões do IAM.

No GKE, o IAM e o RBAC do Kubernetes estão integrados para autorizar os usuários a executar ações se eles tiverem permissões suficientes de acordo com qualquer uma das ferramentas. Essa é uma parte importante da inicialização de um cluster do GKE, já que os usuários do Google Cloud não têm nenhum Kubernetes RBAC RoleBindings.

Para autorizar usuários de contas do Google Cloud, o cliente precisa ser configurado corretamente para fazer a autenticação usando primeiro essas contas. Por exemplo, se você estiver usando kubectl, deverá configurar o comando kubectl para autenticar no Google Cloud antes de executar comandos que exijam autorização.

Em quase todos os casos, é possível usar o RBAC do Kubernetes em vez do IAM. Os usuários do GKE precisam pelo menos da permissão container.clusters.get do IAM no projeto que contém o cluster. Essa permissão está incluída no papel container.clusterViewer e em outros papéis altamente privilegiados. A permissão container.clusters.get é necessária para que os usuários se autentiquem nos clusters do projeto, mas ela não os autoriza a executar ações dentro dos clusters. Nesse caso, a autorização pode ser fornecida pelo IAM ou pelo RBAC do Kubernetes.

Definir e atribuir permissões

É possível definir regras de RBAC em objetos ClusterRole e Role e, em seguida, atribuir essas regras com objetos ClusterRoleBinding e RoleBinding da seguinte maneira:

  • ClusterRole: um agrupamento de recursos e operações permitidos no nível do cluster que pode ser atribuído a um usuário ou grupo usando RoleBinding ou ClusterRoleBinding.
  • Papel: um agrupamento com namespace de recursos e operações permitidas que você pode atribuir a um usuário ou a um grupo de usuários usando um RoleBinding.
  • ClusterRoleBinding: atribua um ClusterRole a um usuário ou a um grupo para todos os namespaces no cluster.
  • RoleBinding: atribua um Role ou ClusterRole a um usuário ou grupo em um namespace específico.

Quando você usa um RoleBinding para atribuir um ClusterRole a um usuário ou grupo, esses usuários e grupos só podem acessar recursos no namespace especificado no RoleBinding. Se você quiser que os usuários ou grupos acessem recursos em todos os namespaces, use um ClusterRoleBinding.

Definir permissões usando Roles ou ClusterRoles

Defina permissões em um objeto Role ou ClusterRole. Um Role define o acesso a recursos em um único namespace, enquanto um ClusterRole define o acesso a recursos em todo o cluster.

Os Roles e ClusterRoles têm a mesma sintaxe. Cada um tem uma seção rules, em que você define os recursos a que a regra se aplica e as operações permitidas para o papel. Por exemplo, o Role a seguir concede acesso de leitura (get, watch e list) a todos os pods no namespace accounting:

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

Consulte a documentação da API Role e ClusterRole para ver uma lista completa de campos permitidos.

Role vs. ClusterRole

Como as permissões concedidas por um ClusterRole se aplicam a todo o cluster, é possível usar os ClusterRoles para controlar o acesso a tipos de recursos diferentes dos que você controla com os Roles. Por exemplo:

  • recursos do escopo do cluster, por exemplo, nós;
  • endpoints REST sem recursos, como /healthz;
  • recursos com namespace em todos os namespaces, por exemplo, todos os pods do cluster inteiro, independentemente do namespace.

Atribuir papéis usando RoleBindings ou ClusterRoleBindings

Depois de criar um Role ou ClusterRole, crie um RoleBinding ou ClusterRoleBinding para atribuí-lo a um usuário ou grupo de usuários. Usuários e grupos são chamados de subjects e podem ser qualquer um dos seguintes:

Tipo de assunto Valor para kind Valor para name
Conta de usuário do Google Cloud User Endereço de e-mail registrado do Google Cloud
Conta de serviço do Kubernetes ServiceAccount O nome de um objeto ServiceAccount do Kubernetes no cluster
Conta de serviço do IAM User Endereço de e-mail da conta de serviço do IAM gerado automaticamente
Endereço do Grupo do Google (Beta) em um domínio verificado Group Endereço de e-mail de um grupo do Google Workspace que é membro do grupo gke-security-groups. Veja instruções sobre como configurar o Grupos do Google para RBAC em Configurar o Grupos do Google para RBAC.

O RoleBinding a seguir concede o papel pod-reader a um usuário, uma conta de serviço do Kubernetes e uma do IAM, além de um grupo do Google:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: pod-reader-binding
  namespace: accounting
subjects:
# Google Cloud user account
- kind: User
  name: janedoe@example.com
# Kubernetes service account
- kind: ServiceAccount
  name: johndoe
# IAM service account
- kind: User
  name: test-account@test-project.iam.gserviceaccount.com
# Google Group
- kind: Group
  name: accounting-group@example.com
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Verificar o acesso à API usando kubectl

kubectl fornece o subcomando auth can-i para consultar rapidamente a camada de autorização da API. Como administrador da plataforma, talvez você precise representar os usuários para determinar quais ações podem ser realizadas. É possível usar o auth can-i e transmitir uma flag --as adicional.

Quando você executa o comando kubectl auth can-i sem a flag --as, o Identity and Access Management (IAM) executa a autorização. Já quando você anexa a flag --as, o RBAC do Kubernetes executa a autorização. Portanto, você precisará criar os objetos Role e RoleBinding necessários para o RBAC.

Para mais informações, consulte Como verificar o acesso à API.

Uso e exemplos da API

Para informações completas sobre o uso da API do Kubernetes para criar os objetos Role, ClusterRole, RoleBinding e ClusterRoleBinding para RBAC, consulte Como usar a autorização de controle de acesso com base em papéis na documentação do Kubernetes.

Solução de problemas e depuração

Para depurar problemas com o RBAC, use o registro de auditoria de atividades do administrador, que é ativado em todos os clusters por padrão. Quando o acesso a um recurso ou operação é negado devido à falta de permissões suficientes, o servidor da API registra um erro RBAC DENY, além de outras informações, como a associação implícita e explícita do usuário ao grupo. Se você estiver usando o Grupos do Google para o RBAC, google groups aparecerá na mensagem de registro.

Limitações

As seções a seguir descrevem as interações que podem não parecer óbvias ao trabalhar com o RBAC e o IAM do Kubernetes.

Papéis de descoberta padrão

Os clusters são criados com um conjunto de ClusterRoles e ClusterRoleBindings padrão. As solicitações feitas com credenciais válidas são colocadas no grupo system:authenticated, ao passo que todas as outras solicitações se enquadram em system:unauthenticated.

O ClusterRole system:basic-user permite que os usuários criem SelfSubjectAccessReviews para testar suas permissões no cluster. O papel system:discovery permite que os usuários leiam APIs de descoberta, que podem revelar informações sobre CustomResourceDefinitions adicionadas ao cluster.

Usuários anônimos (system:unauthenticated) recebem o ClusterRole system:public-info-viewer, que concede acesso somente leitura às APIs /healthz e /version.

Para ver os endpoints da API permitidos pelo ClusterRole system:discovery, execute o seguinte comando:

kubectl get clusterroles system:discovery -o yaml

Erro proibido para contas de serviço em instâncias da VM do Google Cloud

O seguinte erro pode ocorrer quando a instância de VM não tem o escopo userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Por exemplo, suponha que a VM tenha o escopo cloud-platform, mas não o escopo userinfo-email. Quando a VM recebe um token de acesso, o Google Cloud associa esse token ao escopo cloud-platform. Quando o servidor da API do Kubernetes solicita ao Google Cloud a identidade associada ao token de acesso, ele recebe o código exclusivo da conta de serviço, não o e-mail dela.

Para autenticar com êxito, crie uma nova VM com o escopo userinfo-email ou uma nova vinculação de papel que use o código exclusivo.

Para criar uma nova instância de VM com o escopo userinfo-email, execute o seguinte comando:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Para criar uma nova vinculação de papel que use o código exclusivo da conta de serviço para uma VM existente, execute as seguintes etapas:

  1. Identifique o código exclusivo da conta de serviço:

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Por exemplo, a saída a seguir exibe o uniqueId da conta de serviço my-iam-account@somedomain.com:

    displayName: Some Domain IAM service account
email: my-iam-account@somedomain.com
etag: BwWWja0YfJA
name: projects/project-name/serviceAccounts/my-iam-account@somedomain.com
oauth2ClientId: '123456789012345678901'
projectId: project-name
uniqueId: '123456789012345678901'

  2. Crie uma vinculação de papel usando o uniqueId da conta de serviço:

    kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
    --clusterrole cluster-admin \
    --user UNIQUE_ID

Permissão para criar ou atualizar papéis e vinculações dos papéis

No Kubernetes, você só pode criar ou atualizar um papel ou uma vinculação do papel com permissões específicas se atender às seguintes condições:

  • Criar ou atualizar um papel: você precisa ter as mesmas permissões que quer conceder ao papel. Como alternativa, é necessário ter autorização para executar o verbo escalate no papel.
  • Criar ou atualizar uma vinculação do papel: você precisa ter as mesmas permissões que são concedidas ao papel que está sendo vinculado, com o mesmo escopo que a vinculação do papel. Como alternativa, é necessário ter autorização para executar o verbo bind no papel referenciado.

Se as permissões que você está concedendo ao papel forem originalmente concedidas a você usando uma política do IAM em vez de RBAC, é possível que sua solicitação de vinculação do papel ou o papel falhe. Por exemplo, considere a seguinte solicitação de criação de papel, de um usuário que recebeu as permissões do IAM container.pods.* e container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Se o usuário recebesse apenas as permissões usando o IAM, poderia ocorrer o seguinte erro:

Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}

Para atenuar essa limitação, conceda ao autor da chamada as permissões no papel usando o RBAC em vez do IAM.

Como alternativa, você pode usar o RBAC ou o IAM para conceder ao autor da chamada o verbo escalate, bind ou ambos. No entanto o GKE não recomenda essa abordagem, porque o autor da chamada pode conceder qualquer permissão a qualquer papel.

A seguir