Nesta página, mostramos como autorizar ações em recursos nos clusters do Google Kubernetes Engine (GKE) usando o mecanismo integrado de controle de acesso baseado em papéis (RBAC, na sigla em inglês) no Kubernetes.
O RBAC é um recurso de segurança principal do Kubernetes, que permite criar permissões refinadas para gerenciar quais ações os usuários e cargas de trabalho podem executar nos recursos dos clusters. Como administrador de plataforma, você cria papéis do RBAC e vincula esses papéis a assuntos, que são usuários autenticados, como contas de serviço ou grupos. 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:
- Ativar a API Google Kubernetes Engine. Ativar a API Google Kubernetes Engine
- Se você quiser usar a Google Cloud CLI para essa tarefa,
instale e, em seguida,
inicialize a
CLI gcloud. Se você instalou a CLI gcloud anteriormente, instale a versão
mais recente executando
gcloud components update
.
- Leia Práticas recomendadas para o RBAC do GKE para ver diretrizes sobre como melhorar o design das políticas do RBAC.
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.
Para autorizar uma ação, o GKE primeiro verifica se há uma política de RBAC. Se não houver uma política de RBAC, o GKE vai verificar as permissões do IAM.
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
Verificar o acesso à API usando kubectl
kubectl
fornece o subcomando auth can-i
para consultar rapidamente a camada de autorização da API. Como administrador da plataforma, talvez você precise representar os usuários para determinar quais ações podem ser realizadas. É possível usar o auth can-i
e transmitir uma flag --as
adicional.
Quando você executa o comando kubectl auth can-i
sem a flag --as
, o Identity and Access Management (IAM) executa a autorização. Já quando você anexa a flag --as
, o RBAC do Kubernetes executa a autorização. Portanto, você precisará criar os objetos Role
e RoleBinding
necessários para o RBAC.
Para mais informações, consulte Como verificar o acesso à API.
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 RBAC e o IAM do Kubernetes.
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
Permissão para criar ou atualizar papéis e vinculações dos papéis
No Kubernetes, você só pode criar ou atualizar um papel ou uma vinculação do papel com permissões específicas se atender às seguintes condições:
- Criar ou atualizar um papel: você precisa ter as mesmas permissões
que quer conceder ao papel. Como alternativa, é necessário ter autorização para executar o verbo
escalate
no papel. - Criar ou atualizar uma vinculação do papel: você precisa ter as mesmas
permissões que são concedidas ao papel que está sendo vinculado, com o mesmo
escopo que a vinculação do papel. Como alternativa, é necessário ter autorização para executar o verbo
bind
no papel referenciado.
Se as permissões que você está concedendo ao papel forem originalmente
concedidas a você usando uma política do IAM em vez de RBAC,
é possível que sua solicitação de vinculação do papel ou o papel falhe. Por exemplo, considere a
seguinte solicitação de criação de papel, de um usuário que recebeu
as permissões do IAM container.pods.*
e
container.roles.create
:
kubectl create role allowed-to-view-pods --resource pods --verb list,get
Se o usuário recebesse apenas as permissões usando o IAM, poderia ocorrer o seguinte erro:
Error from server (Forbidden): clusterroles.rbac.authorization.k8s.io "allowed-to-view-pods" is forbidden:
user "caller@example.com" (groups=["system:authenticated"]) is attempting to grant RBAC permissions not currently held:
{APIGroups:[""], Resources:["pods"], Verbs:["list" "get"]}
Para atenuar essa limitação, conceda ao autor da chamada as permissões no papel usando o RBAC em vez do IAM.
Como alternativa, você pode usar o RBAC ou o IAM para conceder ao
autor da chamada o verbo escalate
, bind
ou ambos. No entanto
o GKE não recomenda essa abordagem, porque o autor da chamada
pode conceder qualquer permissão a qualquer papel.
A seguir
- Saiba como criar políticas do IAM.
- Saiba como configurar o Grupos do Google para RBAC.