Esta página foi traduzida pela API Cloud Translation.

Resolva problemas de autenticação do Google Distributed Cloud

Este documento ajuda a resolver problemas de autenticação no Google Distributed Cloud. São fornecidas informações e orientações gerais de resolução de problemas, juntamente com informações específicas para o OpenID Connect (OIDC) e o Lightweight Directory Access Protocol (LDAP).

A autenticação OIDC e LDAP usa o serviço de identidade do GKE. Antes de poder usar o GKE Identity Service com o Google Distributed Cloud, tem de configurar um fornecedor de identidade. Se não configurou um Fornecedor de identidade para o GKE Identity Service, siga as instruções de um dos seguintes fornecedores mais comuns:

Resolução de problemas gerais

As seguintes dicas de resolução de problemas podem ajudar com problemas gerais de autenticação e autorização com o Google Distributed Cloud. Se estes problemas não se aplicarem ou tiver problemas com o OIDC ou o LDAP, continue para a secção sobre a resolução de problemas do GKE Identity Service.

Mantenha o `gcloud anthos auth` atualizado

Pode evitar muitos problemas comuns ao verificar se os componentes da sua instalação estão atualizados.gcloud anthos auth

Existem dois elementos que têm de ser validados. O comando gcloud anthos auth tem lógica no componente principal da CLI gcloud e um componente anthos-auth em pacote separado.

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

Configuração do fornecedor inválida

Se a configuração do fornecedor de identidade for inválida, é apresentado um ecrã de erro do fornecedor de identidade depois de clicar em LOGIN. Siga as instruções específicas do fornecedor para configurar corretamente o fornecedor ou o cluster.

Configuração inválida

Se Google Cloud a consola não conseguir ler a configuração OIDC do seu cluster, o botão LOGIN está desativado. Para resolver problemas de configuração do OIDC do cluster, consulte a secção de resolução de problemas do OIDC neste documento.

Autorizações inválidas

Se concluir o fluxo de autenticação, mas continuar a não ver os detalhes do cluster, certifique-se de que concedeu as autorizações RBAC corretas à conta que usou com o OIDC. Esta pode ser uma conta diferente da que usa para aceder à Google Cloud consola.

Token de atualização em falta

O seguinte problema ocorre quando o servidor de autorização pede 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 este problema, no recurso ClientConfig, adicione prompt=consent ao campo authentication.oidc.extraParams. Em seguida, volte a gerar o ficheiro de autenticação do cliente.

O token de atualização expirou

O seguinte problema ocorre quando o token de atualização no ficheiro kubeconfig expirou:

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

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

O comando gcloud anthos auth login falha com `proxyconnect tcp`

Este problema ocorre quando existe um erro nas configurações das variáveis de ambiente https_proxy ou HTTPS_PROXY. Se existir um https:// especificado nas variáveis de ambiente, as bibliotecas de clientes HTTP GoLang podem falhar se o proxy estiver configurado para processar ligações HTTPS através de outros protocolos, como o SOCK5.

Pode ser devolvida a seguinte mensagem de erro de exemplo:

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

Para resolver este 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 quando usa o kubeconfig gerado por `gcloud anthos auth login`

Este problema ocorre quando o servidor da API Kubernetes não consegue autorizar o utilizador. Isto pode acontecer se os RBACs adequados estiverem em falta ou incorretos, ou se houver um erro na configuração do OIDC para o cluster. Pode ser apresentado o seguinte erro de exemplo:

Unauthorized

Para resolver este problema, conclua os seguintes passos:

No ficheiro 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
```
Valide a configuração do OIDC.

O recurso ClientConfig tem os campos group e username. Estes campos são usados para definir os flags --oidc-group-claim e --oidc-username-claim no servidor da API Kubernetes. Quando o servidor da API recebe o token, encaminha-o para o serviço de identidade do GKE, que devolve o group-claim e o username-claim extraídos ao servidor da API. O servidor da API usa a resposta para verificar se o grupo ou o utilizador correspondente tem as autorizações corretas.

Verifique se o conjunto de reivindicações para group e user no recurso ClientConfig está presente no token de ID.
Verifique as RBACs que foram aplicadas.

Verifique se existe um RBAC com as autorizações corretas para o utilizador especificado por username-claim ou um dos grupos indicados group-claim no passo anterior. O nome do utilizador ou do grupo no RBAC deve ter o prefixo usernameprefix ou groupprefix especificado no recurso ClientConfig.

Se usernameprefix estiver em branco e username for um valor diferente de email, o prefixo é predefinido como issuerurl#. Para desativar os prefixos de nomes de utilizador, defina usernameprefix como -.

Para mais informações sobre prefixos de utilizadores e grupos, consulte o artigo Autenticação com OIDC.

Nota: o servidor da API Kubernetes trata uma barra invertida como um caráter de escape. Se o nome do utilizador ou do grupo contiver \\, o servidor da API lê-o como um único \ ao analisar o token de ID. Por conseguinte, a associação de funções RBAC aplicada a este utilizador ou grupo deve conter apenas uma barra invertida, caso contrário, pode ver um erro Unauthorized.

ClientConfig recurso:
```
oidc:
  ...
  username: "unique_name"
  usernameprefix: "-"
  group: "group"
  groupprefix: "oidc:"
```
ID da chave:
```
{
  ...
  "email": "cluster-developer@example.com",
  "unique_name": "EXAMPLE\cluster-developer",
  "group": [
    "Domain Users",
    "EXAMPLE\developers"
  ],
...
}
```
As associações RBAC seguintes concedem a este grupo e utilizador a função de cluster pod-reader. Repare na barra invertida única no campo de nome em vez de uma barra invertida dupla:

Group ClusterRoleBinding:
```
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
```
User ClusterRoleBinding:
```
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 registos 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 devolve um erro Unauthorized quando lhe é apresentado o token de ID. Para ver se houve problemas com o plugin OIDC no servidor de API, execute o seguinte comando:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Substitua o seguinte:
- USER_CLUSTER_NAME: o nome do cluster de utilizadores para ver os registos.
- ADMIN_CLUSTER_KUBECONFIG: O ficheiro kubeconfig do cluster de administrador.

Este problema ocorre quando o ficheiro kubeconfig transmitido a gkectl create-login-config não é para um cluster de utilizador ou o recurso ClientConfig não foi apresentado durante a criação do cluster.

Error getting clientconfig using KUBECONFIG

Para resolver este problema, certifique-se de que tem o ficheiro kubeconfig correto para o seu cluster de utilizador. 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 ficheiro kubeconfig do cluster de utilizadores.

Este problema ocorre se tentar escrever dados de configuração de início de sessão que contenham um nome de cluster que já existe no ficheiro de destino. Cada ficheiro de configuração de início de sessão tem de conter nomes de clusters exclusivos.

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 este problema, use a flag --output para especificar um novo ficheiro de destino.

Se não fornecer --output, estes dados de configuração de início de sessão são escritos num ficheiro denominado kubectl-anthos-config.yaml no diretório atual.

Resolva problemas do OIDC

Quando a autenticação OIDC não está a funcionar para o Google Distributed Cloud, normalmente, a especificação OIDC no recurso ClientConfig foi configurada incorretamente. O recurso ClientConfig fornece instruções para rever os registos e a especificação OIDC para ajudar a identificar a causa de um problema do OIDC.

Reveja o guia de resolução de problemas do fornecedor de identidade do serviço de identidade do GKE para ver informações sobre como ativar e rever os registos de identidade e testar a conetividade. Depois de confirmar que o serviço de identidade do GKE funciona conforme esperado ou identificar um problema, reveja as seguintes informações de resolução de problemas do OIDC.

Verifique a especificação OIDC no seu cluster

As informações da OIDC para o seu cluster são especificadas no recurso ClientConfig no espaço de nomes kube-public.

Use kubectl get para imprimir o recurso OIDC para o cluster de utilizadores:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.
Reveja os valores dos campos para confirmar que a especificação está configurada corretamente para o seu fornecedor de OIDC.
Se identificar um problema de configuração na especificação, reconfigure o OIDC.
Se não conseguir diagnosticar e resolver o problema sozinho, contacte Google Cloud o apoio técnico.

Google Cloud O apoio técnico precisa dos registos do serviço de identidade do GKE e da especificação OIDC para diagnosticar e resolver problemas do OIDC.

Confirme se a autenticação OIDC está ativada

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

Examine os registos do serviço de identidade do GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
O resultado de exemplo seguinte mostra que a autenticação OIDC está corretamente ativada:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Se a autenticação OIDC não estiver ativada corretamente, são apresentados erros semelhantes ao exemplo seguinte:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Reveja os erros específicos comunicados e tente corrigi-los.

Teste a autenticação OIDC

Para usar a funcionalidade OIDC, use uma estação de trabalho com a IU e o navegador ativados. Não pode realizar estes passos a partir de uma sessão de SSH baseada em texto. Para testar se o OIDC funciona corretamente no seu cluster, conclua os seguintes passos:

Transfira a CLI do Google Cloud.
Para gerar o ficheiro de configuração de início de sessão, 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 ficheiro kubeconfig do cluster de utilizadores.
Para autenticar o utilizador, execute o seguinte comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Substitua o seguinte:
- CLUSTER_NAME com o nome do cluster de utilizadores ao qual se quer ligar.
- AUTH_KUBECONFIG com o novo ficheiro kubeconfig para criar que inclui as credenciais para aceder ao seu cluster. Para mais informações, consulte Autentique-se no cluster.
Deve receber uma página de consentimento de início de sessão aberta no navegador de Internet predefinido da sua estação de trabalho local. Forneça informações de autenticação válidas para um utilizador neste pedido de início de sessão.

Depois de concluir com êxito o passo de início de sessão anterior, é gerado um ficheiro kubeconfig no seu diretório atual.
Para testar o novo ficheiro kubeconfig que inclui as suas credenciais, liste os pods no cluster de utilizadores:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Substitua AUTH_KUBECONFIG pelo caminho para o novo ficheiro kubeconfig que foi gerado no passo anterior.

Pode ser devolvida a seguinte mensagem de exemplo, que mostra que pode autenticar-se com êxito, mas não existem controlos de acesso baseados em funções (CABFs) atribuídos à conta:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Reveja os registos de autenticação OIDC

Se não conseguir autenticar com o OIDC, os registos do serviço de identidade do GKE fornecem as informações mais relevantes e úteis para depurar o problema.

Use kubectl logs para imprimir os registos do GKE Identity Service:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.
Reveja os registos para encontrar erros que possam ajudar a diagnosticar problemas de OIDC.

Por exemplo, o recurso ClientConfig pode ter um erro ortográfico no campo issuerURL, como htps://accounts.google.com (falta um t em https). Os registos do serviço de identidade do GKE contêm uma entrada como o seguinte exemplo:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Se identificar um problema de configuração nos registos, Reconfigure o OIDC e corrija os problemas de configuração.
Se não conseguir diagnosticar e resolver o problema sozinho, contacte Google Cloud o apoio técnico.

Google Cloud O apoio técnico precisa dos registos do serviço de identidade do GKE e da especificação do OIDC para diagnosticar e resolver problemas do OIDC.

Problemas comuns de OIDC

Se tiver problemas com a autenticação OIDC, reveja os seguintes problemas comuns. Siga as orientações sobre como resolver o problema.

Não estão disponíveis pontos finais para o serviço "ais"

Quando guarda o recurso ClientConfig, é devolvida a seguinte mensagem de erro:

  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"

Este erro é causado pelo ponto final do serviço de identidade do GKE não saudável. O pod do serviço de identidade do GKE não consegue publicar o webhook de validação.

Para confirmar que o pod do serviço de identidade do GKE não está em bom estado, execute o seguinte comando:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

O resultado de exemplo seguinte significa que o pod do GKE Identity Service está a falhar:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Para compreender o motivo pelo qual o pod tem um problema, consulte os eventos do pod:

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

Substitua KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

O exemplo de saída seguinte comunica um erro de autorizaçã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 comunicarem um problema, continue a resolução de problemas nas áreas afetadas. Se precisar de assistência adicional, contacte Google Cloud o apoio técnico.

Falha ao ler bytes de resposta do servidor

Pode ver os seguintes erros nos registos do serviço de identidade do GKE:

  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.

Estes erros de rede podem aparecer nos registos de uma das seguintes formas:

Aparecem esparsamente no registo: os erros esparsos provavelmente não são o problema principal e podem ser problemas de rede intermitentes.

O plug-in OIDC do GKE Identity Service tem um processo de daemon para sincronizar periodicamente o URL de descoberta do OIDC a cada 5 segundos. Se a ligação de rede for instável, este pedido de saída pode falhar. A falha ocasional não afeta a autenticação OIDC. Os dados em cache existentes podem ser reutilizados.

Se encontrar erros de peças sobresselentes nos registos, continue com os passos de resolução de problemas adicionais.
Aparecer constantemente no registo ou o GKE Identity Service nunca atingir com êxito o ponto final conhecido: estes problemas constantes indicam um problema de conetividade entre o GKE Identity Service e o seu fornecedor de identidade OIDC.

Os seguintes passos de resolução de problemas podem ajudar a diagnosticar estes problemas de conetividade:
1. Certifique-se de que uma firewall não está a bloquear os pedidos de saída do GKE Identity Service.
2. Verifique se o servidor do fornecedor de identidade está a ser executado corretamente.
3. Verifique se o URL do emissor OIDC no recurso ClientConfig está configurado corretamente.
4. Se ativou o campo de proxy no recurso ClientConfig, reveja o estado ou o registo do seu servidor proxy de saída.
5. Teste a conetividade entre o pod do GKE Identity Service e o servidor do fornecedor de identidade OIDC.

Tem de ter sessão iniciada no servidor (não autorizado)

Quando tenta iniciar sessão através da autenticação OIDC, pode receber a seguinte mensagem de erro:

  You must be logged in to the server (Unauthorized)

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

Para determinar o problema, reveja as secções anteriores para Verificar a especificação OIDC no seu cluster e Configurar o recurso ClientConfig.

Falha ao fazer o pedido do autenticador de webhook

Nos registos do GKE Identity Service, pode ver 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

Este erro indica que o servidor da API não consegue estabelecer a ligação ao pod do serviço de identidade do GKE.

Para verificar se é possível aceder ao ponto final do serviço de identidade do GKE a partir do exterior, execute o seguinte 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 pela morada do seu servidor de API.

A resposta esperada é um código de estado HTTP 400. Se o pedido tiver excedido o tempo limite, reinicie o pod do serviço de identidade do GKE. Se o erro persistir, significa que o servidor HTTP do serviço de identidade do GKE não é iniciado. Para receber assistência adicional, contacte o Google Cloud apoio técnico.

URL de início de sessão não encontrado

O seguinte problema ocorre quando a Google Cloud consola não consegue aceder ao fornecedor de identidade. Uma tentativa de início de sessão é redirecionada para uma página com um erro URL not found

Para resolver este problema, reveja os seguintes passos de resolução de problemas. Após cada passo, tente iniciar sessão novamente:

Se o fornecedor de identidade não estiver acessível através da Internet pública, ative o proxy HTTP OIDC para iniciar sessão através da Google Cloud consola. Edite o recurso personalizado ClientConfig e defina useHTTPProxy como true:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.
Se o proxy HTTP estiver ativado e continuar a ter este erro, pode haver um problema com o início do proxy. Veja os registos do proxy:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.

Mesmo que o seu fornecedor de identidade tenha uma AC conhecida, tem de fornecer um valor para oidc.caPath no seu recurso personalizado ClientConfig para que o proxy HTTP seja iniciado com êxito.
Se o servidor de autorização pedir consentimento e não tiver incluído os parâmetros extraparam prompt=consent, edite o recurso personalizado ClientConfig e adicione prompt=consent aos parâmetros extraparams:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores.
Se as definições de configuração forem alteradas no serviço de armazenamento, pode ter de terminar sessão explicitamente nas sessões existentes. Na Google Cloud consola, aceda à página de detalhes do cluster e selecione Terminar sessão.

Resolva problemas de LDAP

Se tiver problemas com a autenticação LDAP, certifique-se de que configurou o seu ambiente seguindo um dos documentos de configuração adequados:

Também tem de se certificar de que preenche o segredo da conta de serviço LDAP e que configurou o recurso ClientConfig para ativar a autenticação LDAP.

Reveja o guia de resolução de problemas do fornecedor de identidade do serviço de identidade do GKE para ver informações sobre como ativar e rever os registos de identidade e testar a conetividade. Depois de confirmar que o serviço de identidade do GKE funciona como esperado ou identificar um problema, reveja as seguintes informações de resolução de problemas do LDAP.

Verifique se a autenticação LDAP está ativada

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

Examine os registos do serviço de identidade do GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
O exemplo de resultado seguinte mostra que a autenticação LDAP está corretamente ativada:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Se a autenticação LDAP não estiver ativada corretamente, são apresentados erros semelhantes ao exemplo seguinte:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Reveja os erros específicos comunicados e tente corrigi-los.

Teste a autenticação LDAP

Para usar a funcionalidade LDAP, use uma estação de trabalho com a IU e o navegador ativados. Não pode realizar estes passos a partir de uma sessão de SSH baseada em texto. Para testar se a autenticação LDAP funciona corretamente no seu cluster, conclua os seguintes passos:

Transfira a CLI do Google Cloud.
Para gerar o ficheiro de configuração de início de sessão, 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 ficheiro kubeconfig do cluster de utilizadores.
Para autenticar o utilizador, execute o seguinte comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Substitua o seguinte:
- CLUSTER_NAME com o nome do cluster de utilizadores ao qual se quer ligar.
- AUTH_KUBECONFIG com o novo ficheiro kubeconfig para criar um que inclua as credenciais para aceder ao seu cluster. Para mais informações, consulte Autentique-se no cluster.
Deve receber uma página de consentimento de início de sessão aberta no navegador de Internet predefinido da sua estação de trabalho local. Forneça informações de autenticação válidas para um utilizador neste pedido de início de sessão.

Depois de concluir com êxito o passo de início de sessão anterior, é gerado um ficheiro kubeconfig no seu diretório atual.
Para testar o novo ficheiro kubeconfig que inclui as suas credenciais, liste os pods no cluster de utilizadores:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Substitua AUTH_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de utilizadores que foi gerado no passo anterior.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Problemas comuns de LDAP

Se tiver problemas com a autenticação LDAP, reveja os seguintes problemas comuns. Siga as orientações sobre como resolver o problema.

Os utilizadores não conseguem autenticar com vírgulas no respetivo CN

Quando usa o LDAP, pode ter problemas em que os utilizadores não conseguem autenticar se o respetivo CN contiver uma vírgula, como CN="a,b". Se ativar o registo de depuração para o GKE Identity Service, é apresentada a seguinte mensagem de erro:

  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.

Este problema ocorre porque o plug-in LDAP do GKE Identity Service escapa duas vezes à vírgula. Este problema só ocorre nas versões 1.13 e anteriores do Google Distributed Cloud.

Para corrigir este problema, conclua um dos seguintes passos:

Atualize o cluster para o Google Distributed Cloud 1.13 ou posterior.
Em alternativa, escolha um identifierAttribute diferente, como sAMAccountName, em vez de usar o CN.
Remova as vírgulas do CN no seu diretório LDAP.

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

Com a CLI gcloud anthos-auth 1.4.2, pode ver a seguinte mensagem de erro quando executa 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 registo do GKE Identity Service, também vê 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 este erro, conclua os seguintes passos:

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

Problemas comuns

Esta secção detalha problemas de autenticação comuns e como os resolver.

Acesso perdido à estação de trabalho de administração devido a um erro da chave SSH `permission denied`

O seguinte erro ocorre quando tenta estabelecer ligação à sua estação de trabalho de administração e recebe uma mensagem "Permission denied" semelhante ao seguinte exemplo:

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

Este erro ocorre devido à utilização de uma chave privada incorreta ou à ausência de uma chave quando se liga à estação de trabalho de administração através de SSH.

Para resolver este problema, encontre e use a chave SSH correta. Se não conseguir encontrar a chave SSH correta, gere um novo par de chaves SSH para a estação de trabalho do administrador através dos seguintes passos:

Crie uma VM de resgate temporária. Esta VM de recuperação tem de se ligar à mesma rede e armazenamento de dados que a VM da estação de trabalho de administração atual.
Desligue a VM da estação de trabalho de administração e a VM de recuperação.
Anexe o disco de dados da VM da estação de trabalho de administração à VM de recuperação. O disco de dados tem geralmente 512 MB, a menos que tenha especificado um tamanho de disco diferente no ficheiro de configuração da estação de trabalho de administração, que é distinto do disco de arranque.
Ligue a VM de resgate.
Estabeleça ligação à VM de resgate através do SSH.
No computador local, gere um novo par de chaves SSH.
No seu computador local, copie a nova chave pública de SSH para a VM de recuperação através do comando ssh-copy-id:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Substitua o seguinte:
- NEW_SSH_KEY com o nome da nova chave SSH que criou no passo anterior.
- RESCUE_VM com o endereço IP ou o FQDN da sua VM de recuperação.
Na VM de recuperação, monte o disco de dados na VM de recuperação:
```
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 recuperação, copie a nova chave pública de SSH para o ficheiro authorized_keys no disco de dados montado da VM da estação de trabalho de administrador.

Veja o conteúdo do ficheiro authorized_keys na VM de recuperação, que inclui a nova chave pública SSH copiada através do comando ssh-copy-id num passo anterior:
```
ls ~/.ssh/authorized_keys
```
Copie a última entrada da chave pública de SSH do ficheiro authorized_keys e, em seguida, feche o ficheiro.
Edite o ficheiro authorized_keys no disco de dados montado a partir da VM da estação de trabalho do administrador:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Cole o conteúdo da chave pública de SSH do ficheiro authorized_keys da VM de recuperação.
Guarde e feche o ficheiro authorized_keys no disco de dados montado a partir da VM da estação de trabalho do administrador.
Verifique se os ficheiros em /mnt/ext-disk/.ssh/ têm as autorizações corretas aplicadas:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Saia da ligação SSH à VM de resgate.
Encerre a VM de resgate.
Desassocie o disco de dados da VM de recuperação e volte a associar o disco à VM da estação de trabalho do administrador.
Ligue a estação de trabalho de administração.
Depois de a VM estar em execução com êxito, estabeleça ligação à estação de trabalho de administração através de SSH e do novo par de chaves SSH.
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
Substitua o seguinte:
- NEW_SSH_KEY com o nome da nova chave SSH que criou num passo anterior e copiou para a VM da estação de trabalho de administração.
- RESCUE_VM com o endereço IP ou o FQDN da VM da estação de trabalho de administrador.
Confirme se consegue estabelecer ligação com êxito através de SSH.
Elimine a VM de recuperação.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte:

Requisitos para abrir um registo de apoio técnico.
Ferramentas para ajudar a resolver problemas, como registos e métricas.
Componentes suportados, versões e funcionalidades do Google Distributed Cloud para VMware (apenas software).