Resolver problemas de autenticação do GKE

Nesta página, mostramos como resolver problemas relacionados a configurações de segurança nos clusters do Autopilot e do Standard do Google Kubernetes Engine (GKE).

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

RBAC e IAM

Contas do IAM autenticadas não realizam ações no cluster

O problema a seguir ocorre quando você tenta executar uma ação no cluster, mas o GKE não consegue encontrar uma política de RBAC que autorize a ação. O GKE tenta encontrar uma política do IAM que conceda a mesma permissão. Se isso falhar, você encontrará uma mensagem de erro semelhante a esta:

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.iam.gserviceaccount.com" cannot list resource "roles" in
API group "rbac.authorization.k8s.io" in the namespace "kube-system": requires
one of ["container.roles.list"] permission(s).

Para resolver esse problema, use uma política de RBAC a fim de conceder as permissões para a tentativa de ação. Por exemplo, para resolver o problema no exemplo anterior, conceda um papel que tenha a permissão list em objetos roles no namespace kube-system. Para instruções, consulte Autorizar ações em clusters usando o controle de acesso baseado em papéis.

A federação de identidade da carga de trabalho para o GKE

O pod não pode se autenticar no Google Cloud

Se não for possível autenticar o aplicativo no Google Cloud, verifique se as configurações a seguir 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. Confirme se a federação de identidade da carga de trabalho do GKE está ativada no cluster. Para isso, verifique se ele tem um pool de identidades de cargas de trabalho definido:

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

    Substitua CLUSTER_NAME pelo nome do cluster do GKE.

    Se você ainda não tiver especificado uma zona ou região padrão para gcloud, talvez seja necessário especificar uma flag --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)"

    Substitua:

    • NODEPOOL_NAME pelo nome do pool de nós.
    • CLUSTER_NAME pelo nome do cluster do GKE.

  4. Confira se a conta de serviço do Kubernetes está anotada corretamente:

    kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME

    Substitua:

    • NAMESPACE pelo namespace do cluster do GKE.
    • KSA pelo nome da conta de serviço do Kubernetes.

    A saída esperada 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 IAM está configurada corretamente:

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

    A saída esperada 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 Para clusters que executam o GKE Dataplane V2, é necessário permitir a saída para 169.254.169.254/32 na porta 80.

    kubectl describe networkpolicy NETWORK_POLICY_NAME

    Substitua NETWORK_POLICY_NAME pelo nome da política de rede do GKE.

Acesso negado à conta de serviço do IAM

Pode ser que os pods não consigam acessar um recurso com a Federação de Identidade da Carga de Trabalho para GKE imediatamente depois de acrescentar vinculações de papel do IAM. É mais provável que a falha de acesso ocorra em pipelines de implantação ou em configurações declarativas do Google Cloud, em que recursos como políticas de permissão do IAM, vinculações de função e pods do Kubernetes são criados em conjunto. A seguinte mensagem de erro aparece nos registros do pod:

HTTP/403: generic::permission_denied: loading: GenerateAccessToken("SERVICE_ACCOUNT_NAME@PROJECT_ID.iam.gserviceaccount.com", ""): googleapi: Error 403: Permission 'iam.serviceAccounts.getAccessToken' denied on resource (or it may not exist).

Este erro pode ser causado pela propagação de mudanças de acesso no IAM, o que significa que mudanças de acesso, tais como permissões de função, levam tempo para se propagar pelo sistema. Para permissões de função, a propagação geralmente leva cerca de dois minutos, mas pode levar sete minutos ou mais. Para mais informações, acesse Propagação de mudança de acesso.

Para resolver este erro, adicione um atraso para que os pods tentem acessar os recursos do Google Cloud depois da criação.

Problemas de resolução de DNS

Algumas bibliotecas de cliente do Google Cloud são configuradas para se conectar aos servidores de metadados do GKE e do Compute Engine resolvendo o nome DNS metadata.google.internal. Para essas bibliotecas, a resolução de DNS íntegra no cluster é uma dependência essencial para que suas cargas de trabalho sejam autenticadas nos serviços do Google Cloud.

A forma como você detecta esse problema depende dos detalhes do aplicativo implantado, o que inclui a configuração da geração de registros. Fique de olho em mensagens de erro que:

  • peçam para você configurar o GOOGLE_APPLICATION_CREDENTIALS ou
  • informem que as solicitações para um serviço do Google Cloud foram rejeitadas porque a solicitação não tinha credenciais.

Se você encontrar problemas com a resolução de DNS de metadata.google.internal, algumas bibliotecas de cliente do Google Cloud poderão ser instruídas a ignorar a resolução de DNS definindo a variável de ambiente GCE_METADATA_HOST como 169.254.169.254:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: default
spec:
  containers:
  - image: debian
    name: main
    command: ["sleep", "infinity"]
    env:
    - name: GCE_METADATA_HOST
      value: "169.254.169.254"

Esse é o endereço IP fixado no código em que o serviço de metadados está sempre disponível nas plataformas de computação do Google Cloud.

Bibliotecas compatíveis do Google Cloud:

  • Python
  • Java
  • Node.js
  • Golang (No entanto, a biblioteca de cliente Golang já prefere se conectar por IP em vez de nome de DNS).

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. As tentativas de autenticação usando a Identidade da carga de trabalho do GKE 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, tente o seguinte:

  • Atualize as bibliotecas de cliente do Google Cloud usadas pelas suas cargas de trabalho.
  • Altere o código do aplicativo para aguardar alguns segundos e tente novamente.

  • Implante um initContainer que aguarde 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:alpine
    name: workload-identity-initcontainer
    command:
    - '/bin/bash'
    - '-c'
    - |
      curl -sS -H 'Metadata-Flavor: Google' 'http://169.254.169.254/computeMetadata/v1/instance/service-accounts/default/token' --retry 30 --retry-connrefused --retry-max-time 60 --connect-timeout 3 --fail --retry-all-errors > /dev/null && exit 0 || echo 'Retry limit exceeded. Failed to wait for metadata server to be available. Check if the gke-metadata-server Pod in the kube-system namespace is healthy.' >&2; exit 1
  containers:
  - image: gcr.io/your-project/your-image
    name: your-main-application-container

A federação de identidade da carga de trabalho para o GKE falha devido à indisponibilidade do plano de controle

O servidor de metadados não pode retornar a federação de identidade da carga de trabalho do GKE 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.

Uma entrada de registro pode ser semelhante a esta na Análise de registros:

dial tcp 35.232.136.58:443: connect: connection refused

Esse comportamento leva à indisponibilidade da federação de identidade da carga de trabalho para o GKE.

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. Consulte Como escolher um plano de controle regional ou zonal para saber mais sobre a disponibilidade do plano de controle. Alternar para um cluster regional elimina esse problema.

A federação de identidade da carga de trabalho para autenticação do GKE falha em clusters usando o Istio

Se o servidor de metadados do GKE for bloqueado por algum motivo, a federação de identidade da carga de trabalho para autenticação do GKE falhará.

Se você estiver usando o Istio ou o Cloud Service Mesh, adicione a seguinte anotação no nível do pod a todas as cargas de trabalho que usam a federação de identidade da carga de trabalho do GKE para excluir o IP do redirecionamento:

traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32

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

Como alternativa, também é possível adicionar a seguinte anotação no nível do pod a todas as cargas de trabalho que usam a federação de identidade da carga de trabalho do GKE para atrasar o início do contêiner do aplicativo até que o arquivo secundário esteja pronto:

proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'

É possível alterar a chave global.proxy.holdApplicationUntilProxyStarts Istio ConfigMap para fazer o mesmo.

O pod gke-metadata-server está falhando

O pod DaemonSet do sistema gke-metadata-server facilita a federação de identidade da carga de trabalho do GKE nos nós. O pod usa recursos de memória proporcionais ao número de contas de serviço do Kubernetes no cluster.

O problema a seguir ocorre quando o uso de recursos do pod gke-metadata-server excede os limites. O kubelet remove o pod com um erro de memória insuficiente. Você poderá ter esse problema se o cluster tiver mais de 3.000 contas de serviço do Kubernetes.

Para identificar o problema, faça o seguinte:

  1. Encontre pods gke-metadata-server com falha no namespace kube-system:

    kubectl get pods -n=kube-system | grep CrashLoopBackOff

    O resultado será assim:

    NAMESPACE     NAME                        READY     STATUS             RESTARTS   AGE
kube-system   gke-metadata-server-8sm2l   0/1       CrashLoopBackOff   194        16h
kube-system   gke-metadata-server-hfs6l   0/1       CrashLoopBackOff   1369       111d
kube-system   gke-metadata-server-hvtzn   0/1       CrashLoopBackOff   669        111d
kube-system   gke-metadata-server-swhbb   0/1       CrashLoopBackOff   30         136m
kube-system   gke-metadata-server-x4bl4   0/1       CrashLoopBackOff   7          15m

  2. Descreva o pod com falha para confirmar que a causa foi uma remoção de falta de memória:

    kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled

    Substitua POD_NAME pelo nome do pod a ser verificado.

Para restaurar a funcionalidade do servidor de metadados do GKE, reduza o número de contas de serviço no cluster para menos de 3 mil.

Falha ao ativar a federação de identidade da carga de trabalho do GKE com a mensagem de erro "DeployPatch"

O GKE usa o Agente de serviço do Kubernetes Engine (em inglês) gerenciado pelo Google Cloud para facilitar a federação de identidade da carga de trabalho do GKE nos seus clusters. O Google Cloud concede automaticamente a esse agente de serviço o papel de agente de serviço do Kubernetes Engine (roles/container.serviceAgent) no projeto quando você ativa a API Google Kubernetes Engine.

Se você tentar ativar a federação de identidade da carga de trabalho do GKE nos clusters de um projeto em que o agente de serviço não tem o papel de agente de serviço do Kubernetes Engine, a operação falhará com uma mensagem de erro semelhante a esta:

Error waiting for updating GKE cluster workload identity config: DeployPatch failed

Para resolver esse problema, tente o seguinte:

  1. Verifique se o agente de serviço existe no projeto e se ele está configurado corretamente:

    gcloud projects get-iam-policy PROJECT_ID \
    --flatten=bindings \
    --filter=bindings.role=roles/container.serviceAgent \
    --format="value[delimiter='\\n'](bindings.members)"

    Substitua o PROJECT_ID pelo ID do projeto do Google Cloud.

    Se o agente de serviço estiver configurado corretamente, a saída mostrará a identidade completa dele:

    serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com

    Se a saída não mostrar o agente de serviço, conceda a ele o papel de agente de serviço do Kubernetes Engine. Para conceder esse papel, conclua as etapas a seguir.

  2. Confira o número do projeto do Google Cloud:

    gcloud projects describe PROJECT_ID \
    --format="value(projectNumber)"

    O resultado será assim:

    123456789012

  3. Conceda ao agente de serviço o seguinte papel:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com \
    --role=roles/container.serviceAgent \
    --condition=None

    Substitua PROJECT_NUMBER pelo número do projeto do Google Cloud.

  4. Tente ativar a federação de identidade da carga de trabalho do GKE de novo.

A seguir

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.