Como configurar o controle de acesso com base 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. Você também verá informações 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, 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, verifique se você realizou as tarefas a seguir:

Defina as configurações padrão da gcloud usando um dos métodos a seguir:

  • Use gcloud init se quiser orientações para definir os padrões.
  • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Se você receber o erro One of [--zone, --region] must be supplied: Please specify location, conclua esta seção.

  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 a usar sua 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.

Como usar o gcloud config

  • Defina o ID do projeto padrão:
    gcloud config set project project-id
  • Se você estiver trabalhando com clusters zonais, defina a zona do Compute padrão: 
    gcloud config set compute/zone compute-zone
  • Se você estiver trabalhando com clusters regionais, defina a região do Compute padrão: 
    gcloud config set compute/region compute-region
  • Atualize gcloud para a versão mais recente: 
    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.

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.

Embora o RBAC do Kubernetes possa ser usado em vez do IAM para quase todos os casos, os usuários do GKE precisam ter pelo menos a permissão container.clusters.get do IAM no projeto que contém o cluster. Essa permissão é incluída pelo papel container.clusterViewer e pelos outros papéis com mais privilégios. 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.

Pré-requisitos para usar o Kubernetes RBAC no Cluster do GKE v1.11.x e em versões mais antigas

Nos Clusters do GKE que usam o GKE v1.11.x e versões anteriores, há uma limitação que impede o IAM de conceder a capacidade de criar um Role ou ClusterRole do RBAC do Kubernetes. No entanto, o papel do IAM de administrador do Kubernetes Engine oferece aos usuários a capacidade de criar um RoleBinding ou ClusterRoleBinding do RBAC do Kubernetes para qualquer usuário, incluindo para eles mesmos. Dessa forma, é possível vincular usuários do Google Cloud a papéis predefinidos do RBAC (em inglês).

Mais especificamente, o papel predefinido cluster-admin do RBAC concede aos usuários permissões totais no cluster. Portanto, para inicializar um usuário a permitir que eles criem RBAC Roles e ClusterRoles, emita o seguinte comando, substituindo user-account pelo endereço de e-mail de login do Google Cloud do usuário de destino.

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin \
  --user user-account

Grupos do Google para GKE

Antes, apenas era possível atribuir papéis a contas de usuário do Google Cloud ou a contas de serviço do IAM. Os Grupos do Google para GKE (Beta) permitem que você conceda papéis a membros de um Grupo no Grupos do Google para empresas. Com esse mecanismo, os usuários e os próprios Grupos são mantidos pelos administradores do Google Workspace, completamente fora do Kubernetes ou do Console do Cloud. Portanto, os administradores do cluster não precisam de informações detalhadas sobre os usuários. Outro benefício é a integração com suas práticas atuais de gerenciamento de contas de usuário, como revogação do acesso quando alguém sai da organização.

Para usar esse recurso, conclua as seguintes tarefas:

Requisitos

O uso dos Grupos do Google para GKE tem os seguintes requisitos:

  • É necessário ter uma assinatura do Google Workspace ou do Cloud Identity.

Configurar os Grupos do Google para usar com o RBAC

A configuração do cluster para usar esse recurso e a sintaxe para referir-se a um Grupo do Google no Kubernetes RBAC são discutidas mais adiante neste tópico. Primeiro, configure os Grupos do Google seguindo as etapas abaixo:

  1. Crie um Grupo do Google no seu domínio, chamado gke-security-groups@yourdomain.com. O Grupo precisa ter o mesmo nome gke-security-groups. Verifique se o grupo gke-security-groups tem a permissão "Visualizar membros" para "Membros do grupo". Consulte este artigo para ver um exemplo de como configurar essa opção no Console do Administrador do Google Workspace.

    Também é possível consultar a Central de Ajuda dos Grupos para mais informações sobre como gerenciar Grupos no Google Workspace.

  2. Se ainda não houver, crie grupos que representem grupos de usuários ou que devem ter permissões diferentes nos seus clusters. Cada grupo precisa ter a permissão "Visualizar membros" para "Membros do grupo".

  3. Adicione esses grupos (não os usuários) à associação de gke-security-groups@yourdomain.com.

Para verificar se determinado usuário tem permissão para criar, modificar ou visualizar um recurso no cluster baseado na associação ao Grupo, o GKE verifica se o usuário é membro de um Grupo com acesso e se esse Grupo é membro direto do Grupo gke-security-groups do seu domínio.

As informações sobre a associação aos Grupos do Google são armazenadas em cache por um curto período. Pode levar alguns minutos para que as alterações nas associações ao Grupo sejam propagadas a todos os clusters. Além da latência de alterações de grupos, o armazenamento em cache (padrão) de credenciais de usuário no cluster leva cerca de uma hora.

Como configurar o cluster para usar os Grupos do Google para GKE

Depois que o administrador dos Grupos do Google configurar os Grupos, crie um novo cluster usando o comando gcloud e adicione a sinalização --security-group="gke-security-groups@yourdomain.com", substituindo o valor pelo nome do seu domínio.

Veja a seguir um exemplo do comando de criação de cluster:

gcloud beta container clusters create cluster-name \
  --security-group="gke-security-groups@yourdomain.com"

Agora você está pronto para criar Roles, ClusterRoles, RoleBindings e ClusterRoleBindings, que se referem aos Grupos do Google.

Como definir e atribuir permissões

Crie os seguintes tipos de objetos do Kubernetes para definir suas permissões de RBAC:

  • ClusterRole ou Role: define um conjunto de tipos de recursos e operações que podem ser atribuídos a um usuário ou grupo de usuários em um cluster (ClusterRole) ou um namespace (Role), mas não especifica o usuário ou grupo de usuários.
  • ClusterRoleBinding ou RoleBinding: atribui um ClusterRole ou Role a um usuário ou grupo de usuários. Um ClusterRoleBinding funciona com um ClusterRole, e um RoleBinding funciona com um ClusterRole ou um Role.

Os papéis do RBAC são puramente aditivos, não havendo regras de negação. Ao estruturar os papéis do RBAC, você deve pensar em termos de "conceder" aos usuários acesso aos recursos do cluster.

Como 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, onde você define o namespace relevante, o tipo de recurso e as operações permitidas para o Role. Por exemplo, o Role a seguir concede acesso de leitura (get, watch e list) a todos os pods no namespace accounting:

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

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.

Como atribuir funções 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 que é membro do Grupo do Google gke-security-groups@yourdomain.com

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-123456.google.com.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 GKE, google groups aparecerá na mensagem de registro.

Problemas de depuração com a integração dos Grupos do Google

As instruções a seguir permitem visualizar registros para validar se seus clusters foram configurados com êxito para usar os Grupos do Google em vinculações de papéis no RBAC.

Pré-requisitos

Antes de começar a examinar os registros, verifique se:

  • Você não interagiu com o cluster que quer testar (por exemplo, se executou algum comando kubectl) por pelo menos uma hora. A autenticação está armazenada em cache por uma hora. Você também precisa garantir que a solicitação esteja registrada quando isso acontecer.
  • Você é membro de pelo menos um dos grupos incluídos nos gke-security-groups. Isso garante que algumas informações dos Grupos do Google sejam preenchidas nos registros.

Como configurar registros

Para usar registros na depuração de Grupos do Google com o RBAC:

  1. Ative a geração de registros de acesso a dados para seu projeto do Google Cloud. Para ativar a geração de registros, siga estas instruções:

    1. No Console do Cloud, acesse a página Registros de auditoria no menu IAM.

      Acessar a página "Registros de auditoria"

    2. Na tabela, selecione API do Kubernetes Engine.

    3. No menu Tipo de registro, selecione:

      • Leitura de administradores
      • Leitura de dados
      • Gravação de dados

    4. Clique em Save.

    Para mais informações sobre como ativar a geração de registros de auditoria, consulte Como configurar registros de acesso a dados com o Console do Cloud na documentação das ferramentas de gerenciamento do Cloud.

  2. Execute um comando usando kubectl no cluster. Pode ser tão simples quanto kubectl create ns helloworld.

  3. Insira uma consulta personalizada na página Visualizador de registros. Para executar a consulta, faça o seguinte:

    1. No Console do Cloud, acesse a página Visualizador de registros no menu Registro.

      Ir para a página "Visualizador de registros"

    2. Clique na seta da caixa Visualização da consulta, na parte superior da página.

    3. Na caixa suspensa em exibição, copie e cole a seguinte consulta:

      resource.type="k8s_cluster"
resource.labels.location="cluster-region"
resource.labels.cluster_name="cluster-name"
protoPayload.resourceName="authorization.k8s.io/v1beta1/subjectaccessreviews"
protoPayload.response.spec.user="email-address"

      Em que:

      • cluster-region é a região ou zona do cluster;
      • cluster-name é o nome do cluster;
      • email-address é o endereço de e-mail registrado da sua Conta do Google.

    4. Selecione Executar consulta. Você deverá receber pelo menos um resultado. Caso contrário, tente aumentar o período.

    5. Selecione o cluster que você quer examinar.

    6. Clique em Expandir campos aninhados.

    7. O campo protoPayload.request.spec.group contém os grupos em que:

      • Os grupos são membros do gke-security-group.
      • Você é membro do grupo.

      Essa lista deve corresponder ao conjunto de grupos de que você é membro. Se nenhum grupo aparecer, talvez haja um problema com a configuração dos grupos.

  4. Restaure o registro de acesso a dados para as configurações anteriores, evitando cobranças adicionais (se desejar).

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. Antes da versão 1.14 do Kubernetes, tanto system:authenticated como system:unauthenticated concediam os ClusterRoles system:basic-user e system:discovery por padrão.

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.

No Kubernetes 1.14, os usuários anônimos (system:unauthenticated) receberão 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