Version 1.14. This version is no longer supported. For more information see the version support policy.

Resolver problemas de autenticação do GKE em VMware

Este documento ajuda a resolver problemas de autenticação no GKE em VMware. São fornecidas informações e orientações gerais para solução de problemas, além de informações específicas para o OpenID Connect (OIDC) e o protocolo leve de acesso a diretórios (LDAP).

A autenticação OIDC e LDAP usa o GKE Identity Service. Antes de usar o GKE Identity Service com o GKE em VMware, configure um provedor de identidade. Se ainda não tiver feito isso, siga as instruções de um dos provedores mais comuns:

Consulte o guia de solução de problemas do provedor de identidade do GKE Identity Service para informações sobre como ativar e revisar registros de identidade e testar a conectividade.

Se precisar de mais ajuda, entre em contato com o Suporte do Google.

Solução de problemas gerais

As dicas de solução de problemas a seguir podem ajudar com problemas gerais de autenticação e autorização com o GKE em VMware. Se esses problemas não se aplicarem ou se você tiver problemas com o OIDC ou LDAP, avance para a seção de solução de problemas do GKE Identity Service.

Manter o `gcloud anthos auth` atualizado

Para evitar muitos problemas comuns, verifique se os componentes da instalação do gcloud anthos auth estão atualizados.

Há duas partes que precisam ser verificadas. O comando gcloud anthos auth tem lógica no componente principal da Google Cloud CLI e um componente anthos-auth empacotado separadamente.

Para atualizar a Google Cloud CLI:
```
gcloud components update
```
Para atualizar o componente anthos-auth:
```
gcloud components install anthos-auth
```

Configuração de provedor inválida

Se a configuração do provedor de identidade for inválida, você verá uma tela de erro do provedor de identidade depois de clicar em LOGIN. Siga as instruções específicas do provedor para configurar corretamente o provedor ou o cluster.

Permissões inválidas

Se você concluir o fluxo de autenticação, mas ainda não vir os detalhes do cluster, verifique se concedeu as permissões RBAC corretas à conta usada com o OIDC. Essa pode ser uma conta diferente da que você usa para acessar o console do Google Cloud.

Token de atualização ausente

O problema a seguir ocorre quando o servidor de autorização solicita consentimento, mas o parâmetro de autenticação necessário não foi fornecido.

Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct

Para resolver esse problema, adicione prompt=consent ao campo authentication.oidc.extraParams no recurso ClientConfig. Em seguida, gere novamente o arquivo de autenticação do cliente.

O token de atualização expirou

O problema a seguir ocorre quando o token de atualização no arquivo kubeconfig expira:

Unable to connect to the server: Get {DISCOVERY_ENDPOINT}: x509:
    certificate signed by unknown authority

Para resolver esse problema, execute o comando gcloud anthos auth login novamente.

Falha no login de autenticação do gcloud anthos com o `proxyconnect tcp`

Esse problema ocorre quando há um erro nas configurações da variável de ambiente https_proxy ou HTTPS_PROXY. Se houver um https:// especificado nas variáveis de ambiente, as bibliotecas de cliente HTTP do GoLang poderão falhar se o proxy estiver configurado para processar conexões HTTPS usando outros protocolos, como SOCK5.

A seguinte mensagem de erro de exemplo pode ser retornada:

proxyconnect tcp: tls: first record does not look like a TLS handshake

Para resolver esse problema, modifique as variáveis de ambiente https_proxy e HTTPS_PROXY para omitir o https:// prefix. No Windows, modifique as variáveis de ambiente do sistema. Por exemplo, altere o valor da variável de ambiente https_proxy de https://webproxy.example.com:8000 para webproxy.example.com:8000.

O acesso ao cluster falha ao usar o kubeconfig gerado por `gcloud anthos auth login`

Esse problema ocorre quando o servidor da API Kubernetes não consegue autorizar o usuário. Isso pode acontecer se os RBACs apropriados estiverem ausentes ou incorretos ou se houver um erro na configuração do OIDC para o cluster. Este exemplo de erro pode ser exibido:

Unauthorized

Para resolver esse problema, siga estas etapas:

No arquivo kubeconfig gerado pelo gcloud anthos auth login, copie o valor de id-token.

kind: Config
...
users:
- name: ...
  user:
    auth-provider:
      config:
        id-token: xxxxyyyy

Instale jwt-cli e execute:
```
jwt ID_TOKEN
```
Verifique a configuração do OIDC.

O recurso ClientConfig tem os campos group e username. Esses campos são usados para definir as sinalizações --oidc-group-claim e --oidc-username-claim no servidor da API Kubernetes. Ao receber o token, o servidor da API encaminha o token para o GKE Identity Service, que retorna o group-claim e o username-claim extraídos para o servidor da API. O servidor da API usa a resposta para verificar se o grupo ou usuário correspondente tem as permissões corretas.

Verifique se as declarações definidas para group e user no recurso ClientConfig estão presentes no token de ID.
Verifique os RBACs que foram aplicados.

Verifique se há um RBAC com as permissões corretas para o usuário especificado por username-claim ou para um dos grupos listados group-claim da etapa anterior. O nome do usuário ou grupo no RBAC precisa ser prefixado com usernameprefix ou groupprefix que foi especificado no recurso ClientConfig.

Se usernameprefix estiver em branco e username for um valor diferente de email, o prefixo será issuerurl# por padrão. Para desativar os prefixos de nome de usuário, defina usernameprefix como -.

Para mais informações sobre prefixos de usuários e grupos, consulte Como autenticar com o OIDC.

Observação: o servidor da API Kubernetes considera uma barra invertida como um caractere de escape. Se o nome do usuário ou grupo contiver \\, o servidor de API o lerá como um único \ ao analisar o token de ID. Portanto, a vinculação do RBAC aplicada a esse usuário ou grupo deve conter somente uma única barra invertida. Caso contrário, você verá um erro Unauthorized.

Recurso ClientConfig:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
Token de ID:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
As seguintes vinculações do RBAC concedem a esse grupo e ao usuário o papel de cluster pod-reader. Observe uma única barra no campo de nome em vez de uma barra dupla:

ClusterRoleBinding do grupo:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: Group
  name: "oidc:EXAMPLE\developers"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
ClusterRoleBinding do usuário:
```
apiVersion:
kind: ClusterRoleBinding
metadata:
  name: example-binding
subjects:
- kind: User
  name: "EXAMPLE\cluster-developer"
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
```
Verifique os registros do servidor da API Kubernetes.

Se o plug-in OIDC configurado no servidor da API Kubernetes não for iniciado corretamente, o servidor da API retornará um erro Unauthorized quando apresentado com o token de ID. Para ver se houve algum problema com o plug-in OIDC no servidor da API, execute:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Substitua:
- USER_CLUSTER_NAME: o nome do cluster de usuários para ver os registros.
- ADMIN_CLUSTER_KUBECONFIG: o arquivo kubeconfig do cluster de administrador.

Esse problema ocorre quando o arquivo kubeconfig transmitido para gkectl create-login-config não é de um cluster de usuário ou o recurso ClientConfig não foi exibido durante a criação do cluster.

Error getting clientconfig using KUBECONFIG

Para resolver esse problema, verifique se você tem o arquivo kubeconfig correto para o cluster de usuário. Em seguida, verifique se o recurso ClientConfig está no cluster:

kubectl get clientconfig default -n kube-public \
  --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

Esse problema ocorre quando você tenta gravar dados de configuração de login que contêm um nome de cluster que já existe no arquivo de destino. Cada arquivo de configuração de login precisa conter nomes exclusivos de cluster.

error merging with file MERGE_FILE because MERGE_FILE contains a cluster with
  the same name as the one read from KUBECONFIG. Please write to a new
  output file

Para resolver esse problema, use a sinalização --output para especificar um novo arquivo de destino.

Se você não fornecer --output, esses dados de configuração de login serão gravados em um arquivo chamado kubectl-anthos-config.yaml no diretório atual.

Resolver problemas do OIDC

Quando a autenticação do OIDC não funciona com o GKE em VMware, geralmente a especificação do OIDC no recurso ClientConfig foi configurada incorretamente. O recurso ClientConfig fornece instruções para analisar registros e a especificação do OIDC para ajudar a identificar a causa de um problema do OIDC.

Consulte o guia de solução de problemas do provedor de identidade do GKE Identity Service para informações sobre como ativar e revisar registros de identidade e testar a conectividade. Depois de confirmar que o GKE Identity Service funciona conforme o esperado ou depois de identificar um problema, analise as seguintes informações de solução de problemas do OIDC.

Verificar a especificação do OIDC no seu cluster

As informações do OIDC do cluster são especificadas no recurso ClientConfig no namespace kube-public.

Use kubectl get para imprimir o recurso OIDC para o cluster de usuário:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.
Revise os valores do campo para confirmar que a especificação está configurada corretamente para o provedor OIDC.
Se você identificar um problema de configuração na especificação, reconfigure o OIDC.
Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o suporte do Google Cloud.

O suporte do Google Cloud precisa dos registros do GKE Identity Service e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.

Verificar se a autenticação OIDC está ativada

Antes de testar a autenticação do OIDC, verifique se ela está ativada no seu cluster.

Analise os registros do GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
O exemplo de saída abaixo mostra que a autenticação OIDC está ativada corretamente:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Se a autenticação OIDC não estiver ativada corretamente, erros semelhantes ao exemplo a seguir serão exibidos:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Analise os erros específicos informados e tente corrigi-los.

Testar a autenticação do OIDC

Para usar o recurso OIDC, use uma estação de trabalho com a IU e o navegador ativados. Não é possível realizar essas etapas em uma sessão SSH baseada em texto. Para testar se o OIDC funciona corretamente no cluster, siga estas etapas:

Faça o download da Google Cloud CLI.
Para gerar o arquivo de configuração de login, execute o seguinte comando gcloud anthos create-login-config:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.
Para autenticar o usuário, execute o seguinte comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Substitua:
- CLUSTER_NAME pelo nome do cluster de usuários a ser conectado.
- AUTH_KUBECONFIG pelo novo arquivo kubeconfig a ser criado, que inclui as credenciais para acessar seu cluster. Para mais informações, consulte Autenticar no cluster.
Você receberá uma página de consentimento de login aberta no navegador da Web padrão da estação de trabalho local. Forneça informações válidas de autenticação a um usuário nessa solicitação de login.

Depois que você concluir a etapa de login anterior, um arquivo kubeconfig será gerado no diretório atual.
Para testar o novo arquivo kubeconfig que inclui suas credenciais, liste os pods no cluster de usuário:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Substitua AUTH_KUBECONFIG pelo caminho para o novo arquivo kubeconfig gerado na etapa anterior.

A mensagem de exemplo a seguir pode ser retornada, mostrando que é possível autenticar com êxito, mas não há controles de acesso com base em papéis (RBACs) atribuídos à conta:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Analisar registros de autenticação do OIDC

Se você não conseguir se autenticar com o OIDC, os registros do GKE Identity Service fornecerão as informações mais relevantes e úteis para depurar o problema.

Use kubectl logs para imprimir os registros do GKE Identity Service:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.
Analise os registros em busca de erros que possam ajudar a diagnosticar problemas do OIDC.

Por exemplo, o recurso ClientConfig pode ter um erro de digitação no campo issuerURL, como htps://accounts.google.com (ausente em t em https). Os registros do GKE Identity Service conteriam uma entrada como a do exemplo a seguir:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Se você identificar um problema de configuração nos registros, reconfigure o OIDC e corrija os problemas de configuração.
Se você não conseguir diagnosticar e resolver o problema por conta própria, entre em contato com o suporte do Google Cloud. O suporte do Google Cloud precisa dos registros do GKE Identity Service e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.

Problemas comuns do OIDC

Se você tiver problemas com a autenticação do LDA, consulte os seguintes problemas comuns. Siga as orientações para resolver o problema.

Nenhum endpoint disponível para o serviço "ais"

Quando você salva o recurso ClientConfig, a seguinte mensagem de erro é retornada:

  Error from server (InternalError): Internal error occurred: failed calling webhook "clientconfigs.validation.com":
  failed to call webhook: Post "https://ais.anthos-identity-service.svc:15000/admission?timeout=10s":
  no endpoints available for service "ais"

Esse erro é causado pelo endpoint não íntegro do GKE Identity Service. O pod do GKE Identity Service não consegue exibir o webhook de validação.

Para confirmar se o pod de serviço do GKE Identity não está íntegro, execute o seguinte comando:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

A saída de exemplo a seguir significa que o pod do GKE Identity Service apresenta falha:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Para entender por que o pod tem um problema, veja os eventos dele:

kubectl describe pod -l k8s-app=ais \
  -n anthos-identity-service \
  --kubeconfig KUBECONFIG

Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.

A saída de exemplo a seguir informa um erro de permissão ao extrair a imagem:

Events:
  Type     Reason     Age                     From               Message
  ----     ------     ----                    ----               -------
  Normal   Scheduled  10m                     default-scheduler  Successfully assigned anthos-identity-service/ais-5949d879cd-flv9w to pool-1-76bbbb8798-dknz5
  Normal   Pulling    8m23s (x4 over 10m)     kubelet            Pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Failed to pull image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": rpc error: code = Unknown desc = failed to pull and unpack image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": failed to resolve reference "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00": pulling from host gcr.io failed with status code [manifests hybrid_identity_charon_20220808_2319_RC00]: 401 Unauthorized
  Warning  Failed     8m21s (x4 over 10m)     kubelet            Error: ErrImagePull
  Warning  Failed     8m10s (x6 over 9m59s)   kubelet            Error: ImagePullBackOff
  Normal   BackOff    4m49s (x21 over 9m59s)  kubelet            Back-off pulling image "gcr.io/gke-on-prem-staging/ais:hybrid_identity_charon_20220808_2319_RC00"

Se os eventos do pod relatarem um problema, continue a solução de problemas nas áreas afetadas. Se precisar de ajuda, fale com o suporte do Google Cloud.

Falha ao ler os bytes da resposta do servidor

Você pode encontrar os seguintes erros nos registros do GKE Identity Service:

  E0516 07:24:38.314681      65 oidc_client.cc:207] Failed fetching the Discovery URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/.well-known/openid-configuration" with error:
  Failed reading response bytes from server.

  E0516 08:24:38.446504      65 oidc_client.cc:223] Failed to fetch the JWKs URI
  "https://oidc.idp.cloud.example.com/auth/idp/k8sIdp/certs" with error:
  Failed reading response bytes from server.

Esses erros de rede podem aparecer nos registros de uma das seguintes maneiras:

Aparece pouco no registro: os erros de reserva provavelmente não são o problema principal e podem ser intermitentes.

O plug-in OIDC do GKE Identity Service tem um processo daemon para sincronizar periodicamente o URL de descoberta do OIDC a cada cinco segundos. Se a conexão de rede estiver instável, essa solicitação de saída poderá falhar. A falha ocasional não afeta a autenticação do OIDC. Os dados armazenados em cache podem ser reutilizados.

Se você encontrar erros extras nos registros, continue com as outras etapas de solução de problemas.
Eles aparecem constantemente no registro ou o GKE Identity Service nunca alcança com sucesso o endpoint conhecido: esses problemas constantes indicam um problema de conectividade entre o GKE Identity Service e seu provedor de identidade OIDC.

As seguintes etapas de solução de problemas podem ajudar a diagnosticar esses problemas de conectividade:
1. Verifique se um firewall não está bloqueando as solicitações de saída do GKE Identity Service.
2. Verifique se o servidor do provedor de identidade está sendo executado corretamente.
3. Verifique se o URL do emissor do OIDC no recurso ClientConfig está configurado corretamente.
4. Se você tiver ativado o campo do proxy no recurso ClientConfig, revise o status ou o registro do servidor proxy de saída.
5. Teste a conectividade entre o pod do GKE Identity Service e o servidor do provedor de identidade do OIDC.

Você deve estar conectado ao servidor (não autorizado)

Ao tentar fazer login usando a autenticação OIDC, você talvez receba a seguinte mensagem de erro:

  You must be logged in to the server (Unauthorized)

Esse erro é um problema geral de autenticação do Kubernetes que não fornece informações adicionais. No entanto, esse erro indica um problema de configuração.

Para determinar o problema, consulte as seções anteriores sobre Verificar a especificação do OIDC no cluster e configurar o recurso ClientConfig.

Falha ao fazer a solicitação do autenticador de webhook

Nos registros do GKE Identity Service, você pode encontrar o seguinte erro:

  E0810 09:58:02.820573       1 webhook.go:127] Failed to make webhook authenticator request:
  error trying to reach service: net/http: TLS handshake timeout

Esse erro indica que o servidor da API não pode estabelecer a conexão com o pod do GKE Identity Service.

Para verificar se o endpoint do serviço de identidade do GKE pode ser acessado de fora, execute este comando curl:
```
curl -k  -s -o /dev/null -w "%{http_code}" -X POST \
  https://APISERVER_HOST/api/v1/namespaces/anthos-identity-service/services/https:ais:https/proxy/authenticate -d '{}'
```
Substitua APISERVER_HOST pelo endereço do servidor da API.

A resposta esperada é um código de status HTTP 400. Se a solicitação expirar, reinicie o pod do GKE Identity Service. Se o erro persistir, isso significa que o servidor HTTP do GKE Identity Service não consegue iniciar. Para receber mais ajuda, entre em contato com o suporte do Google Cloud.

Resolver problemas no LDAP

Se você tiver problemas com a autenticação LDAP, verifique se configurou seu ambiente seguindo um dos documentos de configuração apropriados:

Você também precisa preencher a chave secreta da conta de serviço LDAP e ter configurado o recurso ClientConfig para ativar a autenticação LDAP.

Consulte o guia de solução de problemas do provedor de identidade do GKE Identity Service para informações sobre como ativar e revisar registros de identidade e testar a conectividade. Depois de confirmar que o GKE Identity Service funciona conforme o esperado ou depois identificar um problema, analise as seguintes informações de solução de problemas do LDAP.

Verificar se a autenticação LDAP está ativada

Antes de testar a autenticação LDAP, verifique se ela está ativada no seu cluster.

Analise os registros do GKE Identity Service:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
O exemplo de saída abaixo mostra que a autenticação LDAP está ativada corretamente:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Se a autenticação LDAP não estiver ativada corretamente, serão exibidos erros semelhantes ao seguinte exemplo:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Analise os erros específicos informados e tente corrigi-los.

Testar a autenticação LDAP

Para usar o recurso LDAP, use uma estação de trabalho com a IU e o navegador ativados. Não é possível realizar essas etapas em uma sessão SSH baseada em texto. Para testar se a autenticação LDAP funciona corretamente no cluster, siga estas etapas:

Faça o download da Google Cloud CLI.
Para gerar o arquivo de configuração de login, execute o comando gcloud anthos create-login-config a seguir:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Substitua KUBECONFIG pelo caminho para o arquivo kubeconfig do cluster de usuário.
Para autenticar o usuário, execute o seguinte comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Substitua:
- CLUSTER_NAME pelo nome do cluster de usuários a ser conectado.
- AUTH_KUBECONFIG pelo novo arquivo kubeconfig a ser criado, que inclui as credenciais para acessar seu cluster. Para mais informações, consulte Autenticar no cluster.
Você receberá uma página de consentimento de login aberta no navegador da Web padrão da estação de trabalho local. Forneça informações válidas de autenticação a um usuário nessa solicitação de login.

Depois que você concluir a etapa de login anterior, um arquivo kubeconfig será gerado no diretório atual.
Para testar o novo arquivo kubeconfig que inclui suas credenciais, liste os pods no cluster de usuário:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Substitua AUTH_KUBECONFIG pelo caminho para o cluster de usuário kubeconfig que foi gerado na etapa anterior.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Problemas comuns do LDAP

Se você tiver problemas com a autenticação LDAP, analise os seguintes problemas comuns. Siga as orientações para resolver o problema.

Os usuários não podem fazer a autenticação com vírgulas na CN

Quando você usa o LDAP, pode ter problemas em que os usuários não podem fazer a autenticação quando o CN contém uma vírgula, como CN="a,b". Se você ativar o registro de depuração do GKE Identity Service, a seguinte mensagem de erro será exibida:

  I0207 20:41:32.670377 30 authentication_plugin.cc:977] Unable to query groups from the LDAP server directory.example.com:636, using the LDAP service account
  'CN=svc.anthos_dev,OU=ServiceAccount,DC=directory,DC=example,DC=com'.
  Encountered the following error: Empty entries.

Esse problema ocorre porque o plug-in LDAP do GKE Identity Service faz o escape duplo da vírgula. Esse problema só acontece nas versões GKE em VMware 1.13 e anteriores.

Para corrigir esse problema, siga uma destas etapas:

Faça upgrade do cluster para o GKE em VMware 1.13 ou posterior.
Escolha um identifierAttribute diferente, como sAMAccountName, em vez de usar a CN.
Remova as vírgulas da CN do seu diretório LDAP.

Falha de autenticação com a Google Cloud CLI 1.4.2

Com a Google Cloud CLI anthos-auth 1.4.2, você pode ver a seguinte mensagem de erro ao executar o comando gcloud anthos auth login:

  Error: LDAP login failed: could not obtain an STS token: Post "https://127.0.0.1:15001/sts/v1beta/token":
  failed to obtain an endpoint for deployment anthos-identity-service/ais: Unauthorized
  ERROR: Configuring Anthos authentication failed

No registro do GKE Identity Service você também encontra o seguinte erro:

  I0728 12:43:01.980012      26 authentication_plugin.cc:79] Stopping STS   authentication, unable to decrypt the STS token:
  Decryption failed, no keys in the current key set could decrypt the payload.

Para resolver esse erro, siga estas etapas:

Verifique se você usa a versão 1.4.2 da anthos-auth do Google Cloud CLI:
```
gcloud anthos auth version
```
O exemplo de saída abaixo mostra que a versão é 1.4.2:
```
Current Version: v1.4.2
```
Se você executar a Google Cloud CLI anthos-auth versão 1.4.2, faça upgrade para a versão 1.4.3 ou posterior.

Problemas comuns

Nesta seção, detalhamos problemas comuns de autenticação e como resolvê-los.

O acesso à estação de trabalho do administrador foi perdido devido a um erro de chave SSH `permission denied`

O erro a seguir ocorre quando você tenta se conectar à estação de trabalho do administrador e recebe uma mensagem "Permission denied" semelhante ao exemplo a seguir:

Authorized users only. All activity may be monitored and reported.
TARGET_MACHINE: Permission denied (publickey).

Esse erro ocorre devido ao uso de uma chave privada incorreta ou de nenhuma chave quando você se conecta à estação de trabalho do administrador usando SSH.

Para resolver esse problema, encontre e use a chave SSH correta. Se você não encontrar a chave SSH correta, gere um novo par de chaves SSH para a estação de trabalho do administrador seguindo estas etapas:

Crie uma VM de resgate temporário. Essa VM de resgate precisa se conectar à mesma rede e Datastore que a VM atual da estação de trabalho do administrador.
Desligue a VM da estação de trabalho do administrador e a VM de resgate.
Anexe o disco de dados da VM da estação de trabalho do administrador à VM de resgate. O disco de dados geralmente é de 512 MB, a menos que você tenha especificado um tamanho de disco diferente no arquivo de configuração da estação de trabalho do administrador, que é diferente do disco de inicialização.
Ligue a VM de resgate.
Conecte-se à VM de resgate usando SSH.
No computador local, gere um novo par de chaves SSH.
No computador local, copie a nova chave pública SSH na VM de resgate usando o comando ssh-copy-id:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Substitua:
- NEW_SSH_KEY pelo nome da nova chave SSH que você criou na etapa anterior;
- RESCUE_VM pelo endereço IP ou FQDN da VM de resgate.
Na VM de resgate, monte o disco de dados nela:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Substitua DEVICE pelo identificador exclusivo do seu próprio disco, como /dev/sdb1.
Na VM de resgate, copie a nova chave pública SSH no arquivo authorized_keys no disco de dados ativado da VM da estação de trabalho do administrador.

Visualize o conteúdo do arquivo authorized_keys na VM de resgate, que inclui a nova chave pública SSH copiada usando o comando ssh-copy-id em uma etapa anterior:
```
ls ~/.ssh/authorized_keys
```
Copie a última entrada de chave pública SSH do arquivo authorized_keys e feche-o.
Edite o arquivo authorized_keys no disco de dados ativado da VM da estação de trabalho do administrador:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Cole o conteúdo da chave pública SSH do arquivo authorized_keys da VM de resgate.
Salve e feche o arquivo authorized_keys no disco de dados ativado da VM da estação de trabalho do administrador.
Verifique se os arquivos em /mnt/ext-disk/.ssh/ têm as permissões corretas aplicadas a eles:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Saia da conexão SSH com a VM de resgate.
Encerre a VM de resgate.
Remova o disco de dados da VM de resgate e anexe-o novamente à VM da estação de trabalho do administrador.
Ligue a estação de trabalho de administrador.
Depois que a VM estiver em execução, conecte-se à estação de trabalho do administrador usando SSH e o novo par de chaves SSH.
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
Substitua:
- NEW_SSH_KEY pelo nome da nova chave SSH que você criou em uma etapa anterior e copiou para a VM da estação de trabalho do administrador.
- RESCUE_VM pelo endereço IP ou FQDN da VM da estação de trabalho do administrador.
Verifique se é possível se conectar usando SSH.
Exclua a VM de resgate.

A seguir