A federação de identidade da carga de trabalho para GKE é a maneira recomendada para que suas cargas de trabalho em execução no Google Kubernetes Engine (GKE) acessem os serviços do Google Cloud de maneira segura e gerenciável.
A federação de identidade da carga de trabalho para GKE está disponível por meio da federação de identidade da carga de trabalho do IAM, que fornece identidades para cargas de trabalho executadas em ambientes dentro e fora do Google Cloud. É possível usar a federação de identidade da carga de trabalho do IAM para se autenticar com segurança nas APIs do Google Cloud compatíveis de cargas de trabalho em execução, por exemplo, AWS, Azure e Kubernetes autogerenciado. No GKE, o Google Cloud gerencia o pool de identidade e o provedor da carga de trabalho para você e não exige um provedor de identidade externo.
- Para saber mais sobre a federação de identidade da carga de trabalho em outros ambientes, consulte Federação de identidade da carga de trabalho.
- Para ativar e usar a federação de identidade da carga de trabalho para o GKE, consulte Acessar as APIs do Google Cloud das cargas de trabalho do GKE.
- Para oferecer suporte à federação de identidade da carga de trabalho para clusters em frotas, use a identidade da carga de trabalho da frota.
Terminologia
Nesta página, diferenciamos as contas de serviço do Kubernetes das contas de serviço do Identity and Access Management (IAM).
- Contas de serviço do Kubernetes
- Recursos do Kubernetes que fornecem uma identidade para processos em execução nos pods do GKE.
- Contas de serviço do IAM
- Recursos do Google Cloud que permitem que os aplicativos façam chamadas autorizadas para as APIs do Google Cloud.
O que é a federação de identidade da carga de trabalho do GKE?
Os aplicativos em execução no GKE talvez precisem de acesso às APIs do Google Cloud, como a API Compute Engine, a API BigQuery Storage ou as APIs Machine Learning.
A federação de identidade da carga de trabalho para GKE permite usar políticas do IAM para conceder às cargas de trabalho do Kubernetes no cluster do GKE acesso a APIs específicas do Google Cloud sem precisar de configuração manual ou métodos menos seguros, como arquivos de chave da conta de serviço. O uso da federação de identidade da carga de trabalho para o GKE permite atribuir identidades e autorizações distintas e refinadas para cada aplicativo no cluster.
A federação de identidade da carga de trabalho do GKE substitui a necessidade de usar a ocultação de metadados. Os metadados confidenciais protegidos por Metadata Concealment também são protegidos pela federação de identidade da carga de trabalho para GKE.
Como funciona a federação de identidade da carga de trabalho para o GKE
Quando você ativa a federação de identidade da carga de trabalho para o GKE em um cluster, o GKE faz o seguinte:
Cria um pool de identidade da carga de trabalho fixo para o projeto do Google Cloud do cluster com o seguinte formato:
PROJECT_ID.svc.id.googO pool de identidades de carga de trabalho apresenta um formato de nomenclatura que permite que o IAM entenda e confie nas credenciais da conta de serviço do Kubernetes.
Registra o cluster do GKE como um provedor de identidade no pool de identidade da carga de trabalho.
Implanta o servidor de metadados do GKE, que intercepta solicitações de credenciais das cargas de trabalho em cada nó.
Criar políticas de permissão do IAM nos recursos do Google Cloud
Para fornecer acesso com a federação de identidade da carga de trabalho para o GKE, crie uma política de permissão do IAM
que conceda acesso a um recurso específico do Google Cloud
a um principal que corresponda à identidade do seu aplicativo. Por exemplo,
é possível conceder permissões de leitura em um bucket do Cloud Storage para todos os pods que
usam a conta de serviço database-reader do Kubernetes.
Para ver uma lista de recursos compatíveis com políticas de permissão, consulte Tipos de recursos que aceitam políticas de permissão.
Usar condições em políticas do IAM
Também é possível limitar o escopo do acesso definindo conditions nas políticas de permissão. As condições são um método extensível de especificação de quando uma política de permissão precisa ser aplicada. Por exemplo, é possível usar condições para conceder acesso temporário a uma carga de trabalho em um recurso específico do Google Cloud, eliminando a necessidade de gerenciar esse acesso manualmente.
As condições também podem ser úteis se você definir as políticas de permissão no nível do projeto, da pasta ou da organização em vez de recursos específicos, como segredos do Secret Manager ou buckets do Cloud Storage.
Para adicionar uma condição à sua política de permissão, use estes recursos:
- Gerenciar vinculações de papéis condicionais: adicione, modifique ou remova vinculações de papéis condicionais.
- Configurar o acesso temporário: use condições para definir o acesso com vencimento aos recursos do Google Cloud nas políticas de permissão.
- Tags e acesso condicional: use condições para aplicar políticas de permissão apenas quando os recursos tiverem tags específicas.
Os exemplos de expressões a seguir são para cenários comuns em que você pode usar condições. Para uma lista de atributos disponíveis em expressões, consulte Referência de atributo para condições do IAM.
| Exemplo de expressões condicionais | ||
|---|---|---|
| Permitir acesso antes do horário especificado | request.time < timestamp('Substitua |
|
| Permitir acesso se o recurso na solicitação tiver a tag especificada | resource.matchTag('Substitua:
|
|
Referenciar recursos do Kubernetes nas políticas do IAM
Na política do IAM, você faz referência a um recurso do Kubernetes usando um identificador principal do IAM para selecionar o recurso. Esse identificador tem a seguinte sintaxe:
PREFIX://iam.googleapis.com/projects/1234567890/locations/global/workloadIdentityPools/example-project.svc.id.goog/SELECTOR
Neste exemplo, considere os seguintes campos:
PREFIX: precisa serprincipalouprincipalSet, dependendo do recurso selecionado.principalserve para um recurso específico, como uma única ServiceAccount.principalSetserve para vários recursos que pertencem ao recurso especificado, como todos os pods em um cluster específico.SELECTOR: uma string que seleciona um tipo de principal. Por exemplo,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDseleciona uma ServiceAccount pelo UID.
A tabela a seguir mostra os tipos de principais compatíveis com o GKE:
| Tipo de identificador principal | Sintaxe |
|---|---|
| Todos os pods que usam uma conta de serviço específica do Kubernetes | Selecione a conta de serviço pelo nome:
principal://iam.googleapis.com/projects/Substitua:
Selecionar a ServiceAccount pelo UID: principal://iam.googleapis.com/projects/Substitua:
|
| Todos os pods em um namespace, independentemente da conta de serviço ou do cluster | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/namespace/NAMESPACE Substitua:
|
| Todos os pods em um cluster específico | principalSet://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/kubernetes.cluster/https://container.googleapis.com/v1/projects/PROJECT_ID/locations/LOCATION/clusters/CLUSTER_NAME Substitua:
|
Fluxo de credenciais
Quando uma carga de trabalho envia uma solicitação para acessar uma API do Google Cloud, por exemplo, ao usar uma biblioteca de cliente do Google Cloud, ocorrem as seguintes etapas de autenticação:
- O Application Default Credentials (ADC) solicita um token de acesso do Google Cloud do servidor de metadados do Compute Engine executado na VM.
- O servidor de metadados do GKE intercepta a solicitação de token e solicita ao servidor da API Kubernetes um token da conta de serviço do Kubernetes que identifique a carga de trabalho solicitante. Essa credencial é um JSON Web Token (JWT) assinado pelo servidor da API.
- O servidor de metadados do GKE usa o Serviço de token de segurança para trocar o JWT por um token de acesso federado do Google Cloud de curta duração que faz referência à identidade da carga de trabalho do Kubernetes.
- O servidor de metadados do GKE fornece o token de acesso federado à carga de trabalho.
A carga de trabalho pode acessar as APIs do Google Cloud que o identificador do IAM principal da carga de trabalho pode acessar.
Semelhança de identidade
Se os metadados no identificador do principal forem os mesmos para cargas de trabalho em vários clusters que compartilham um pool de Identidade da carga de trabalho por pertencerem ao mesmo projeto do Google Cloud, o IAM identificará essas cargas como sendo as mesmas. Por exemplo, se você tiver o mesmo namespace em dois clusters e conceder acesso a esse namespace no IAM, as cargas de trabalho nesse namespace em ambos os clusters terão esse acesso. É possível limitar esse acesso a clusters específicos usando políticas condicionais do IAM.
Por exemplo, considere o diagrama a seguir. Os clusters A e B pertencem ao
mesmo pool de Identidade da carga de trabalho. O Google Cloud identifica aplicativos que usam a ServiceAccount back-ksa no namespace backend do Cluster A e do Cluster B como a mesma identidade. O IAM não faz distinção entre os clusters que fazem as chamadas.
Essa semelhança de identidade também significa que você precisa confiar em todos os clusters em um pool de identidades de carga de trabalho específico. Por exemplo, se um novo cluster, o Cluster C
no exemplo anterior, fosse de uma equipe não confiável, ela poderia criar um
namespace backend e acessar as APIs do Google Cloud usando a ServiceAccount
back-ksa, assim como os Clusters A e B.
Para evitar o acesso não confiável, coloque os clusters em projetos separados para garantir que eles tenham pools de identidade de carga de trabalho diferentes ou que os nomes de namespace sejam diferentes para evitar um identificador principal comum.
Noções básicas do servidor de metadados do GKE
Cada nó em um GKE com federação de identidade da carga de trabalho para GKE ativado armazena os metadados dele no servidor de metadados do GKE. O servidor de metadados do GKE é um subconjunto dos endpoints do servidor de metadados do Compute Engine necessários para as cargas de trabalho do Kubernetes.
O servidor de metadados do GKE é executado como um DaemonSet, com um pod em cada nó do Linux ou um serviço do Windows nativo em cada nó do Windows no cluster. O servidor de metadados intercepta solicitações HTTP para http://metadata.google.internal (169.254.169.254:80). Por exemplo, a solicitação GET
/computeMetadata/v1/instance/service-accounts/default/token recupera um
token para a conta de serviço do IAM que o pod está configurado para personificar.
O tráfego para o servidor de metadados nunca sai da instância de VM que hospeda o pod.
Veja nas tabelas a seguir o subconjunto de endpoints do servidor de metadados do Compute Engine disponíveis com o servidor de metadados do GKE. Para uma lista completa de endpoints disponíveis no servidor de metadados do Compute Engine, consulte Valores de metadados da VM padrão.
Metadados de instância
Os metadados da instância são armazenados no diretório a seguir.
http://metadata.google.internal/computeMetadata/v1/instance/
| Entrada | Descrição |
|---|---|
hostname |
O nome do host do nó. |
id |
O ID exclusivo do seu nó. |
service-accounts/ |
Um diretório das contas de serviço associadas à instância. As seguintes informações estão disponíveis para cada conta de serviço:
|
zone |
A zona do Compute Engine do seu nó do GKE. |
Atributos da instância
Os atributos da instância são armazenados no seguinte diretório.
http://metadata.google.internal/computeMetadata/v1/instance/attributes/
| Entrada | Descrição |
|---|---|
cluster-location |
A zona ou a região do Compute Engine do cluster. |
cluster-name |
: o nome do cluster do GKE. |
cluster-uid |
O UID do seu cluster do GKE. |
Metadados do projeto
Os metadados do projeto de cluster são armazenados no diretório a seguir.
http://metadata.google.internal/computeMetadata/v1/project/
| Entrada | Descrição |
|---|---|
project-id |
É o ID do seu projeto no Google Cloud. |
numeric-project-id |
Seu número do projeto do Google Cloud. |
Restrições da federação de identidade da carga de trabalho para o GKE
Não é possível alterar o nome do pool de identidades da carga de trabalho que o GKE cria para o projeto do Google Cloud.
Quando o GKE ativa o servidor de metadados do GKE em um pool de nós, os pods não podem mais acessar o servidor de metadados do Compute Engine. Em vez disso, o servidor de metadados do GKE intercepta solicitações feitas desses pods para endpoints de metadados, com exceção dos pods em execução na rede do host.
O servidor de metadados do GKE leva alguns segundos para começar a aceitar solicitações em um pod recém-criado. Portanto, as tentativas de autenticação usando a federação de identidade da carga de trabalho para o GKE nos primeiros segundos da vida útil de um pod podem falhar. Tentar novamente a chamada resolverá o problema. Consulte Solução de problemas para mais detalhes.
Os agentes integrados de geração de registros e monitoramento do GKE continuarão a usar a conta de serviço do nó.
A federação de identidade da carga de trabalho para o GKE exige a configuração manual para que Knative serving continue lançando métricas de solicitação.
A federação de identidade da carga de trabalho para GKE define um limite de 200 conexões com o servidor de metadados do GKE para cada nó, evitando problemas de memória. Expirações de tempo limite podem acontecer se os nós excederem esse limite.
A federação de identidade da carga de trabalho para nós do Windows Server está disponível nas versões do GKE 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 e posteriores.
O servidor de metadados do GKE usa recursos de memória proporcionalmente ao número total de contas de serviço do Kubernetes no seu cluster. Se o cluster tiver mais de 3.000 contas de serviço do Kubernetes, o kubelet poderá encerrar os pods do servidor de metadados. Para mitigações, consulte Solução de problemas.
Alternativas à federação de identidade da carga de trabalho do GKE
É possível usar uma das seguintes alternativas à federação de identidade da carga de trabalho para que o GKE acesse as APIs do Google Cloud pelo GKE. Recomendamos que você use a federação de identidade da carga de trabalho para o GKE porque essas alternativas exigem que você faça alguns compromissos de segurança.
Use a conta de serviço padrão do Compute Engine dos nós. É possível executar pools de nós como qualquer conta de serviço do IAM no projeto. Se você não especificar uma conta de serviço durante a criação do pool de nós, o GKE usará a conta de serviço padrão do Compute Engine para o projeto. A conta de serviço do Compute Engine é compartilhada por todas as cargas de trabalho implantadas no nó. Isso pode resultar no provisionamento excessivo de permissões, o que viola o princípio do menor privilégio e é inadequado para clusters multilocatários.
Exporte as chaves de conta de serviço e armazene-as como secrets do Kubernetes ativados nos pods como volumes.
A seguir
- Saiba como ativar e configurar a federação de identidade da carga de trabalho para o GKE.
- Saiba mais sobre o servidor de metadados do Compute Engine.