Usar identidade da carga de trabalho

Neste documento, mostramos como ativar e configurar a Identidade da carga de trabalho nos clusters do Google Kubernetes Engine (GKE). A Identidade da carga de trabalho permite que as cargas de trabalho nos clusters do GKE representem contas de serviço de gerenciamento de identidade e acesso (IAM) para acessar serviços do Google Cloud. A Identidade da carga de trabalho é ativada por padrão nos clusters do Autopilot.

Para saber mais sobre como a Identidade da carga de trabalho funciona, consulte Identidade da carga de trabalho.

Limitações

  • O GKE cria um pool de identidades de carga de trabalho fixo para cada projeto do Google Cloud, com o formato PROJECT_ID.svc.id.goog.

  • A Identidade de carga de trabalho substitui a necessidade de usar Ocultação de metadados. Os metadados confidenciais protegidos pela ocultação de metadados também são protegidos pela Identidade da carga de trabalho.

  • 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.

  • A Identidade da carga de trabalho não pode ser usada por pods em execução na rede do host. As solicitações feitas desses pods para endpoints de metadados são encaminhadas para o servidor de metadados do Compute Engine.

  • 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 Identidade da carga de trabalho nos primeiros segundos da vida de um pod podem falhar. Tentar novamente a chamada resolverá o problema. Para mais informações, consulte a seção de solução de problemas abaixo.

  • Os agentes integrados de geração de registros e monitoramento do GKE continuarão a usar a conta de serviço do nó.

  • A Identidade da carga de trabalho requer a configuração manual para que o Cloud Run para Anthos continue lançando métricas de solicitação.

  • A Identidade da carga de trabalho instalará ip-masq-agent se o cluster for criado sem a sinalização --disable-default-snat.

  • A Identidade da carga de trabalho define um limite de 200 conexões com o servidor de metadados do GKE para cada nó, a fim de evitar problemas de memória. Expirações de tempo limite podem acontecer se os nós excederem esse limite.

  • A 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.

Antes de começar

Antes de começar, veja se você realizou as seguintes tarefas:

  • Veja se você ativou a API do Google Kubernetes Engine.
  • Ativar a API Google Kubernetes Engine
  • Confirme se você instalou a Google Cloud CLI.
  • Defina as configurações padrão da Google Cloud CLI para o projeto usando um dos seguintes métodos:
    • Use gcloud init se quiser orientações para definir os padrões do projeto.
    • Use gcloud config para definir individualmente a região, a zona e o ID do projeto.

    gcloud init

    1. Execute gcloud init e siga as instruções:

      gcloud init

      Se você estiver usando SSH em um servidor remoto, utilize a sinalização --console-only para impedir que o comando inicie um navegador:

      gcloud init --console-only
    2. Siga as instruções para autorizar a CLI gcloud a usar a conta do Google Cloud.
    3. Crie uma nova configuração ou selecione uma atual.
    4. Escolha um projeto do Google Cloud.
    5. Escolha uma zona padrão do Compute Engine.
    6. Escolha uma região padrão do Compute Engine.
    .

    gcloud config

    1. Defina o ID do projeto padrão:
      gcloud config set project PROJECT_ID
    2. Defina a região padrão do Compute Engine (por exemplo, us-central1):
      gcloud config set compute/region COMPUTE_REGION
    3. Defina a zona padrão do Compute Engine (por exemplo, us-central1-c):
      gcloud config set compute/zone COMPUTE_ZONE
    4. Atualize gcloud para a versão mais recente:
      gcloud components update
    .

    Ao definir locais padrão, é possível evitar erros na CLI gcloud, como: One of [--zone, --region] must be supplied: Please specify location.

Ativar a Identidade da carga de trabalho

É possível ativar a identidade da carga de trabalho em clusters e pools de nós usando a Google Cloud CLI ou o Console do Google Cloud.

A Identidade da carga de trabalho precisa estar ativada no nível do cluster para que seja possível ativá-la em pools de nós.

Criar um novo cluster

É possível ativar a Identidade da carga de trabalho em um novo cluster Standard usando a CLI gcloud ou o Console do Cloud.

gcloud

Para ativar a Identidade da carga de trabalho em um novo cluster, execute o seguinte comando:

gcloud container clusters create CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --workload-pool=PROJECT_ID.svc.id.goog

Substitua:

  • CLUSTER_NAME: o nome do novo cluster;
  • COMPUTE_REGION: a região do Compute Engine do cluster. Para clusters zonais, use --zone=COMPUTE_ZONE.
  • PROJECT_ID: é seu ID do projeto no Google Cloud.

Console

Para ativar a identidade da carga de trabalho em um novo cluster, faça o seguinte:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud:

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Na caixa de diálogo Criar cluster do GKE Standard, clique em Configurar.

  4. No menu de navegação, na seção Cluster, clique em Segurança.

  5. Marque a caixa de seleção Ativar identidade de carga de trabalho.

  6. Continue configurando o cluster e clique em Criar.

Atualizar um cluster atual

É possível ativar a Identidade da carga de trabalho em um cluster Standard usando a CLI gcloud ou o Console do Cloud. Pools de nós existentes não são afetados, mas todos os pools de nós novos no cluster usam a Identidade da carga de trabalho.

gcloud

Para ativar a Identidade da carga de trabalho em um cluster existente, execute o seguinte comando:

gcloud container clusters update CLUSTER_NAME \
    --region=COMPUTE_REGION \
    --workload-pool=PROJECT_ID.svc.id.goog

Substitua:

  • CLUSTER_NAME: o nome do cluster atual.
  • COMPUTE_REGION: a região do Compute Engine do cluster. Para clusters zonais, use --zone=COMPUTE_ZONE.
  • PROJECT_ID: é seu ID do projeto no Google Cloud.

Console

Para ativar a Identidade da carga de trabalho em um cluster, faça o seguinte:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Na página de detalhes do cluster, na seção Segurança, clique em Editar Identidade da carga de trabalho.

  4. Na caixa de diálogo Editar Identidade da carga de trabalho, marque a caixa de seleção Ativar Identidade da carga de trabalho.

  5. Clique em Save changes.

Migrar cargas de trabalho para a Identidade da carga de trabalho

Depois de ativar a Identidade da carga de trabalho em um cluster existente, convém migrar as cargas de trabalho em execução para usar a Identidade da carga de trabalho. Selecione a estratégia de migração ideal para seu ambiente. É possível criar novos pools de nós com a Identidade da carga de trabalho ativada ou atualizar os pools de nós existentes para ativar a Identidade da carga de trabalho.

Recomendamos a criação de novos pools de nós se você também precisar modificar os aplicativos para que sejam compatíveis com a Identidade da carga de trabalho.

Todos os pools de nós novos criados assumem como padrão usar a Identidade da carga de trabalho caso o cluster tenha esse recurso ativado. Para criar um novo pool de nós com a Identidade da carga de trabalho ativada, execute o seguinte comando:

gcloud container node-pools create NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

Substitua:

  • NODEPOOL_NAME: o nome do novo pool de nós.
  • CLUSTER_NAME: o nome do cluster atual que tem a Identidade da carga de trabalho ativada.

A sinalização --workload-metadata=GKE_METADATA configura o pool de nós para usar o servidor de metadados do GKE. Recomendamos incluir a sinalização para que a criação do pool de nós falhe caso a Identidade da carga de trabalho não esteja ativada no cluster.

Atualizar um pool de nós

É possível ativar manualmente a Identidade da carga de trabalho em pools de nós existentes depois de ativá-la no cluster.

gcloud

Para modificar um pool de nós para usar a Identidade da carga de trabalho, execute o seguinte comando:

gcloud container node-pools update NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --workload-metadata=GKE_METADATA

Se um cluster tiver a identidade de carga de trabalho ativada, será possível desativá-la seletivamente em um pool de nós especificando explicitamente --workload-metadata=GCE_METADATA. Consulte Como proteger os metadados do cluster para mais informações.

Console

Para modificar um pool de nós para usar a Identidade da carga de trabalho, execute as seguintes etapas:

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Clique na guia Nós.

  4. Na seção Pool de nós, clique no nome do pool de nós que você quer redimensionar.

  5. Na página Detalhes do pool de nós, clique em Editar.

  6. Na página Editar pool de nós, na seção Segurança, marque a caixa de seleção Ativar servidor de metadados do GKE.

  7. Clique em Save.

Configurar aplicativos para usar a Identidade da carga de trabalho

Depois de ativar a Identidade da carga de trabalho, configure os aplicativos para autenticar no Google Cloud usando a Identidade da carga de trabalho antes de migrar os aplicativos para os novos pools de nós.

Atribua uma conta de serviço do Kubernetes ao aplicativo e configure-a para atuar como uma conta de serviço do IAM.

As etapas a seguir mostram como configurar seus aplicativos para usar a Identidade da carga de trabalho, se ela estiver ativada no cluster.

  1. Receba as credenciais do cluster:

    gcloud container clusters get-credentials CLUSTER_NAME
    

    Substitua CLUSTER_NAME pelo nome do cluster que tem a Identidade da carga de trabalho ativada.

  2. Crie o namespace que será usado para a conta de serviço do Kubernetes. Também é possível usar o namespace padrão ou qualquer namespace existente.

    kubectl create namespace NAMESPACE
    
  3. Crie uma conta de serviço do Google para o aplicativo usar: Também é possível usar a conta de serviço padrão do Kubernetes no namespace padrão ou em qualquer outro existente.

    kubectl create serviceaccount KSA_NAME \
        --namespace NAMESPACE
    

    Substitua:

    • KSA_NAME: o nome da nova conta de serviço do Kubernetes.
    • NAMESPACE, o nome do namespace do Kubernetes da conta de serviço.
  4. Crie uma conta de serviço do IAM para seu aplicativo ou use uma conta de serviço do IAM atual. É possível usar qualquer conta de serviço do Google em qualquer projeto na organização. Para o Config Connector, aplique o objeto IAMServiceAccount à conta de serviço escolhida.

    gcloud

    Para criar uma nova conta de serviço de IAM usando a CLI gcloud, execute o comando a seguir.

    gcloud iam service-accounts create GSA_NAME \
        --project=GSA_PROJECT
    

    Substitua:

    • GSA_NAME: o nome da nova conta de serviço do IAM.
    • GSA_PROJECT, o ID do projeto do Google Cloud da conta de serviço do IAM.

    Config Connector

    Para usar uma conta de serviço do Google nova ou existente com o Config Connector, aplique o arquivo de configuração a seguir.

    Observação: esta etapa requer o Config Connector. Siga estas instruções para instalar o Config Connector no cluster.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMServiceAccount
    metadata:
      name: [GSA_NAME]
    spec:
      displayName: [DISPLAY_NAME]
    Para implantar esse manifesto, faça o download dele para sua máquina como service-account.yaml.

    Use kubectl para aplicar o manifesto:

    kubectl apply -f service-account.yaml
    

    Para ver informações sobre como autorizar contas de serviço do Google a acessar as APIs do Google Cloud, consulte Como entender as contas de serviço.

  5. Verifique se a conta de serviço do IAM tem os papéis necessários. É possível conceder outros papéis usando o seguinte comando:

    gcloud projects add-iam-policy-binding PROJECT_ID \
        --member "serviceAccount:GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com" \
        --role "ROLE_NAME"
    

    Substitua:

    • PROJECT_ID: é seu ID do projeto no Google Cloud.
    • GSA_NAME: o nome da conta de serviço do IAM.
    • GSA_PROJECT, o ID do projeto do Google Cloud da conta de serviço do IAM.
    • ROLE_NAME: o papel do IAM a ser atribuído à conta de serviço, como roles/spanner.viewer.
  6. Permita que a conta de serviço do Kubernetes atue como a conta de serviço do IAM. Para isso, adicione uma vinculação de política do IAM entre as duas contas de serviço. Essa vinculação permite que a conta de serviço do Kubernetes atue como a conta de serviço do Google.

    gcloud

    gcloud iam service-accounts add-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
    

    Config Connector

    Observação: esta etapa requer o Config Connector. Siga estas instruções para instalar o Config Connector no cluster.

    apiVersion: iam.cnrm.cloud.google.com/v1beta1
    kind: IAMPolicy
    metadata:
      name: iampolicy-workload-identity-sample
    spec:
      resourceRef:
        apiVersion: iam.cnrm.cloud.google.com/v1beta1
        kind: IAMServiceAccount
        name: [GSA_NAME]
      bindings:
        - role: roles/iam.workloadIdentityUser
          members:
            - serviceAccount:[PROJECT_ID].svc.id.goog[[K8S_NAMESPACE]/[KSA_NAME]]
    Para implantar esse manifesto, faça o download dele para sua máquina como policy-binding.yaml. Substitua GSA_NAME, PROJECT_ID NAMESPACE e KSA_NAME pelos valores correspondentes do seu ambiente. Depois, execute:

    kubectl apply -f policy-binding.yaml
    
  7. Anote a conta de serviço do Kubernetes com o endereço de e-mail da conta de serviço do IAM.

    kubectl

    kubectl annotate serviceaccount KSA_NAME \
        --namespace NAMESPACE \
        iam.gke.io/gcp-service-account=GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
    

    yaml

    apiVersion: v1
    kind: ServiceAccount
    metadata:
      annotations:
        iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
      name: KSA_NAME
      namespace: NAMESPACE
    
  8. Atualize a especificação do pod para programar as cargas de trabalho em nós que usam a Identidade da carga de trabalho e usar a conta de serviço do Kubernetes com anotação.

    spec:
      serviceAccountName: KSA_NAME
      nodeSelector:
        iam.gke.io/gke-metadata-server-enabled: "true"
    
  9. Aplique a configuração atualizada ao cluster:

    kubectl apply -f DEPLOYMENT_FILE
    

    Substitua DEPLOYMENT_FILE pelo caminho para a especificação de pod atualizada.

Verificar a configuração da Identidade da carga de trabalho

Verifique se as contas de serviço estão configuradas corretamente. Para isso, crie um pod com a conta de serviço do Kubernetes que executa a imagem do contêiner específico do SO e conecte-se a ele com uma sessão interativa.

Linux

Crie um pod que use a conta de serviço do Kubernetes anotada, e curl o endpoint service-accounts.

  1. Salve a configuração a seguir como wi-test.yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: workload-identity-test
      namespace: NAMESPACE
    spec:
      containers:
      - image: google/cloud-sdk:slim
        name: workload-identity-test
        command: ["sleep","infinity"]
      serviceAccountName: KSA_NAME
      nodeSelector:
        iam.gke.io/gke-metadata-server-enabled: "true"
    

    A imagem google/cloud-sdk inclui a Google Cloud CLI, que é uma maneira conveniente de consumir as APIs Google Cloud. Pode levar algum tempo para fazer o download da imagem.

  2. Crie o pod:

    kubectl apply -f wi-test.yaml
    
  3. Abra uma sessão interativa no pod:

    kubectl exec -it workload-identity-test \
      --namespace NAMESPACE \
      -- /bin/bash
    
  4. Execute o seguinte comando no pod:

    curl -H "Metadata-Flavor: Google" http://169.254.169.254/computeMetadata/v1/instance/service-accounts/
    

    Se as contas de serviço estiverem configuradas corretamente, o endereço de e-mail da conta de serviço do Google será listado como a identidade ativa (e única). Isso demonstra que, por padrão, o pod atua como a autoridade da conta de serviço do IAM ao chamar as APIs do Google Cloud.

Windows

Crie um pod com a conta de serviço do Kubernetes que executa a imagem do contêiner servercore:

  1. Salve o seguinte manifesto:

    apiVersion: v1
    kind: Pod
    metadata:
      name: workload-identity-test
      namespace: NAMESPACE
    spec:
      containers:
      - image: IMAGE_NAME
        name: workload-identity-test
        command: ["powershell.exe", "sleep", "3600"]
      serviceAccountName: KSA_NAME
      nodeSelector:
        kubernetes.io/os: windows
        cloud.google.com/gke-os-distribution: windows_ltsc
        iam.gke.io/gke-metadata-server-enabled: "true"
    

    Substitua IMAGE_NAME por um dos seguintes valores de imagem do núcleo do servidor de contêiner:

    Imagem do nó do Windows Server Imagem de contêiner servercore
    WINDOWS_LTSC,
    WINDOWS_LTSC_CONTAINERD
    mcr.microsoft.com/windows/servercore:ltsc2019
    WINDOWS_SAC,
    WINDOWS_SAC_CONTAINERD
    Verifique o mapeamento de versões entre a versão do nó do GKE e a versão do Windows SAC. Para o Windows Server versão 1909, especifique mcr.microsoft.com/windows/servercore:1909. Caso contrário, especifique mcr.microsoft.com/windows/servercore:20H2.
  2. Abra uma sessão interativa no pod:

    kubectl exec -it workload-identity-test \
      --namespace NAMESPACE -- powershell
    
  3. Execute o seguinte comando powershell no pod:

    Invoke-WebRequest  -Headers @{"Metadata-Flavor"="Google"} -Uri  http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/email  -UseBasicParsing
    

    Se as contas de serviço estiverem configuradas corretamente, o endereço de e-mail da conta de serviço do Google será listado como a identidade ativa (e única). Isso demonstra que, por padrão, o pod usa a autoridade da conta de serviço do Google ao chamar APIs Google Cloud.

Usar a Identidade da carga de trabalho do código

A autenticação nos serviços do Google Cloud usando o código segue o mesmo processo que a autenticação usando o servidor de metadados do Compute Engine. Quando você usa a Identidade da carga de trabalho, suas solicitações para o servidor de metadados da instância são encaminhadas para o servidor de metadados do GKE. O código atual que autentica usando o servidor de metadados da instância (como o código que usa as bibliotecas de cliente do Google Cloud) funcionará sem precisar de modificações.

Limpar

Para interromper o uso da Identidade da carga de trabalho, revogue o acesso à conta de serviço do IAM e desative a Identidade da carga de trabalho no cluster.

Revogar acesso

  1. Revogue o acesso à conta de serviço do IAM:

    gcloud

    gcloud iam service-accounts remove-iam-policy-binding GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"
    

    Substitua:

    • PROJECT_ID, o ID do projeto do cluster do GKE;
    • NAMESPACE, o nome do namespace do Kubernetes em que a conta de serviço do Kubernetes está localizada;
    • KSA_NAME, o nome da conta de serviço do Kubernetes que terá o acesso revogado;
    • GSA_NAME: o nome da conta de serviço do IAM.
    • GSA_PROJECT, o ID do projeto da conta de serviço do IAM.

    Config Connector

    Se você usou o Config Connector para criar a conta de serviço, exclua-a com kubectl.

    kubectl delete -f service-account.yaml
    

    Pode levar até 30 minutos para que os tokens em cache expirem. É possível verificar se os tokens em cache já expiraram com este comando:

    gcloud auth list
    

    Os tokens em cache expiram se a saída desse comando não incluir mais GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com.

  2. Remova a anotação da conta de serviço do Kubernetes. Esta etapa é opcional porque o acesso foi revogado pelo IAM.

    kubectl annotate serviceaccount KSA_NAME \
        --namespace NAMESPACE iam.gke.io/gcp-service-account-
    

Desativar a Identidade da carga de trabalho

Só é possível desativar a Identidade da carga de trabalho nos clusters do GKE Standard.

gcloud

  1. Desative a Identidade da carga de trabalho em cada pool de nós:

    gcloud container node-pools update NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --workload-metadata=GCE_METADATA
    

    Repita esse comando em cada pool de nós no cluster.

  2. Desative a identidade de carga de trabalho no cluster:

    gcloud container clusters update CLUSTER_NAME \
        --disable-workload-identity
    

Console

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

  2. Na lista de clusters, clique no nome do cluster que você quer modificar.

  3. Clique na guia Nós.

  4. Para desativar a Identidade da carga de trabalho em cada pool de nós, faça o seguinte para cada pool de nós na seção Pools de nós:

    1. Clique no nome do pool de nós que você quer modificar.
    2. Na página Detalhes do pool de nós, clique em Editar.
    3. Na página Editar pool de nós, na seção Segurança, desmarque a caixa de seleção Ativar servidor de metadados do GKE.
    4. Clique em Save.
  5. Para desativar a identidade da carga de trabalho para o cluster, faça o seguinte:

    1. Clique na guia Details.
    2. Na seção Segurança, ao lado de Identidade da carga de trabalho, clique em Editar.
    3. Na caixa de diálogo Editar Identidade da carga de trabalho, desmarque a caixa de seleção Ativar Identidade da carga de trabalho.
    4. Clique em Save changes.

Desativar a Identidade da carga de trabalho na organização

Do ponto de vista da segurança, a Identidade da carga de trabalho permite que o GKE declare identidades das contas de serviço do Kubernetes que podem ser autenticadas e autorizadas nos recursos do Google Cloud. Se você é um administrador que realizou ações para isolar cargas de trabalho de recursos do Google Cloud, como desativar a criação de contas de serviço ou desativar a criação de chave da conta de serviço, talvez também queira desativar a Identidade da carga de trabalho para sua organização.

Consulte estas instruções para desativar a Identidade da carga de trabalho na sua organização.

Solução de problemas

O pod não pode se autenticar no Google Cloud

Se não for possível autenticar seu aplicativo no Google Cloud, confira se as seguintes configurações estão corretas:

  1. Verifique se você ativou a API Service Account Credentials do IAM no projeto que contém o cluster do GKE.

    Ativar a API IAM Credentials

  2. Garanta que a Identidade da carga de trabalho esteja ativada no cluster. Para isso, verifique se ela tem um pool definido de Identidade da carga de trabalho:

    gcloud container clusters describe CLUSTER_NAME \
        --format="value(workloadIdentityConfig.workloadPool)"
    

    Se você ainda não tiver especificado uma zona ou região padrão para gcloud, talvez seja necessário especificar uma sinalização --region ou --zone ao executar este comando.

  3. Verifique se o servidor de metadados do GKE está configurado no pool de nós em que o aplicativo está em execução:

    gcloud container node-pools describe NODEPOOL_NAME \
        --cluster=CLUSTER_NAME \
        --format="value(config.workloadMetadataConfig.mode)"
    
  4. Confira se a conta de serviço do Kubernetes está anotada corretamente:

    kubectl describe serviceaccount \
        --namespace NAMESPACE KSA_NAME
    

    A saída contém uma anotação semelhante a esta:

    iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    
  5. Verifique se a conta de serviço do Google está configurada corretamente:

    gcloud iam service-accounts get-iam-policy \
        GSA_NAME@GSA_PROJECT.iam.gserviceaccount.com
    

    A saída contém uma vinculação semelhante a esta:

    - members:
      - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]
      role: roles/iam.workloadIdentityUser
    
  6. Se você tiver uma política de rede de cluster, permita que a saída seja permitida para 127.0.0.1/32 na porta 988 para clusters que executam versões do GKE anteriores a 1.21.0-gke.1.000 ou 169.254.169.252/32 na porta 988 para clusters que executam o GKE versão 1.21.0-gke.1000 e posterior

    kubectl describe networkpolicy NETWORK_POLICY_NAME
    

Erros de tempo limite na inicialização do pod

O servidor de metadados do GKE precisa de alguns segundos para começar a aceitar solicitações em um novo pod. Portanto, as tentativas de autenticação que usam a Identidade da carga de trabalho nos primeiros segundos da vida de um pod podem falhar em aplicativos e nas bibliotecas de cliente do Google Cloud configuradas com um tempo limite curto.

Se você encontrar erros de tempo limite, altere o código do aplicativo para aguardar alguns segundos e tentar novamente. Como alternativa, é possível implantar um initContainer que aguarda até que o servidor de metadados do GKE esteja pronto antes de executar o contêiner principal do pod.

Por exemplo, o seguinte manifesto é para um pod com initContainer:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-initcontainer
spec:
  serviceAccountName: KSA_NAME
  initContainers:
  - image:  gcr.io/google.com/cloudsdktool/cloud-sdk:326.0.0-alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -s -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 30 > /dev/null || exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

A identidade da carga de trabalho falha devido à indisponibilidade do plano de controle

O servidor de metadados não pode retornar a identidade da carga de trabalho quando o plano de controle do cluster não está disponível. As chamadas para o servidor de metadados retornam o código de status 500.

A entrada de registro pode ser semelhante a esta no Explorador de registros:

dial tcp 35.232.136.58:443: connect: connection refused

Isso levará à indisponibilidade esperada da Identidade da carga de trabalho.

O plano de controle pode estar indisponível em clusters zonais na manutenção do cluster, como rotação de IPs, upgrade de VMs do plano de controle ou redimensionamento de clusters ou pools de nós. Saiba mais sobre como escolher um plano de controle regional ou zonal para saber mais sobre a disponibilidade do plano de controle. Mudar para o cluster regional eliminará esse problema.

Falha na identidade da carga de trabalho

Se o servidor de metadados do GKE for bloqueado por qualquer motivo, a identidade da carga de trabalho falhará.

Se você estiver usando o Istio, adicione a seguinte anotação no nível do aplicativo a todas as cargas de trabalho que usam a Identidade da carga de trabalho:

"traffic.sidecar.istio.io/excludeOutboundIPRanges=169.254.169.254/32"

Se preferir, altere a chave global.proxy.excludeIPRanges Istio ConfigMap para fazer o mesmo.

A seguir