Autorize ações em clusters através do controlo de acesso baseado em funções

Esta página mostra como autorizar ações em recursos nos seus clusters do Google Kubernetes Engine (GKE) através do mecanismo de controlo de acesso baseado em funções (RBAC) incorporado no Kubernetes. O CABF do Kubernetes está ativado por predefinição, o que lhe dá um controlo detalhado sobre o acesso ao cluster.

Vai aprender a definir e atribuir autorizações precisas, criar funções e associações de funções para gerir o acesso dos utilizadores, validar o acesso à API para verificar o nível de acesso, resolver problemas comuns e compreender as limitações quando trabalha com RBAC no GKE.

Esta página destina-se a especialistas e operadores de segurança que querem usar o RBAC para melhorar a segurança nos respetivos clusters do GKE. Para saber mais sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE. Google Cloud

Antes de ler esta página, certifique-se de que conhece os seguintes conceitos:

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

  • Ative a API Google Kubernetes Engine.
    • Ative a API Google Kubernetes Engine
  • Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute gcloud components update para obter a versão mais recente.

Interação com a gestão de identidade e de acesso

Pode usar a gestão de identidade e de acesso (IAM) e o RBAC do Kubernetes para controlar o acesso ao seu cluster do GKE:

  • O IAM não é específico do Kubernetes. Fornece gestão de identidades para vários Google Cloud produtos e opera principalmente ao nível do Google Cloud projeto.

  • O RBAC do Kubernetes é um componente essencial do Kubernetes e permite-lhe criar e conceder funções (conjuntos de autorizações) para qualquer objeto ou tipo de objeto no cluster.

  • Para autorizar uma ação, o GKE verifica primeiro uma política de RBAC. Se não existir uma política RBAC, o GKE verifica as autorizações IAM.

No GKE, o IAM e o RBAC do Kubernetes estão integrados para autorizar os utilizadores a realizar ações se tiverem autorizações suficientes de acordo com qualquer uma das ferramentas. Esta é uma parte importante do arranque de um cluster do GKE, uma vez que, por predefinição, Google Cloud os utilizadores não têm nenhuma RoleBinding do RBAC do Kubernetes.

Para autorizar utilizadores através de contas Google Cloud , o cliente tem de estar corretamente configurado para autenticar primeiro através dessas contas. Por exemplo, se estiver a usar o kubectl, tem de configurar o comando kubectl para fazer a autenticação no Google Cloud antes de executar quaisquer comandos que exijam autorização.

Em quase todos os casos, pode usar o RBAC do Kubernetes em vez do IAM. Os utilizadores do GKE precisam, no mínimo, da autorização container.clusters.get do IAM no projeto que contém o cluster. Esta autorização está incluída na função container.clusterViewer e noutras funções com mais privilégios. A autorização container.clusters.get é necessária para que os utilizadores se autentiquem nos clusters do projeto, mas não os autoriza a realizar ações nesses clusters. A autorização pode ser fornecida pelo IAM ou pelo RBAC do Kubernetes.

Defina e atribua autorizações

Pode definir regras de RBAC em objetos ClusterRole e Role e, em seguida, atribuir essas regras com objetos ClusterRoleBinding e RoleBinding da seguinte forma:

  • ClusterRole: um agrupamento ao nível do cluster de recursos e operações permitidas que pode atribuir a um utilizador ou a um grupo através de um RoleBinding ou um ClusterRoleBinding.
  • Função: um agrupamento com espaço de nomes de recursos e operações permitidas que pode atribuir a um utilizador ou a um grupo de utilizadores através de um RoleBinding.
  • ClusterRoleBinding: atribui um ClusterRole a um utilizador ou a um grupo para todos os namespaces no cluster.
  • RoleBinding: atribui uma Role ou uma ClusterRole a um utilizador ou um grupo num namespace específico.

Quando usa um RoleBinding para atribuir um ClusterRole a um utilizador ou a um grupo, esses utilizadores e grupos só podem aceder a recursos no espaço de nomes que especificar no RoleBinding. Se quiser que os utilizadores ou os grupos acedam ao recurso em todos os namespaces, use um ClusterRoleBinding.

Defina autorizações através de funções ou ClusterRoles

Define autorizações num objeto Role ou ClusterRole. Uma função define o acesso a recursos num único espaço de nomes, enquanto uma função de cluster define o acesso a recursos em todo o cluster.

Os Roles e os ClusterRoles têm a mesma sintaxe. Cada um tem uma secção rules, onde define os recursos aos quais a regra se aplica e as operações permitidas para a função. Por exemplo, a seguinte atribuição de função concede acesso de leitura (get, watch e list) a todos os pods no espaço de nomes 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 dos campos permitidos.

Role vs. ClusterRole

Uma vez que as autorizações concedidas por um ClusterRole se aplicam a todo o cluster, pode usar ClusterRoles para controlar o acesso a diferentes tipos de recursos do que com as funções. Por exemplo:

  • Recursos com âmbito de cluster, como nós
  • Pontos finais REST não de recursos, como /healthz
  • Recursos com espaço de nomes em todos os espaços de nomes (por exemplo, todos os pods em todo o cluster, independentemente do espaço de nomes)

Atribua funções através de RoleBindings ou ClusterRoleBindings

Depois de criar uma função ou uma ClusterRole, atribui-a a um utilizador ou a um grupo de utilizadores criando uma RoleBinding ou uma ClusterRoleBinding. Os utilizadores e os grupos são denominados subjects e podem ser qualquer uma das seguintes opções:

Tipo de assunto Valor para kind Valor para name
Google Cloud conta de utilizador User Google Cloud Endereço de email registado
Conta de serviço do Kubernetes ServiceAccount O nome de um objeto Kubernetes ServiceAccount no cluster
Conta de serviço do IAM User Endereço de email da conta de serviço de IAM gerado automaticamente
Endereço do Grupo Google num domínio validado Group Endereço de email de um grupo do Google Workspace que é membro do grupo gke-security-groups. Para ver instruções sobre como configurar os Grupos Google para o RBAC, consulte o artigo Configure os Grupos Google para o RBAC.

A RoleBinding seguinte concede a função pod-reader a um utilizador, a uma conta de serviço do Kubernetes, a uma conta de serviço do IAM e a um grupo 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

Valide o acesso à API através de kubectl

kubectl fornece o subcomando auth can-i para consultar rapidamente a camada de autorização da API. Enquanto administrador da plataforma, pode ter de se fazer passar por utilizadores para determinar que ações podem realizar. Pode usar o auth can-i e transmitir uma flag --as adicional.

Quando executa o comando kubectl auth can-i sem o sinalizador --as, a gestão de identidade e de acesso (IAM) realiza a autorização. Por outro lado, quando anexa a flag --as, o RBAC do Kubernetes executa a autorização. Por conseguinte, tem de criar os objetos Role e RoleBinding necessários para o RBAC.

Para mais informações, consulte o artigo Validar o acesso à API.

Utilização e exemplos da API

Para obter informações completas sobre a utilização da API Kubernetes para criar os objetos Role, ClusterRole, RoleBinding e ClusterRoleBinding necessários para o CABF, consulte o artigo Utilizar a autorização de controlo de acesso baseado em funções na documentação do Kubernetes.

Resolva problemas de RBAC

Para depurar problemas com o RBAC, use o registo de auditoria da atividade do administrador, que está ativado em todos os clusters por predefinição. Se o acesso a um recurso ou a uma operação for recusado devido à falta de autorizações suficientes, o servidor da API regista um erro, juntamente com informações adicionais, como a associação implícita e explícita do utilizador ao grupo.RBAC DENY Se estiver a usar o Google Groups para RBAC, google groups aparece na mensagem de registo.

Limitações

As secções seguintes descrevem interações que podem não parecer óbvias quando trabalha com o RBAC e o IAM do Kubernetes.

Funções de descoberta predefinidas

Os clusters são criados com um conjunto de ClusterRoles e ClusterRoleBindings predefinidos. Os pedidos feitos com credenciais válidas são colocados no grupo system:authenticated, enquanto todos os outros pedidos pertencem ao grupo system:unauthenticated.

O system:basic-user ClusterRole permite que os utilizadores criem SelfSubjectAccessReviews para testar as respetivas autorizações no cluster. A função system:discovery permite que os utilizadores leiam APIs de deteção, que podem revelar informações sobre os CustomResourceDefinitions adicionados ao cluster.

Os utilizadores anónimos (system:unauthenticated) recebem o system:public-info-viewer ClusterRole, que concede acesso só de leitura às APIs /healthz e /version.

Para ver os pontos finais da API permitidos pelo system:discovery ClusterRole, execute o seguinte comando:

kubectl get clusterroles system:discovery -o yaml

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

O seguinte erro pode ocorrer quando a instância de VM não tem o âmbito userinfo-email:

Error from server (Forbidden): error when creating ... "role-name" is forbidden: attempt to grant extra privileges:...

Por exemplo, suponha que a VM tem o âmbito cloud-platform, mas não tem o âmbito userinfo-email. Quando a VM recebe um token de acesso, Google Cloud associa esse token ao âmbito cloud-platform. Quando o servidor da API Kubernetes pede Google Cloud a identidade associada à chave de acesso, recebe o ID exclusivo da conta de serviço e não o email da conta de serviço.

Para fazer a autenticação com êxito, crie uma nova VM com o âmbito userinfo-email ou crie uma nova associação de funções que use o ID exclusivo.

Para criar uma nova instância de VM com o âmbito userinfo-email, execute o seguinte comando:

gcloud compute instances create INSTANCE_NAME \
    --service-account SERVICE_ACCOUNT_EMAIL \
    --scopes userinfo-email

Para criar uma nova associação de funções que use o ID exclusivo da conta de serviço para uma VM existente, siga estes passos:

  1. Identifique o ID exclusivo da conta de serviço:

    gcloud iam service-accounts describe SERVICE_ACCOUNT_EMAIL

    Por exemplo, o seguinte resultado apresenta o uniqueId para a conta de serviço my-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'

  2. Crie uma associação de funções com o uniqueId da conta de serviço:

    kubectl create clusterrolebinding CLUSTERROLEBINDING_NAME \
    --clusterrole cluster-admin \
    --user UNIQUE_ID

Autorização para criar ou atualizar funções e associações de funções

No Kubernetes, só pode criar ou atualizar uma função ou uma associação de funções com autorizações específicas se cumprir as seguintes condições:

  • Criar ou atualizar uma função: já tem de ter as mesmas autorizações que quer conceder à função. Em alternativa, tem de ter autorização para executar o verbo escalate na função.
  • Criar ou atualizar uma associação de funções: já tem de ter as mesmas autorizações concedidas na função que está a ser associada, com o mesmo âmbito que a associação de funções. Em alternativa, tem de ter autorização para executar o verbo bind na função referenciada.

Se as autorizações que está a conceder na função lhe foram originalmente concedidas através de uma política de autorização do IAM em vez do RBAC, o seu pedido de função ou associação de funções pode falhar. Por exemplo, considere o seguinte pedido de criação de funções de um utilizador ao qual foram concedidas as autorizações de IAM container.pods.* e container.roles.create:

kubectl create role allowed-to-view-pods --resource pods --verb list,get

Se as autorizações tiverem sido concedidas ao utilizador apenas através do IAM, pode 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 mitigar esta limitação, conceda ao autor da chamada as autorizações na função através do RBAC em vez do IAM.

Em alternativa, pode usar RBAC ou IAM para conceder ao autor da chamada o verbo escalate, o verbo bind ou ambos. No entanto, o GKE não recomenda esta abordagem, porque o autor da chamada pode conceder qualquer autorização a qualquer função.

O que se segue?