Algumas ou todas as informações nesta página podem não se aplicar à Trusted Cloud da S3NS. Consulte Diferenças do Google Cloud para saber mais.

Esta página foi traduzida pela API Cloud Translation.

Resolva problemas de autenticação do GKE

Autopilot Padrão

Esta página mostra como resolver problemas relacionados com as configurações de segurança nos clusters Autopilot e Standard do Google Kubernetes Engine (GKE).

RBAC e IAM

As contas IAM autenticadas não conseguem realizar ações no cluster

O seguinte problema ocorre quando tenta realizar 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 de autorização da IAM que conceda a mesma autorização. Se falhar, é apresentada uma mensagem de erro semelhante à seguinte:

Error from server (Forbidden): roles.rbac.authorization.k8s.io is forbidden:
User "example-account@example-project.s3ns.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 este problema, use uma política de RBAC para conceder as autorizações para a ação tentada. Por exemplo, para resolver o problema no exemplo anterior, conceda uma função que tenha a autorização list em objetos roles no espaço de nomes kube-system. Para obter instruções, consulte o artigo Autorize ações em clusters através do controlo de acesso baseado em funções.

Workload Identity Federation para o GKE

O pod não consegue autenticar-se em Trusted Cloud by S3NS

Se a sua aplicação não conseguir autenticar-se em Trusted Cloud by S3NS, certifique-se de que as seguintes definições estão configuradas corretamente:

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

Ative a API IAM Credentials
Confirme se a federação de identidade da força de trabalho para o GKE está ativada no cluster verificando se tem um conjunto do Workload Identity definido:
```
gcloud container clusters describe CLUSTER_NAME \
    --format="value(workloadIdentityConfig.workloadPool)"
```
Substitua CLUSTER_NAME pelo nome do seu cluster do GKE.

Se ainda não tiver especificado uma zona ou uma região predefinida para gcloud, também pode ter de especificar uma flag --region ou --zone quando executar este comando.
Certifique-se de que o servidor de metadados do GKE está configurado no conjunto de nós onde a sua aplicação está a ser executada:
```
gcloud container node-pools describe NODEPOOL_NAME \
    --cluster=CLUSTER_NAME \
    --format="value(config.workloadMetadataConfig.mode)"
```
Substitua o seguinte:
- NODEPOOL_NAME com o nome do seu nodepool.
- CLUSTER_NAME com o nome do seu cluster do GKE.
Verifique se a conta de serviço do Kubernetes está anotada corretamente:
```
kubectl describe serviceaccount \
    --namespace NAMESPACE KSA_NAME
```
Substitua o seguinte:
- NAMESPACE com o espaço de nomes do cluster do GKE.
- KSA com o nome da sua conta de serviço do Kubernetes.
O resultado esperado contém uma anotação semelhante à seguinte:
```
iam.gke.io/gcp-service-account: GSA_NAME@PROJECT_ID.s3ns.iam.gserviceaccount.com
```

Verifique se a conta de serviço do IAM está configurada corretamente:

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

O resultado esperado contém uma associação semelhante à seguinte:

- members:
  - serviceAccount:PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]
  role: roles/iam.workloadIdentityUser

Se tiver uma política de rede de cluster, tem de permitir a saída para 127.0.0.1/32 na porta 988 para clusters que executam versões do GKE anteriores à 1.21.0-gke.1000 ou para 169.254.169.252/32 na porta 988 para clusters que executam a versão 1.21.0-gke.1000 e posteriores do GKE. Para clusters que executam o GKE Dataplane V2, tem de 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 sua política de rede do GKE.

Acesso à conta de serviço de IAM negado

Os pods podem não conseguir aceder imediatamente a um recurso com a Workload Identity Federation para o GKE depois de adicionar vinculações de funções de IAM. É mais provável que ocorra uma falha de acesso em pipelines de implementação ou em Trusted Cloud configurações Trusted Cloud declarativas, onde os recursos, como as políticas de autorização do IAM, as associações de funções e os pods do Kubernetes, são criados em conjunto. A seguinte mensagem de erro é apresentada nos registos do pod:

HTTP/403: generic::permission_denied: loading: GenerateAccessToken("SERVICE_ACCOUNT_NAME@PROJECT_ID.s3ns.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 alterações de acesso no IAM, o que significa que as alterações de acesso, como as concessões de funções, demoram algum tempo a propagar-se por todo o sistema. Para concessões de funções, a propagação demora normalmente cerca de dois minutos, mas, por vezes, pode demorar sete ou mais minutos. Para mais detalhes, consulte o artigo Propagação de alterações de acesso.

Para resolver este erro, considere adicionar um atraso antes de os pods tentarem aceder a recursos Trusted Cloud depois de serem criados.

Problemas de resolução de DNS

Esta secção descreve como identificar e resolver erros de ligação de Pods a APIs causados por problemas de resolução de DNS. Trusted Cloud Se os passos nesta secção não resolverem os erros de ligação, consulte a secção Erros de limite de tempo no arranque do pod.

Algumas Trusted Cloud by S3NS bibliotecas de cliente estão configuradas para estabelecer ligação aos servidores de metadados do GKE e do Compute Engine resolvendo o nome DNSmetadata.google.internal. Para estas bibliotecas, a resolução DNS no cluster saudável é uma dependência crítica para que as suas cargas de trabalho se autentiquem nosTrusted Cloud serviços.

A forma como deteta este problema depende dos detalhes da sua aplicação implementada, incluindo a respetiva configuração de registo. Procure mensagens de erro que lhe digam para configurar o GOOGLE_APPLICATION_CREDENTIALS, que as suas solicitações a um serviçoTrusted Cloud foram rejeitadas porque a solicitação não tinha credenciais ou que não foi possível encontrar o servidor de metadados.

Por exemplo, a seguinte mensagem de erro pode indicar que existe um problema de resolução de DNS:

ComputeEngineCredentials cannot find the metadata server. This is likely because code is not running on Google Compute Engine

Se tiver problemas com a resolução de DNS de metadata.google.internal, algumas Trusted Cloud by S3NS bibliotecas de cliente podem ser instruídas para 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"

Este é o endereço IP codificado no qual o serviço de metadados está sempre disponível nas plataformas de computação. Trusted Cloud

As seguintes Trusted Cloud bibliotecas são suportadas:

Python
Java
Node.js
Golang

Por predefinição, a biblioteca cliente Go estabelece ligação através do endereço IP.

Erros de limite de tempo no arranque do Pod

O servidor de metadados do GKE precisa de alguns segundos antes de poder começar a aceitar pedidos num novo pod. As tentativas de autenticação com a Workload Identity Federation para o GKE nos primeiros segundos da vida útil de um pod podem falhar para aplicações e Trusted Cloud by S3NS bibliotecas de cliente configuradas com um limite de tempo curto.

Se encontrar erros de limite de tempo, experimente o seguinte:

Atualize as bibliotecas de cliente do Trusted Cloud que as suas cargas de trabalho usam.
Altere o código da aplicação para aguardar alguns segundos e tentar novamente.

Implemente um initContainer que aguarde até que o servidor de metadados do GKE esteja pronto antes de executar o contentor principal do pod.

Por exemplo, o seguinte manifesto destina-se a um agrupamento com um 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 controlo

O servidor de metadados não pode devolver a Workload Identity Federation para o GKE quando o plano de controlo do cluster está indisponível. As chamadas para o servidor de metadados devolvem o código de estado 500.

Uma entrada de registo pode ter um aspeto semelhante ao seguinte no Explorador de registos:

dial tcp 35.232.136.58:443: connect: connection refused

Este comportamento leva à indisponibilidade da federação de identidade de cargas de trabalho para o GKE.

O plano de controlo pode estar indisponível em clusters zonais durante a manutenção do cluster, como a rotação de IPs, a atualização de VMs do plano de controlo ou a alteração do tamanho de clusters ou conjuntos de nós. Consulte o artigo Escolher um plano de controlo regional ou zonal para saber mais sobre a disponibilidade do plano de controlo. A mudança para um cluster regional elimina este problema.

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

Pode ver erros semelhantes aos seguintes quando a sua aplicação é iniciada e tenta comunicar com um ponto final:

Connection refused (169.254.169.254:80)

Connection timeout

Estes erros podem ocorrer quando a sua aplicação tenta estabelecer uma ligação de rede antes de o contentor istio-proxy estar pronto. Por predefinição, o Istio e o Cloud Service Mesh permitem que as cargas de trabalho enviem pedidos assim que começam, independentemente de a carga de trabalho do proxy de service mesh que interceta e redireciona o tráfego estar em execução. Para pods que usam a Workload Identity Federation para o GKE, estes pedidos iniciais que ocorrem antes do início do proxy podem não chegar ao servidor de metadados do GKE. Consequentemente, a autenticação nas APIs Trusted Cloud falha. Se não configurar as suas aplicações para repetir os pedidos, as suas cargas de trabalho podem falhar.

Para confirmar que este problema é a causa dos seus erros, veja os registos e verifique se o contentor istio-proxy foi iniciado com êxito:

Na Trusted Cloud consola, aceda à página Explorador de registos.

Aceda ao Explorador de registos

No painel de consultas, introduza a seguinte consulta:

(resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
textPayload:"Envoy proxy is ready" OR textPayload:"ERROR_MESSAGE")
OR
(resource.type="k8s_pod"
logName:"events"
jsonPayload.involvedObject.name="POD_NAME")

Substitua o seguinte:

POD_NAME: o nome do Pod com a carga de trabalho afetada.
ERROR_MESSAGE: o erro que a aplicação recebeu (connection timeout ou connection refused).

Clique em Executar consulta.
Reveja o resultado e verifique quando o contentor istio-proxy ficou pronto.

No exemplo seguinte, a aplicação tentou fazer uma chamada gRPC. No entanto, uma vez que o contentor istio-proxy ainda estava a ser inicializado, a aplicação recebeu um erro Connection refused. A data/hora junto à mensagem Envoy proxy is ready indica quando o contentor istio-proxy ficou pronto para pedidos de ligação:
```
2024-11-11T18:37:03Z started container istio-init
2024-11-11T18:37:12Z started container gcs-fetch
2024-11-11T18:37:42Z Initializing environment
2024-11-11T18:37:55Z Started container istio-proxy
2024-11-11T18:38:06Z StatusCode="Unavailable", Detail="Error starting gRPC call. HttpRequestException: Connection refused (169.254.169.254:80)
2024-11-11T18:38:13Z Envoy proxy is ready
```

Para resolver este problema e evitar que volte a ocorrer, experimente uma das seguintes opções de configuração por carga de trabalho:

Impedir que as suas aplicações enviem pedidos até que a carga de trabalho do proxy esteja pronta. Adicione a seguinte anotação ao campo metadata.annotations na especificação do pod:
```
proxy.istio.io/config: '{ "holdApplicationUntilProxyStarts": true }'
```
Configure o Istio ou o Cloud Service Mesh para excluir o endereço IP do servidor de metadados do GKE do redirecionamento. Adicione a seguinte anotação ao campo metadata.annotations da especificação do pod:
```
traffic.sidecar.istio.io/excludeOutboundIPRanges: 169.254.169.254/32
```

No Istio de código aberto, pode mitigar opcionalmente este problema para todos os pods definindo uma das seguintes opções de configuração global:

Exclua o endereço IP do servidor de metadados do GKE do redirecionamento: atualize a global.proxy.excludeIPRanges opção de configuração global para adicionar o intervalo de endereços IP 169.254.169.254/32.
Impedir que as aplicações enviem pedidos até o proxy ser iniciado: adicione a opção de configuração global global.proxy.holdApplicationUntilProxyStarts com um valor de true à configuração do Istio.

O `gke-metadata-server` Pod está a falhar

O pod DaemonSet do sistema gke-metadata-server facilita a Workload Identity Federation para o GKE nos seus nós. O pod usa recursos de memória proporcionais ao número de contas de serviço do Kubernetes no seu cluster.

O seguinte problema ocorre quando a utilização de recursos do gke-metadata-server Pod excede os respetivos limites. O kubelet despeja o pod com um erro de falta de memória. Pode ter este problema se o seu cluster tiver mais de 3000 contas de serviço do Kubernetes.

Para identificar o problema, faça o seguinte:

Encontre gke-metadata-serverpodskube-system com falhas de sistema no espaço de nomes kube-system:

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

O resultado é semelhante ao seguinte:

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

Descreva o pod com falhas para confirmar que a causa foi uma remoção por falta de memória:
```
kubectl describe pod POD_NAME --namespace=kube-system | grep OOMKilled
```
Substitua POD_NAME pelo nome do Pod a verificar.

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

A Workload Identity Federation para o GKE não é ativada com a mensagem de erro DeployPatch failed

O GKE usa o Trusted Cloudagente do serviço do Kubernetes Engine gerido pela Google para facilitar a Federação de Identidades de cargas de trabalho para o GKE nos seus clusters. Trusted Cloud concede automaticamente a este agente do serviço a função de agente do serviço do Kubernetes Engine (roles/container.serviceAgent) no seu projeto quando ativa a API Google Kubernetes Engine.

Se tentar ativar a Workload Identity Federation para o GKE em clusters num projeto onde o agente de serviço não tem a função de agente de serviço do Kubernetes Engine, a operação falha com uma mensagem de erro semelhante à seguinte:

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

Para resolver este problema, experimente os seguintes passos:

Verifique se o agente de serviço existe no seu projeto e 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 PROJECT_ID pelo seu Trusted Cloud ID do projeto.

Se o agente do serviço estiver configurado corretamente, o resultado mostra a identidade completa do agente do serviço:
```
serviceAccount:service-PROJECT_NUMBER@container-engine-robot.s3ns.iam.gserviceaccount.com
```
Se o resultado não apresentar o agente de serviço, tem de lhe conceder a função de agente de serviço do Kubernetes Engine. Para conceder esta função, conclua os seguintes passos.

Obtenha o número do seu projeto Trusted Cloud :

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