Esta página descreve as contas de serviço no Google Kubernetes Engine (GKE) e como fornecem identidades para aplicações. Vai saber mais sobre os diferentes tipos de contas de serviço e quando usar cada tipo para autenticar o acesso aos recursos no GKE sem depender de credenciais pessoais.
Esta página destina-se a especialistas de segurança e operadores que criam e gerem contas de serviço para interagir com aplicações 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. Trusted Cloud by S3NS
Contas de serviço do Kubernetes e contas de serviço da IAM
A tabela seguinte descreve as principais diferenças entre as contas de serviço do Kubernetes e as contas de serviço do IAM:
Tipos de contas de serviço no GKE | |
---|---|
ServiceAccount do Kubernetes |
|
Conta de serviço do IAM |
|
ServiceAccounts do Kubernetes
As contas de serviço do Kubernetes são geridas ao nível do cluster e existem no servidor da API Kubernetes como objetos ServiceAccount
. A documentação do Kubernetes e a documentação do GKE usam frequentemente o termo ServiceAccount para distinguir estes recursos do Kubernetes das contas de serviço noutros ambientes, como o IAM.
Cria uma ServiceAccount do Kubernetes num espaço de nomes e, em seguida, atribui essa ServiceAccount a um pod através do campo serviceAccountName
no manifesto do pod. O processo kubelet no nó recebe um token de portador de curta duração para a ServiceAccount atribuída e monta o token como um volume projetado no pod. Por predefinição, este volume projetado tem um nome que começa com o prefixo kube-api-access-
. Todos os volumes que começam com este prefixo são geridos pelo GKE, o que significa que não pode modificar o tamanho destes volumes. Para uma monitorização da utilização do disco mais precisa, exclua os volumes que começam
com o prefixo kube-api-access-
da configuração de monitorização.
O token de portador de curta duração é um token da Web JSON (JWT) assinado pelo servidor da API, que é um fornecedor do OpenID Connect (OIDC). Para validar o token de autorização, obtenha a chave de validação pública para o cluster chamando o método projects.locations.clusters.getJwks
na API GKE.
- Para saber o básico sobre as contas de serviço do Kubernetes, consulte o artigo Contas de serviço na documentação do Kubernetes.
- Para saber como criar novas contas de serviço, conceder autorizações através do controlo de acesso baseado em funções (RBAC) e atribuir contas de serviço a pods, consulte o artigo Configurar contas de serviço para pods.
- Para ver as práticas recomendadas ao gerir ServiceAccounts do Kubernetes, consulte o artigo Práticas recomendadas para RBAC.
- Para ler a configuração OIDC do servidor da API Kubernetes para um cluster,
chame o método
projects.locations.clusters.well-known.getOpenid-configuration
na API GKE.
Credenciais da conta de serviço do Kubernetes comprometidas
Se uma credencial da conta de serviço do Kubernetes for comprometida, use uma das seguintes opções para revogar as credenciais:
- Recrie os seus pods: o token de portador está associado a cada UID do pod exclusivo, pelo que a recriação dos pods invalida as credenciais anteriores.
- Recrie a conta de serviço do Kubernetes: o token de portador está associado ao UID do objeto ServiceAccount na API Kubernetes. Elimine a ServiceAccount e crie uma nova ServiceAccount com o mesmo nome. Os tokens anteriores tornam-se inválidos porque o UID da nova conta de serviço é diferente.
- Efetue uma rotação de credenciais: esta operação revoga todas as credenciais da conta de serviço do Kubernetes no seu cluster. A rotação também altera o certificado da AC e o endereço IP do cluster. Para obter detalhes, consulte o artigo sobre a rotação de credenciais.
Contas de serviço do IAM
As contas de serviço da IAM são geridas ao nível do projeto através da API IAM. Pode usar estas contas de serviço para realizar ações como chamar APIs Trusted Cloud programaticamente e gerir autorizações para aplicações em execução em Trusted Cloud produtos.
Para saber mais, consulte a vista geral das contas de serviço do IAM.
Agentes de serviço do GKE
Um agente do serviçodo IAM é uma conta de serviço do IAM que o Trusted Cloud gerencia.
O GKE usa o agente do serviço do Kubernetes Engine para gerir o ciclo de vida dos recursos do cluster em seu nome, como nós, discos e equilibradores de carga. Este agente do serviço tem o domínio
container-engine-robot.s3ns.iam.gserviceaccount.com
e recebe
a função de
agente do serviço do Kubernetes Engine (roles/container.serviceAgent
) no seu projeto quando ativa a
API GKE.
O identificador deste agente do serviço é o seguinte:
service-PROJECT_NUMBER@container-engine-robot.s3ns.iam.gserviceaccount.com
PROJECT_NUMBER
é o seu número do projeto numérico.
Se remover as autorizações do agente de serviço no seu projeto, pode recuperá-las seguindo as instruções em Erro 400/403: faltam autorizações de edição na conta.
Conta de serviço do nó do GKE predefinida
O GKE usa contas de serviço da IAM anexadas aos seus nós para
executar tarefas do sistema, como registo e monitorização. No mínimo, estas contas de serviço de nós
têm de ter a função
Conta de serviço de nós predefinida do Kubernetes Engine
(roles/container.defaultNodeServiceAccount
) no seu projeto. Por predefinição,
o GKE usa a
conta de serviço predefinida do Compute Engine,
que é criada automaticamente no seu projeto, como a conta de serviço do nó.
Se a sua organização aplicar a restrição da política da organização iam.automaticIamGrantsForDefaultServiceAccounts
, a conta de serviço do Compute Engine predefinida no seu projeto pode não receber automaticamente as autorizações necessárias para o GKE.
Se usar a conta de serviço predefinida do Compute Engine para outras funções no seu projeto ou organização, a conta de serviço pode ter mais autorizações do que o GKE precisa, o que pode expô-lo a riscos de segurança.
Para conceder a função roles/container.defaultNodeServiceAccount
à conta de serviço predefinida do Compute Engine, conclua os passos seguintes:
consola
- Aceda à página Boas-vindas:
- No campo Número do projeto, clique em Copiar para a área de transferência.
- Aceda à página IAM:
- Clique em Conceder acesso.
- No campo Novos responsáveis, especifique o seguinte valor:
SubstituaPROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com
PROJECT_NUMBER
pelo número do projeto que copiou. - No menu Selecionar uma função, selecione a função Conta de serviço do nó predefinido do Kubernetes Engine.
- Clique em Guardar.
gcloud
- Encontre o seu Trusted Cloud número do projeto:
gcloud projects describe PROJECT_ID \ --format="value(projectNumber)"
Substitua
PROJECT_ID
pelo ID do seu projeto.O resultado é semelhante ao seguinte:
12345678901
- Conceda a função
roles/container.defaultNodeServiceAccount
à conta de serviço predefinida do Compute Engine:gcloud projects add-iam-policy-binding PROJECT_ID \ --member="serviceAccount:PROJECT_NUMBER-compute@developer.s3ns-system.iam.gserviceaccount.com" \ --role="roles/container.defaultNodeServiceAccount"
Substitua
PROJECT_NUMBER
pelo número do projeto do passo anterior.
Não desative a conta de serviço predefinida do Compute Engine, a menos que esteja a fazer a migração para contas de serviço geridas pelo utilizador.
Quando usar uma conta de serviço específica
O tipo de conta de serviço que usa depende do tipo de identidade que quer fornecer para as suas aplicações, da seguinte forma:
- Forneça uma identidade para os seus pods usarem no cluster: use uma
ServiceAccount do Kubernetes. Todos os espaços de nomes do Kubernetes têm uma
default
ServiceAccount, mas recomendamos que crie novas ServiceAccounts com privilégios mínimos para cada carga de trabalho em cada espaço de nomes. - Forneça uma identidade para os seus pods usarem fora do cluster: use a Federação do Workload Identity para o GKE. A federação de identidade da carga de trabalho para o GKE permite-lhe especificar recursos do Kubernetes, como ServiceAccounts, como principais nas políticas do IAM. Por exemplo, use a Workload Identity Federation para o GKE quando chamar Trusted Cloud APIs como o Secret Manager ou o Spanner a partir dos seus pods.
- Forneça uma identidade predefinida para os seus nós: use uma conta de serviço do IAM com privilégios mínimos personalizada quando criar os seus clusters ou nós do GKE. Se não usar uma conta de serviço do IAM personalizada, o GKE usa a conta de serviço predefinida do Compute Engine.
O que se segue?
- Saiba como usar contas de serviço Google com privilégios mínimos.
- Saiba como conceder uma função a um principal.