Controle de acesso baseado em papéis

Nesta página, fornecemos uma visão geral do sistema de controle de acesso baseado em papéis (RBAC, na sigla em inglês) oferecido pelo Kubernetes e de como o Kubernetes RBAC pode ser usado no Google Kubernetes Engine.

Visão geral

O Kubernetes inclui um mecanismo integrado de controle de acesso baseado em papéis (RBAC) que permite definir conjuntos específicos e detalhados de permissões que definem como determinado usuário ou grupo de usuários do Google Cloud pode interagir com qualquer objeto do Kubernetes no cluster ou em um namespace específico do cluster.

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

Antes de começar

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

Verifique se você ativou a API Google Kubernetes Engine.

Ativar a API do Google Kubernetes Engine

Verifique se o SDK do Cloud está instalado.

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

Use gcloud init se você quer receber orientações sobre a definição de padrões.
Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

Como usar o gcloud init

Execute gcloud init e siga as instruções:
```
gcloud init
```
Se você estiver usando SSH em um servidor remoto, use a sinalização --console-only para impedir que o comando inicie um navegador:
```
gcloud init --console-only
```
Siga as instruções para autorizar gcloud a usar sua conta do Google Cloud.
Crie uma nova configuração ou selecione uma atual.
Escolha um projeto do Google Cloud.
Escolha uma zona padrão do Compute Engine.

Observação: é possível substituir essas configurações padrão nos comandos gcloud usando as sinalizações , --project, --zone e --region.

Como usar a configuração da gcloud

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
```

Observação: é possível substituir essas configurações padrão nos comandos gcloud usando as sinalizações --project, --zone e --region.

Interação com o gerenciamento de identidade e acesso

É possível usar tanto o Cloud Identity and Access Management como o Kubernetes RBAC para controlar o acesso ao seu cluster do GKE:

O Cloud 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 do Google Cloud.
O Kubernetes RBAC é um componente principal do Kubernetes e permite que você crie e conceda papéis (conjuntos de permissões) para qualquer objeto ou tipo de objeto dentro do cluster.

No GKE, o Cloud IAM e o Kubernetes RBAC são integrados para autorizar os usuários a executar ações se eles tiverem permissões suficientes de acordo com qualquer ferramenta. 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 os usuários a usar contas do Google Cloud, primeiro é necessário configurar o cliente para autenticar usando essas contas. Por exemplo, se você estiver usando kubectl, será preciso configurar o comando kubectl para autenticar no Google Cloud antes de executar comandos que exigem autorização.

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 em que o Cloud IAM não pode conceder a capacidade de criar um Kubernetes RBAC Role ou ClusterRole. No entanto, o papel Cloud IAM do administrador do Kubernetes Engine oferece aos usuários a capacidade de criar um Kubernetes RBAC RoleBinding ou ClusterRoleBinding para qualquer usuário, incluindo eles mesmos. Isso pode ser usado para vincular os usuários do Google Cloud a papéis RBAC predefinidos.

Mais especificamente, o papel RBAC predefinido cluster-admin concede aos usuários permissões totais no cluster. Portanto, para iniciar um usuário para permitir a criação de papéis RBAC e ClusterRoles, emita o seguinte comando, substituindo user-account pelo endereço de e-mail de login do Google Cloud.

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

Grupos do Google para GKE

beta

Anteriormente, só era possível atribuir papéis a contas de usuário do Google Cloud ou a contas de serviço do Cloud IAM. Os Grupos do Google para GKE (Beta) permitem que você conceda papéis a membros de um Grupo do Google do G Suite. Com esse mecanismo, os usuários e os próprios grupos são mantidos pelos administradores do G Suite, 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 de gerenciamento de contas de usuário atuais, como a revogação do acesso quando alguém sai da organização.

Para usar esse recurso, configure seus Grupos do Google do G Suite , crie um cluster com o recurso ativado e associe esses Grupos do Google a conjuntos de permissões de cluster.

Configurar os Grupos do Google para usar com o RBAC

A configuração do cluster para usar esse recurso, bem como a sintaxe para se referir a um Grupo do Google do G Suite no Kubernetes RBAC são discutidas posteriormente neste tópico. Primeiro, configure seus Grupos do Google seguindo as etapas abaixo:

Crie um Grupo do Google do G Suite no seu domínio, chamado gke-security-groups@yourdomain.com. O grupo precisa ser nomeado exatamente como gke-security-groups. Verifique se o grupo gke-security-groups tem a permissão "Visualizar membros" para "Membros do grupo". Veja este artigo (em inglês) para ver um exemplo de como configurar isso no Console do Administrador do G Suite.

Também é possível consultar a Central de Ajuda do Grupos do Google para mais informações sobre como gerenciar os Grupos do G Suite.
Se ainda não houver, crie grupos que representem grupos de usuários ou que precisem ter permissões diferentes nos seus clusters.
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 com base em associação a grupo, o GKE verifica se o usuário é membro de um grupo com acesso e se esse grupo é membro direto do gke-security-groups grupo do domínio.

As informações sobre a associação ao Grupo do Google do G Suite são armazenadas em cache por um curto período. Pode levar alguns minutos para que as alterações nas associações do grupo sejam propagadas para todos os clusters.

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

Depois que o administrador dos Grupos do Google do G Suite configurar seus 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 seu próprio nome de 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 fazem referência aos Grupos do Google do G Suite.

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 há regras de negação. Ao estruturar os papéis do RBAC, pense em "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, em que 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. São elas:

Recursos do escopo do cluster, por exemplo, nodes
Endpoints sem recursos, como /healthz
Recursos com namespace, em todos os namespaces, por exemplo, todos os pods do cluster inteiro, independentemente do namespace

Como atribuir Roles 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 Kubernetes ServiceAccount no cluster
Conta de serviço do Cloud IAM	`User`	Endereço de e-mail da conta de serviço do Cloud IAM gerado automaticamente
Endereço do Grupo do Google do G Suite (Beta) em um domínio verificado	`Group`	Endereço de e-mail de um Grupo do Google que seja membro do gke-security-groups@`[yourdomain.com]`.

O RoleBinding a seguir concede o Rolepod-reader a um usuário, uma conta de serviço do Kubernetes, uma conta de serviço do Cloud IAM e 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
    # Cloud IAM service account
    - kind: User
      name: test-account@test-project-123456.google.com.iam.gserviceaccount.com
    # G Suite 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 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.

Advertências

Nas seções a seguir, descrevemos 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 (em inglês). 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 as permissões no cluster. O papel system:discovery permite que os usuários leiam as 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:basic-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

Esse erro pode ocorrer quando a instância da VM não tem o escopo userinfo-email. Por exemplo, suponha que a VM tenha o escopo cloud-platform, mas não tenha 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 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 crie uma nova vinculação de papel que use o código exclusivo.

Para criar uma nova 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 atual, execute as seguintes etapas:

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

    gcloud iam service-accounts describe service-account-email

Use o código exclusivo para criar uma vinculação de papel:

    kubectl create clusterrolebinding clusterrolebinding-name \
      --clusterrole cluster-admin \
      --user unique-id

A seguir

Saiba como criar políticas do Cloud Identity and Access Management.

Controle de acesso baseado em papéis

Visão geral

Antes de começar

Como usar o gcloud init

Como usar a configuração da gcloud

Interação com o gerenciamento de identidade e acesso

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

Grupos do Google para GKE

Configurar os Grupos do Google para usar com o RBAC

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

Como definir e atribuir permissões

Como definir permissões usando Roles ou ClusterRoles

Role vs. ClusterRole

Como atribuir Roles usando RoleBindings ou ClusterRoleBindings

Uso e exemplos da API

Advertências

Papéis de descoberta padrão

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

A seguir

`Role` vs. `ClusterRole`