Esta página explica a Workload Identity Federation para o GKE, incluindo como funciona, como a ativação afeta os seus clusters do GKE e como conceder funções a entidades do Kubernetes nas políticas de gestão de identidades e acessos. Na maioria dos casos, a Workload Identity Federation para o GKE é a forma recomendada para que as suas cargas de trabalho em execução no GKE acedam aos Google Cloud serviços de forma segura e gerível.
Esta página destina-se a especialistas e operadores de segurança que gerem cargas de trabalho no GKE que requerem acesso a outros serviços Google Cloud . 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 recursos:
- Para saber mais sobre a federação de identidades da carga de trabalho noutros ambientes, consulte o artigo Federação de identidades da carga de trabalho.
- Para ativar e usar a Workload Identity Federation para o GKE, consulte o artigo Aceder Google Cloud às APIs a partir de cargas de trabalho do GKE.
- Para fornecer suporte para a Workload Identity Federation para clusters em frotas, use o Workload Identity da frota.
Terminologia
Esta página distingue entre contas de serviço do Kubernetes e contas de serviço de gestão de identidade e de acesso (IAM).
- Contas de serviço do Kubernetes
- Recursos do Kubernetes que fornecem uma identidade para processos executados nos seus pods do GKE.
- Contas de serviço do IAM
- Google Cloud recursos que permitem que as aplicações façam chamadas autorizadas para Google Cloud APIs.
O que é a Workload Identity Federation para o GKE?
As aplicações executadas no GKE podem precisar de acesso a Google Cloud APIs, como a API Compute Engine, a API BigQuery Storage ou as APIs de aprendizagem automática.
A Workload Identity Federation para o GKE permite-lhe usar políticas de IAM para conceder aos workloads do Kubernetes no seu cluster do GKE acesso aGoogle Cloud APIs específicas sem precisar de configuração manual ou métodos menos seguros, como ficheiros de chaves de contas de serviço. A utilização da Workload Identity Federation para o GKE permite-lhe atribuir identidades distintas e detalhadas, bem como autorização para cada aplicação no seu cluster.
A Workload Identity Federation para o GKE substitui a necessidade de usar a ocultação de metadados. Os metadados confidenciais protegidos pela ocultação de metadados também são protegidos pela Workload Identity Federation para o GKE.
A Workload Identity Federation para o GKE está disponível através da Workload Identity Federation do IAM, que fornece identidades para cargas de trabalho executadas em ambientes dentro e fora Google Cloud. Pode usar a federação de identidades da carga de trabalho do IAM para autenticar em segurança nas APIs suportadas Google Cloud a partir de cargas de trabalho em execução, por exemplo, no AWS, no Azure e no Kubernetes autogerido. No GKE, Google Cloud faz a gestão do Workload Identity Pool e do fornecedor por si e não requer um fornecedor de identidade externo.
Como funciona a federação de identidade da carga de trabalho para o GKE
Quando ativa a federação de identidade da carga de trabalho para o GKE num cluster, o GKE faz o seguinte:
Cria um Workload Identity Pool fixo para o projeto do cluster com o seguinte formato: Google Cloud
PROJECT_ID.svc.id.googO Workload Identity Pool fornece um formato de nomenclatura que permite ao IAM compreender e confiar nas credenciais do Kubernetes. O GKE não elimina este pool de identidades de carga de trabalho, mesmo que elimine todos os clusters no seu projeto.
Regista o cluster do GKE como um fornecedor de identidade no Workload Identity Pool.
Implementa o servidor de metadados do GKE, que interceta pedidos de credenciais de cargas de trabalho, em todos os nós.
Crie políticas de autorização da IAM em Google Cloud recursos
Para conceder acesso com a federação de identidade da carga de trabalho para o GKE, cria uma política de autorização do IAM que concede acesso a um Google Cloud recurso Google Cloud específico a um principal que corresponde à identidade da sua aplicação. Por exemplo, pode conceder autorizações de leitura num contentor do Cloud Storage a todos os pods que usam a database-reader conta de serviço do Kubernetes.
Para ver uma lista de recursos que suportam políticas de permissão, consulte o artigo Tipos de recursos que aceitam políticas de permissão.
Use condições em políticas de IAM
Também pode limitar o âmbito do acesso definindo condições nas suas políticas de autorização. As condições são um método extensível de especificar quando uma política de autorização deve ser aplicada. Por exemplo, pode usar condições para conceder acesso temporário a uma carga de trabalho num recurso específico, eliminando a necessidade de gerir esse acesso manualmente. Google Cloud
As condições também podem ser úteis se definir as suas políticas de autorização ao nível do projeto, da pasta ou da organização, em vez de em recursos específicos, como segredos do Secret Manager ou contentores do Cloud Storage.
Para adicionar uma condição à sua política de autorização, use os seguintes recursos:
- Gerir associações de funções condicionais: adicione, modifique ou remova associações de funções condicionais.
- Configure o acesso temporário: use condições para definir o acesso com data de validade aos recursos nas políticas de autorização. Google Cloud
- Etiquetas e acesso condicional: use condições para aplicar políticas de permissão apenas quando os recursos tiverem etiquetas específicas.
As expressões de exemplo seguintes destinam-se a cenários comuns nos quais pode usar condições. Para ver uma lista dos atributos disponíveis em expressões, consulte a referência de atributos para condições da IAM.
| Exemplos de expressões de condições | ||
|---|---|---|
| Permita o acesso antes da hora especificada | request.time < timestamp('Substitua |
|
| Permitir o acesso se o recurso no pedido tiver a etiqueta especificada | resource.matchTag('Substitua o seguinte:
|
|
Referencie recursos do Kubernetes em políticas de IAM
Na sua política de IAM, refere-se a um recurso do Kubernetes através de um identificador principal do IAM para selecionar o recurso. Este 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: tem de serprincipalouprincipalSet, consoante o recurso que selecionar.principaldestina-se a um recurso específico, como uma única ServiceAccount.principalSetdestina-se a vários recursos que pertencem ao recurso especificado, como todos os pods num cluster específico.SELECTOR: uma string que seleciona um tipo de principal. Por exemplo,kubernetes.serviceaccount.uid/SERVICEACCOUNT_UIDseleciona uma ServiceAccount pelo respetivo UID.
A tabela seguinte mostra os tipos de principais suportados no GKE:
| Tipo de identificador principal | Sintaxe |
|---|---|
| Todos os agrupamentos que usam uma conta de serviço do Kubernetes específica | Selecione a ServiceAccount por nome:
principal://iam.googleapis.com/projects/Substitua o seguinte:
Selecione a conta de serviço por UID: principal://iam.googleapis.com/projects/Substitua o seguinte:
|
| Todos os pods num espaço de nomes, 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 o seguinte:
|
| Todos os pods num 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 o seguinte:
|
Fluxo de credenciais
Quando uma carga de trabalho envia um pedido para aceder a uma Google Cloud API, por exemplo, quando usa uma Google Cloud biblioteca cliente, ocorrem os seguintes passos de autenticação:
- As credenciais predefinidas da aplicação (ADC) pedem um Google Cloud token de acesso ao servidor de metadados do Compute Engine que é executado na VM.
- O servidor de metadados do GKE interceta o pedido de token e pede ao servidor da API Kubernetes um token ServiceAccount do Kubernetes que identifica a carga de trabalho que está a fazer o pedido. Esta credencial é um símbolo da Web JSON (JWT) assinado pelo servidor da API.
- O servidor de metadados do GKE usa o Security Token Service 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 devolvido pelo serviço de tokens de segurança pode ter limitações quando tenta aceder a alguns Google Cloud serviços, conforme descrito em Produtos suportados e limitações. Se o Google Cloud serviço selecionado tiver limitações, pode, opcionalmente, configurar a representação da conta de serviço. Este método resulta num token de acesso para uma conta de serviço de IAM que a sua carga de trabalho pode usar para aceder ao serviço de destino. Para ver detalhes, consulte o artigo Associe contas de serviço do Kubernetes ao IAM.
Em seguida, a carga de trabalho pode aceder a quaisquer Google Cloud APIs a que o identificador principal do IAM da carga de trabalho possa aceder.
Quota para a API Exchange Token no Security Token Service
A API Exchange Token no serviço de tokens de segurança tem um limite de quota
de 6000 pedidos por minuto. Se vir QUOTA_EXCEEDED erros, pode
pedir um aumento da quota Token exchange requests per minute através
da página Quotas e limites do sistema.
Identidade igual
Se os metadados no identificador principal forem os mesmos para cargas de trabalho em vários clusters que partilham um Workload Identity Pool porque pertencem ao mesmo projeto, o IAM identifica essas cargas de trabalho como as mesmas. Google Cloud Por exemplo, se tiver o mesmo espaço de nomes em dois clusters e conceder acesso a esse espaço de nomes na IAM, as cargas de trabalho nesse espaço de nomes em ambos os clusters recebem esse acesso. Pode limitar este acesso a clusters específicos através de políticas de IAM condicionais.
Por exemplo, considere o seguinte diagrama. Os clusters A e B pertencem ao mesmo Workload Identity Pool.O Google Cloud identifica as aplicações que usam a back-ksa ServiceAccount no espaço de nomes backend do cluster A e do cluster B como a mesma identidade. O IAM não distingue os clusters que fazem as chamadas.
Esta igualdade de identidade também significa que tem de poder confiar em todos os clusters
num Workload Identity Pool específico. Por exemplo, se um novo cluster, o cluster C, no exemplo anterior, fosse propriedade de uma equipa não fidedigna, esta poderia criar um espaço de nomes backend Google Cloud e aceder às APIs através da back-ksa conta de serviço, tal como o cluster A e o cluster B.
Para evitar o acesso não fidedigno, coloque os clusters em projetos separados para garantir que recebem conjuntos de identidades do Workload Identity diferentes ou certifique-se de que os nomes dos espaços de nomes são distintos entre si para evitar um identificador principal comum.
Servidor de metadados do GKE
Cada nó num GKE com a Workload Identity Federation para GKE ativada armazena os respetivos metadados no servidor de metadados do GKE. O servidor de metadados do GKE é um subconjunto dos pontos finais do servidor de metadados do Compute Engine necessários para cargas de trabalho do Kubernetes.
O servidor de metadados do GKE é executado como um DaemonSet, com um pod em cada nó Linux ou um serviço Windows nativo em cada nó Windows no cluster. O servidor de metadados interceta pedidos HTTP para http://metadata.google.internal
(169.254.169.254:80). Por exemplo, o pedido GET
/computeMetadata/v1/instance/service-accounts/default/token obtém um token para a conta de serviço do IAM que o pod está configurado para se fazer passar por.
O tráfego para o servidor de metadados do GKE nunca sai da instância de VM que aloja o pod.
Tempo de vida do token
Por predefinição, o token de acesso devolvido tem uma duração de 1 hora (3600 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 devolvido pelo servidor de metadados pode estar perto da respetiva data de validade.
As bibliotecas cliente da nuvem têm uma lógica incorporada que, por predefiniçã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 atualiza o token. As chamadas API consecutivas podem usar o token atualizado.
Se usar o seu próprio código para aceder diretamente às Google Cloud APIs, implemente uma lógica semelhante para processar a expiração do token. O seu código deve fazer o seguinte:
- Verifique se o token de acesso expira após um período de 3 minutos e 45 segundos. O parâmetro
expna carga útil do token indica a data/hora de expiração do token. - Se o token estiver definido para expirar nos próximos 3 minutos e 45 segundos, faça um pedido de token.
As tabelas seguintes descrevem o subconjunto de pontos finais do servidor de metadados do Compute Engine disponíveis com o servidor de metadados do GKE. Para ver uma lista completa dos pontos finais disponíveis no servidor de metadados do Compute Engine, consulte os valores de metadados da VM predefinidos.
Metadados da instância
Os metadados de instância são armazenados no seguinte diretório.
http://metadata.google.internal/computeMetadata/v1/instance/
| Entrada | Descrição |
|---|---|
hostname |
O nome do anfitrião do seu nó. |
id |
O ID exclusivo do seu nó. |
service-accounts/ |
Um diretório de contas de serviço associadas ao nó. Para cada conta de serviço, estão disponíveis as seguintes informações:
|
zone |
A zona do Compute Engine do seu nó do GKE. |
Atributos da instância
Os atributos de 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 seu cluster. |
cluster-name |
O nome do seu cluster do GKE. |
cluster-uid |
O UID do seu cluster do GKE. |
Os atributos apresentados na tabela são os únicos atributos suportados. Se tentar aceder a atributos não suportados, o gke-metadata-server Pod no espaço de nomes kube-system gera e regista um erro 404.
O erro é semelhante ao seguinte:
HTTP/404: generic::not_found: no child "", Reason: "NOT_FOUND", UserMessage: "Not Found"
Se estiver a usar o istio-proxy, é apresentada uma mensagem de erro semelhante à seguinte:
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 seguinte diretório.
http://metadata.google.internal/computeMetadata/v1/project/
| Entrada | Descrição |
|---|---|
project-id |
O seu Google Cloud ID do projeto. |
numeric-project-id |
O número do seu Google Cloud projeto. |
Restrições da federação de identidades de cargas de trabalho para o GKE
Não pode alterar o nome do Workload Identity Pool que o GKE cria para o seu Google Cloud projeto.
Quando o GKE ativa o servidor de metadados do GKE num conjunto de nós, os pods já não podem aceder ao servidor de metadados do Compute Engine. Em alternativa, o servidor de metadados do GKE interceta os pedidos feitos a partir destes pods para pontos finais de metadados, com exceção dos pods em execução na rede do anfitrião.
Quando usar o controlador CSI FUSE do Cloud Storage com clusters GKE padrão com a versão
1.33.3-gke.1226000ou posterior, os pods executados na rede do anfitrião (hostNetwork: true) podem autenticar-se através da respetiva conta de serviço do Kubernetes. Para mais informações, consulte o artigo Configure o acesso para pods com rede de anfitrião.O servidor de metadados do GKE demora alguns segundos a começar a aceitar pedidos num pod criado recentemente. Por conseguinte, as tentativas de autenticação através da Workload Identity Federation para o GKE nos primeiros segundos da vida de um pod podem falhar. Tentar novamente a chamada resolve o problema. Consulte o artigo Resolução de problemas para ver mais detalhes.
Os agentes de registo e monitorização integrados do GKE continuam a usar a conta de serviço do nó.
A Workload Identity Federation para o GKE requer uma configuração manual para o Knative Serving para continuar a lançar métricas de pedidos.
A Workload Identity Federation para o GKE define um limite de 500 ligações simultâneas ao servidor de metadados do GKE para cada nó. As chamadas simultâneas adicionais que excedam este limite são colocadas numa fila de espera para processamento posterior. Este mecanismo de colocação em fila pode originar erros
HTTP/499se o limite de tempo do cliente for atingido antes de o servidor de metadados do GKE poder processar o pedido.A Workload Identity Federation para GKE para nós do Windows Server está disponível nas versões 1.18.16-gke.1200, 1.19.8-gke.1300, 1.20.4-gke.1500 e posteriores do GKE.
O servidor de metadados do GKE usa recursos de memória proporcionais ao número total de contas de serviço do Kubernetes no seu cluster. Se o seu cluster tiver mais de 3000 contas de serviço do Kubernetes, o kubelet pode terminar os pods do servidor de metadados. Para mitigações, consulte a secção Resolução de problemas.
A Workload Identity Federation para o GKE funciona dentro de um perímetro dos VPC Service Controls, o que permite o acesso a recursos dentro do mesmo. No entanto, os VPC Service Controls não aplicam o controlo de acesso a pedidos entre perímetros com base nestas identidades federadas. Pode usar a representação da conta de serviço para aceder a recursos num perímetro diferente.
Alternativas à federação de identidades da carga de trabalho para o GKE
Pode usar uma das seguintes alternativas à Workload Identity Federation para o GKE para aceder às Google Cloud APIs a partir do GKE. Recomendamos que use a Workload Identity Federation para o GKE, porque estas alternativas exigem que faça determinados compromissos de segurança.
Usar a conta de serviço predefinida do Compute Engine dos seus nós. Pode executar pools de nós como qualquer conta de serviço do IAM no seu projeto. Se não especificar uma conta de serviço durante a criação do conjunto de nós, o GKE usa a conta de serviço predefinida do Compute Engine para o projeto. A conta de serviço do Compute Engine é partilhada por todas as cargas de trabalho implementadas nesse nó. Isto pode resultar no aprovisionamento excessivo de autorizações, o que viola o princípio do menor privilégio e é inadequado para clusters multi-inquilinos.
Exporte as chaves da conta de serviço e armazene-as como segredos do Kubernetes que monta nos seus pods como volumes.
O que se segue?
- Saiba como ativar e configurar a Workload Identity Federation para o GKE.
- Saiba mais acerca do servidor de metadados do Compute Engine.