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:
- Verifique se você ativou a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Verifique se o SDK do Cloud está instalado.
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.
-
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
-
Siga as instruções para autorizar a
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.
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:
- Cumpra os requisitos.
- Configure seus Grupos do Google.
- Crie um cluster com o recurso ativado.
- Associe os Grupos do Google a conjuntos de permissões de cluster.
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:
Crie um Grupo do Google no seu domínio, chamado
gke-security-groups@yourdomain.com
. O Grupo precisa ter o mesmo nomegke-security-groups
. Verifique se o grupogke-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.
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".
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:
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:
No Console do Cloud, acesse a página Registros de auditoria no menu IAM.
Na tabela, selecione API do Kubernetes Engine.
No menu Tipo de registro, selecione:
- Leitura de administradores
- Leitura de dados
- Gravação de dados
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.
Execute um comando usando
kubectl
no cluster. Pode ser tão simples quantokubectl create ns helloworld
.Insira uma consulta personalizada na página Visualizador de registros. Para executar a consulta, faça o seguinte:
No Console do Cloud, acesse a página Visualizador de registros no menu Registro.
Clique na seta da caixa Visualização da consulta, na parte superior da página.
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.
Selecione Executar consulta. Você deverá receber pelo menos um resultado. Caso contrário, tente aumentar o período.
Selecione o cluster que você quer examinar.
Clique em Expandir campos aninhados.
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.
- Os grupos são membros do
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:
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çomy-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'
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
- Saiba como criar políticas do IAM.