Este documento descreve a federação de identidade da carga de trabalho para o GKE, incluindo como ela funciona, como a ativação afeta seus clusters do GKE e como conceder papéis a entidades do Kubernetes em políticas do Identity and Access Management. Na maioria dos casos, a federação de identidade da carga de trabalho para GKE é a maneira recomendada de proteger e gerenciar como suas cargas de trabalho executadas no GKE acessam os serviços do Google Cloud .
Este documento é destinado a especialistas e operadores de segurança que gerenciam cargas de trabalho no GKE que exigem acesso a outros serviços do Google Cloud. Para saber mais sobre papéis comuns e tarefas de exemplo que mencionamos no conteúdo do Google Cloud , consulte Tarefas e funções de usuário comuns do GKE.
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 doGoogle 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 doGoogle 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 aGoogle Cloud APIs específicas 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.
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 Google Cloud compatíveis de cargas de trabalho em execução, por exemplo, AWS, Azure e Kubernetes autogerenciado. No GKE, 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.
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 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. O GKE não exclui esse pool de identidades de carga de trabalho mesmo que você exclua todos os clusters no seu projeto.
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 em 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 Google Cloud específico
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 Google Cloud , por exemplo, ao usar uma biblioteca de cliente Google Cloud , ocorrem as seguintes etapas de autenticação:
- As credenciais padrão do aplicativo (ADC) solicitam um token de acesso 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 de curta duração que faz referência à identidade da carga de trabalho do Kubernetes.
O token de acesso federado retornado pelo Security Token Service pode ter limitações ao tentar acessar alguns serviços do Google Cloud , conforme descrito em Produtos e limitações compatíveis. Se o serviço Google Cloud selecionado tiver limitações, você poderá configurar a personificação da conta de serviço. Esse método resulta em um token de acesso para uma conta de serviço do IAM que sua carga de trabalho pode usar para acessar o serviço de destino. Para mais detalhes, consulte vincular contas de serviço do Kubernetes ao IAM.
A carga de trabalho pode acessar as APIs do Google Cloud que o identificador do IAM principal da carga de trabalho pode acessar. Google Cloud
Cota da API Exchange Token no Security Token Service
A API Exchange Token no Security Token Service tem um limite de cota
de 6.000 solicitações por minuto. Se você encontrar erros QUOTA_EXCEEDED, poderá
solicitar um aumento na cota de Token exchange requests per minute na página
Cotas e limites do sistema.
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 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. 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 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.
Servidor de metadados do GKE
Quando você ativa a federação de identidade da carga de trabalho para o GKE em um cluster, cada nó do cluster armazena metadados 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.
Ciclo de vida do token
Por padrão, o token de acesso retornado tem uma vida útil de 1 hora (3.600 segundos). Para reduzir a latência do cliente, o servidor de metadados do GKE armazena em cache os tokens de acesso. Em algumas situações, o token em cache retornado pelo servidor de metadados pode estar perto do prazo de validade.
As bibliotecas de cliente do Cloud têm uma lógica integrada que, por padrão, verifica se o token de acesso expira nos próximos 3 minutos e 45 segundos. Se o token estiver dentro do período de validade, o GKE vai atualizar o token. Chamadas de API consecutivas podem usar o token atualizado.
Se você usar seu próprio código para acessar diretamente as APIs Google Cloud , implemente uma lógica semelhante para processar a expiração do token. O código precisa fazer o seguinte:
- Verifique se o token de acesso expira após um período de 3 minutos e 45
segundos. O parâmetro
expno payload do token indica o carimbo de data/hora de expiração do token. - Se o token estiver definido para expirar nos próximos 3 minutos e 45 segundos, faça uma solicitação de token.
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. |
Os atributos listados na tabela são os únicos compatíveis. Se você
tentar acessar atributos não compatíveis, o pod gke-metadata-server no
namespace kube-system vai gerar e registrar um erro 404.
O erro é semelhante a este:
HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"
Se você estiver usando o istio-proxy, vai encontrar uma mensagem de erro como esta:
Error fetching GCP Metadata property gcp_gce_instance_template: metadata: GCE metadata "instance/attributes/UNSUPPORTED_ATTRIBUTE" not defined
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 Google Cloud . |
numeric-project-id |
O número do seu projeto Google Cloud . |
Restrições da federação de identidade da carga de trabalho para o GKE
Não é possível mudar o nome do pool de identidades da carga de trabalho que o GKE cria para o projeto Google Cloud .
Se você vincular contas de serviço do Kubernetes a contas de serviço do IAM para configurar a Federação de Identidade da Carga de Trabalho para GKE, o servidor de metadados do GKE vai retornar um valor de
SERVICEACCOUNT_NAME.svc.id.googcomo o identificador da conta de serviço. Esse identificador não usa a sintaxe padrão de identificador principal do IAM, o que pode causar erros em algumas operações programáticas. Para receber o identificador da conta de serviço como um identificador principal do IAM, adicione a anotaçãoiam.gke.io/return-principal-id-as-email: "true"à sua ServiceAccount do Kubernetes.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.
Ao usar o driver CSI do Cloud Storage FUSE com clusters padrão do GKE na versão
1.33.3-gke.1226000ou mais recente, os pods em execução na rede do host (hostNetwork: true) podem se autenticar usando a própria conta de serviço do Kubernetes. Para mais informações, consulte Configurar o acesso para pods com rede de 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 500 conexões simultâneas com o servidor de metadados do GKE para cada nó. Outras chamadas simultâneas que excedem esse limite são colocadas em uma fila de espera para processamento posterior. Esse mecanismo de enfileiramento pode causar erros de
HTTP/499se o tempo limite do cliente for atingido antes que o servidor de metadados do GKE possa processar a solicitação.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.
A federação de identidade da carga de trabalho para GKE opera em um perímetro do VPC Service Controls, permitindo o acesso a recursos dentro dele. No entanto, o VPC Service Controls não aplica o controle de acesso para solicitações entre perímetros com base nessas identidades federadas. É possível usar a identidade temporária de conta de serviço para acessar recursos em um perímetro diferente.
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 doGoogle 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.
- Saiba mais sobre a federação de identidade da carga de trabalho em outros ambientes.
- Forneça suporte à federação de identidade da carga de trabalho para clusters em frotas usando a identidade da carga de trabalho da frota.