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. -
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 CLI a usar a 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.
- Escolha uma região padrão do Compute Engine.
- Defina o ID do projeto padrão:
gcloud config set project PROJECT_ID
- Defina a região padrão do Compute Engine (por exemplo,
us-central1
):gcloud config set compute/region COMPUTE_REGION
- Defina a zona padrão do Compute Engine (por exemplo,
us-central1-c
):gcloud config set compute/zone COMPUTE_ZONE
- Atualize
gcloud
para a versão mais recente:gcloud components update
gcloud init
gcloud config
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
ouClusterRoleBinding
. - 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
ouClusterRole
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:
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.
- Saiba como configurar o Grupos do Google para RBAC.