Esta página fornece uma visão geral do sistema de controle de acesso baseado em função (RBAC) oferecido pelo Kubernetes e como você pode usar o Kubernetes RBAC no Google Kubernetes Engine.
Visão geral
O Kubernetes inclui um mecanismo integrado de controle de acesso baseado em função (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
Prepare-se para a tarefa tomando as seguintes medidas:
- 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 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
gcloudpara a versão mais recente:gcloud components update
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 funções (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, deverá
configurar o comando kubectl para autenticar no Google Cloud
antes de executar comandos que exijam 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 inicializar um usuário a permitir que eles
criem RBAC Roles e ClusterRoles, emita o seguinte comando, substituindo
kubectl create clusterrolebinding cluster-admin-binding \ --clusterrole cluster-admin \ --user[USER_ACCOUNT]
Grupos do Google para GKE
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 existentes, 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 fazer referência 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 deve ser nomeado exatamente comogke-security-groups. - Se ainda não houver, crie grupos que representem grupos de usuários ou que devem 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 ao grupo, o GKE verifica
se o usuário é membro de um grupo com acesso e se esse grupo é membro do grupo gke-security-groups do seu 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 seguinte opção, substituindo seu
nome de domínio: --security-group="gke-security-groups@[yourdomain.com]". Veja
a seguir um exemplo de comando de criação de cluster:
gcloud beta container clusters create my-cluster \
--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, 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. 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 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 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 papel pod-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 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.
Advertências
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 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 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 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 existente, 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]