Configurar o controle de acesso baseado em papéis

Nesta página, você encontra uma visão geral do sistema de controle de acesso baseado em papéis (RBAC, na sigla em inglês) fornecido pelo Kubernetes e sobre como usá-lo no Google Kubernetes Engine (GKE).

Visão geral

O Kubernetes inclui um mecanismo integrado de controle de acesso baseado em papéis (RBAC, na sigla em inglês), permitindo configurar conjuntos de permissões específicos e detalhados que definem como um determinado usuário ou grupo de usuários do Google Cloud pode interagir com qualquer objeto do Kubernetes no seu cluster ou em um namespace em particular.

O RBAC do Kubernetes está ativado por padrão.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

  • Veja se você ativou a API do Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Confirme se você instalou a Google Cloud CLI.
  • Defina as configurações padrão da Google Cloud CLI para o projeto usando um dos seguintes métodos:
    • Use gcloud init se quiser orientações para definir os padrões do projeto.
    • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

    gcloud init

    1. Execute gcloud init e siga as instruções:

      gcloud init

      Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

      gcloud init --console-only
    2. Siga as instruções para autorizar a gcloud CLI a usar a conta do Google Cloud.
    3. Crie uma nova configuração ou selecione uma atual.
    4. Escolha um projeto do Google Cloud.
    5. Escolha uma zona padrão do Compute Engine.
    6. Escolha uma região padrão do Compute Engine.
    .

    gcloud config

    1. Defina o ID do projeto padrão: 
      gcloud config set project PROJECT_ID
    2. Defina a região padrão do Compute Engine (por exemplo, us-central1): 
      gcloud config set compute/region COMPUTE_REGION
    3. Defina a zona padrão do Compute Engine (por exemplo, us-central1-c): 
      gcloud config set compute/zone COMPUTE_ZONE
    4. Atualize gcloud para a versão mais recente: 
      gcloud components update
    .

    Ao definir locais padrão, é possível evitar erros na gcloud CLI, como: One of [--zone, --region] must be supplied: Please specify location.

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.

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. Esses recursos incluem:

  • 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

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 Kubernetes RBAC.

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

A seguir