Los clústeres de Anthos en VMware ahora son Google Distributed Cloud (solo software) para VMware. Para obtener más información, consulta la descripción general del producto.

Esta página se ha traducido con Cloud Translation API.

Solucionar problemas de autenticación de Google Distributed Cloud

Este documento ayuda a solucionar problemas de autenticación en Google Distributed Cloud. Se proporciona información y directrices generales para solucionar problemas, así como información específica sobre OpenID Connect (OIDC) y el protocolo ligero de acceso a directorios (LDAP).

La autenticación OIDC y LDAP usa Identity Service para GKE. Para poder usar GKE Identity Service con Google Distributed Cloud, debes configurar un proveedor de identidades. Si no has configurado un proveedor de identidades para GKE Identity Service, sigue las instrucciones de uno de los proveedores más habituales:

Solucionar problemas generales

Los siguientes consejos para solucionar problemas pueden ayudarte con los problemas generales de autenticación y autorización de Google Distributed Cloud. Si estos problemas no se aplican o tienes problemas con OIDC o LDAP, ve a la sección sobre cómo solucionar problemas de GKE Identity Service.

Mantener `gcloud anthos auth` actualizado

Puedes evitar muchos problemas habituales comprobando que los componentes de tu instalación de gcloud anthos auth estén actualizados.

Hay dos elementos que deben verificarse. El comando gcloud anthos auth tiene lógica en el componente principal de Google Cloud CLI y un componente anthos-auth empaquetado por separado.

Para actualizar Google Cloud CLI, sigue estos pasos:
```
gcloud components update
```
Para actualizar el componente anthos-auth, sigue estos pasos:
```
gcloud components install anthos-auth
```

Configuración de proveedor no válida

Si la configuración de tu proveedor de identidades no es válida, verás una pantalla de error de tu proveedor de identidades después de hacer clic en LOGIN. Sigue las instrucciones específicas del proveedor para configurar correctamente el proveedor o tu clúster.

Configuración no válida

Si la consola no puede leer la configuración de OIDC de tu clúster, el botón LOGIN estará inhabilitado. Google Cloud Para solucionar problemas con la configuración de OIDC de tu clúster, consulta la sección Solucionar problemas de OIDC de este documento.

Permisos no válidos

Si completas el flujo de autenticación, pero sigues sin ver los detalles del clúster, asegúrate de haber concedido los permisos de RBAC correctos a la cuenta que has usado con OIDC. Puede que sea una cuenta distinta a la que usas para acceder a la consola Google Cloud .

Falta el token de actualización

El siguiente problema se produce cuando el servidor de autorización solicita el consentimiento, pero no se ha proporcionado el parámetro de autenticación necesario.

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

Para solucionar este problema, añade prompt=consent al campo authentication.oidc.extraParams de tu recurso ClientConfig. A continuación, vuelve a generar el archivo de autenticación del cliente.

El token de actualización ha caducado

El siguiente problema se produce cuando el token de actualización del archivo kubeconfig ha caducado:

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

Para solucionar este problema, vuelve a ejecutar el comando gcloud anthos auth login.

gcloud anthos auth login falla con `proxyconnect tcp`

Este problema se produce cuando hay un error en las configuraciones de las variables de entorno https_proxy o HTTPS_PROXY. Si se especifica un https:// en las variables de entorno, es posible que las bibliotecas de clientes HTTP de GoLang fallen si el proxy está configurado para gestionar conexiones HTTPS con otros protocolos, como SOCK5.

Puede que se devuelva el siguiente mensaje de error de ejemplo:

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

Para solucionar este problema, modifique las variables de entorno https_proxy y HTTPS_PROXY para omitir https:// prefix. En Windows, modifica las variables de entorno del sistema. Por ejemplo, cambia el valor de la variable de entorno https_proxy de https://webproxy.example.com:8000 a webproxy.example.com:8000.

Fallo al acceder al clúster cuando se usa kubeconfig generado por `gcloud anthos auth login`

Este problema se produce cuando el servidor de la API de Kubernetes no puede autorizar al usuario. Esto puede ocurrir si faltan los RBACs adecuados o son incorrectos, o si hay un error en la configuración de OIDC del clúster. Puede que se muestre el siguiente error de ejemplo:

Unauthorized

Para solucionar este problema, siga estos pasos:

En el archivo kubeconfig generado por gcloud anthos auth login, copia el valor de id-token.

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

Instala jwt-cli y ejecuta lo siguiente:
```
jwt ID_TOKEN
```
Verifica la configuración de OIDC.

El recurso ClientConfig tiene los campos group y username. Estos campos se usan para definir las marcas --oidc-group-claim y --oidc-username-claim en el servidor de la API de Kubernetes. Cuando se le presenta el token al servidor de la API, este lo reenvía al servicio de identidad de GKE, que devuelve los valores group-claim y username-claim extraídos al servidor de la API. El servidor de la API usa la respuesta para verificar que el grupo o el usuario correspondiente tiene los permisos correctos.

Verifica que las reclamaciones definidas para group y user en el recurso ClientConfig estén presentes en el token de ID.
Comprueba los RBACs que se han aplicado.

Verifica que haya un control de acceso basado en roles con los permisos correctos para el usuario especificado en username-claim o para uno de los grupos indicados en group-claim en el paso anterior. El nombre del usuario o del grupo en el control de acceso basado en roles debe ir precedido del prefijo usernameprefix o groupprefix que se haya especificado en el recurso ClientConfig.

Si usernameprefix está en blanco y username tiene un valor distinto de email, el prefijo será issuerurl# de forma predeterminada. Para inhabilitar los prefijos de nombre de usuario, asigna el valor - a usernameprefix.

Para obtener más información sobre los prefijos de usuarios y grupos, consulta Autenticación con OIDC.

Nota: El servidor de la API de Kubernetes trata la barra invertida como un carácter de escape. Si el nombre del usuario o del grupo contiene \\, el servidor de la API lo lee como un solo \ al analizar el token de ID. Por lo tanto, el enlace de rol RBAC aplicado a este usuario o grupo solo debe contener una barra invertida. De lo contrario, puede que se produzca un error Unauthorized.

ClientConfig recurso:
```
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"
  ],
...
}
```
Los siguientes enlaces RBAC conceden a este grupo y a este usuario el rol de clúster pod-reader. Observa la barra única en el campo de nombre en lugar de una barra doble:

Agrupar 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
```
Consulta los registros del servidor de la API de Kubernetes.

Si el complemento OIDC configurado en el servidor de la API de Kubernetes no se inicia correctamente, el servidor de la API devuelve un error Unauthorized cuando se le presenta el token de ID. Para ver si ha habido algún problema con el complemento OIDC en el servidor de la API, ejecuta el siguiente comando:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Haz los cambios siguientes:
- USER_CLUSTER_NAME: el nombre del clúster de usuarios del que quieres ver los registros.
- ADMIN_CLUSTER_KUBECONFIG: el archivo kubeconfig del clúster de administrador.

Este problema se produce cuando el archivo kubeconfig transferido a gkectl create-login-config no es de un clúster de usuario o el recurso ClientConfig no se ha creado durante la creación del clúster.

Error getting clientconfig using KUBECONFIG

Para solucionar este problema, asegúrate de que tienes el archivo kubeconfig correcto para tu clúster de usuario. A continuación, comprueba si el recurso ClientConfig está en el clúster:

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

Sustituye USER_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.

Este problema se produce si intenta escribir datos de configuración de inicio de sesión que contengan un nombre de clúster que ya exista en el archivo de destino. Cada archivo de configuración de inicio de sesión debe contener nombres de clúster únicos.

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, utilice la marca --output para especificar un nuevo archivo de destino.

Si no proporcionas --output, estos datos de configuración de inicio de sesión se escribirán en un archivo llamado kubectl-anthos-config.yaml en el directorio actual.

Solucionar problemas de OIDC

Cuando la autenticación OIDC no funciona en Google Distributed Cloud, normalmente es porque la especificación OIDC del recurso ClientConfig no se ha configurado correctamente. El recurso ClientConfig proporciona instrucciones para revisar los registros y la especificación de OIDC, lo que ayuda a identificar la causa de un problema de OIDC.

Consulta la guía de solución de problemas del proveedor de identidades de Identity Service para GKE para obtener información sobre cómo habilitar y revisar los registros de identidad, así como probar la conectividad. Una vez que hayas confirmado que el servicio de gestión de identidades de GKE funciona correctamente o hayas identificado un problema, consulta la siguiente información para solucionar problemas de OIDC.

Comprobar la especificación de OIDC en tu clúster

La información de OIDC de tu clúster se especifica en el recurso ClientConfig del espacio de nombres kube-public.

Usa kubectl get para imprimir el recurso OIDC de tu clúster de usuarios:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Revise los valores de los campos para confirmar que la especificación está configurada correctamente para su proveedor de OIDC.
Si detectas un problema de configuración en la especificación, vuelve a configurar OIDC.
Si no puedes diagnosticar y resolver el problema por tu cuenta, ponte en contacto con el equipo de Google Cloud asistencia.

Google Cloud El equipo de Asistencia necesita los registros de GKE Identity Service y la especificación de OIDC para diagnosticar y resolver problemas de OIDC.

Verificar que la autenticación OIDC esté habilitada

Antes de probar la autenticación OIDC, comprueba que esté habilitada en tu clúster.

Examina los registros de Identity Service de GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
En el siguiente ejemplo de salida se muestra que la autenticación OIDC está habilitada correctamente:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Si la autenticación OIDC no está habilitada correctamente, se mostrarán errores similares al siguiente ejemplo:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos que se hayan notificado e intenta corregirlos.

Probar la autenticación OIDC

Para usar la función OIDC, utiliza una estación de trabajo con la interfaz de usuario y el navegador habilitados. No puedes seguir estos pasos desde una sesión SSH basada en texto. Para comprobar que OIDC funciona correctamente en tu clúster, sigue estos pasos:

Descarga la CLI de Google Cloud.
Para generar el archivo de configuración de inicio de sesión, ejecuta el siguiente comando de gcloud anthos create-login-config:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Para autenticar al usuario, ejecuta el siguiente comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Haz los cambios siguientes:
- CLUSTER_NAME con el nombre del clúster de usuario al que quieras conectarte.
- AUTH_KUBECONFIG con el nuevo archivo kubeconfig para crear un archivo que incluya las credenciales para acceder a tu clúster. Para obtener más información, consulta Autenticarse en el clúster.
Deberías ver una página de consentimiento de inicio de sesión en el navegador web predeterminado de tu estación de trabajo local. Proporciona información de autenticación válida para un usuario en esta petición de inicio de sesión.

Una vez que hayas completado correctamente el paso de inicio de sesión anterior, se generará un archivo kubeconfig en tu directorio actual.
Para probar el nuevo archivo kubeconfig que incluye tus credenciales, enumera los pods de tu clúster de usuario:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Sustituye AUTH_KUBECONFIG por la ruta del nuevo archivo kubeconfig que se ha generado en el paso anterior.

Puede que se devuelva el siguiente mensaje de ejemplo, que muestra que puedes autenticarte correctamente, pero que no hay controles de acceso basados en roles (RBACs) asignados a la cuenta:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Revisar los registros de autenticación OIDC

Si no puedes autenticarte con OIDC, los registros de GKE Identity Service te proporcionarán la información más relevante y útil para depurar el problema.

Usa kubectl logs para imprimir los registros de Identity Service for GKE:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Revisa los registros para detectar errores que puedan ayudarte a diagnosticar problemas de OIDC.

Por ejemplo, el recurso ClientConfig podría tener un error tipográfico en el campo issuerURL, como htps://accounts.google.com (falta una t en https). Los registros del servicio de identidad de GKE contendrían una entrada como la siguiente:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Si identificas un problema de configuración en los registros, vuelve a configurar OIDC y corrige los problemas de configuración.
Si no puedes diagnosticar y resolver el problema por tu cuenta, ponte en contacto con el equipo de Google Cloud asistencia.

Google Cloud El equipo de Asistencia necesita los registros de GKE Identity Service y la especificación de OIDC para diagnosticar y resolver problemas de OIDC.

Problemas habituales de OIDC

Si tienes problemas con la autenticación OIDC, consulta los siguientes problemas habituales. Sigue las instrucciones para solucionar el problema.

No hay endpoints disponibles para el servicio "ais"

Cuando guardas el recurso ClientConfig, se devuelve el siguiente mensaje de error:

  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 error se debe a que el endpoint de Identity Service for GKE no está en buen estado. El pod de GKE Identity Service no puede servir el webhook de validación.

Para confirmar que el pod de GKE Identity Service no está en buen estado, ejecuta el siguiente comando:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.

El siguiente ejemplo de salida significa que tu pod de Identity Service para GKE falla:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Para saber por qué tiene un problema el pod, consulta los eventos del pod:

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

Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.

En el siguiente ejemplo de salida se informa de un error de permisos al extraer la imagen:

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"

Si el informe de eventos de Pod indica que hay un problema, sigue solucionándolo en las áreas afectadas. Si necesitas más ayuda, ponte en contacto con el Google Cloud equipo de Asistencia.

No se han podido leer los bytes de respuesta del servidor

Es posible que veas los siguientes errores en los registros de 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.

Estos errores de red pueden aparecer en los registros de una de las siguientes formas:

Aparecen de forma esporádica en el registro: es probable que los errores esporádicos no sean el problema principal y que se deban a problemas de red intermitentes.

El complemento OIDC de GKE Identity Service tiene un proceso de daemon para sincronizar periódicamente la URL de Discovery de OIDC cada 5 segundos. Si la conexión de red es inestable, es posible que esta solicitud de salida falle. Los errores ocasionales no afectan a la autenticación OIDC. Los datos almacenados en caché se pueden reutilizar.

Si encuentras errores de repuesto en los registros, sigue otros pasos para solucionar el problema.
Aparece constantemente en el registro o el servicio de identidad de GKE nunca llega correctamente al endpoint conocido: estos problemas constantes indican que hay un problema de conectividad entre el servicio de identidad de GKE y tu proveedor de identidad de OIDC.

Los siguientes pasos pueden ayudarte a diagnosticar estos problemas de conectividad:
1. Asegúrate de que ningún cortafuegos esté bloqueando las solicitudes salientes del servicio de identidad de GKE.
2. Comprueba que el servidor del proveedor de identidades funciona correctamente.
3. Verifica que la URL del emisor de OIDC del recurso ClientConfig esté configurada correctamente.
4. Si ha habilitado el campo de proxy en el recurso ClientConfig, consulte el estado o el registro de su servidor proxy de salida.
5. Prueba la conectividad entre tu pod de Identity Service para GKE y el servidor del proveedor de identidades OIDC.

Debes haber iniciado sesión en el servidor (no autorizado)

Cuando intentas iniciar sesión mediante la autenticación OIDC, es posible que recibas el siguiente mensaje de error:

  You must be logged in to the server (Unauthorized)

Este error es un problema general de autenticación de Kubernetes que no proporciona información adicional. Sin embargo, este error indica un problema de configuración.

Para determinar el problema, consulta las secciones anteriores para comprobar la especificación de OIDC en tu clúster y configurar el recurso ClientConfig.

No se ha podido realizar la solicitud del autenticador de webhook

En los registros del servicio de identidad de GKE, puede que veas el siguiente error:

  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 error indica que el servidor de la API no puede establecer la conexión con el pod del servicio de identidad de GKE.

Para verificar si se puede acceder al endpoint de Identity Service para GKE desde fuera, ejecuta el siguiente 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 '{}'
```
Sustituye APISERVER_HOST por la dirección de tu servidor de APIs.

La respuesta esperada es un código de estado HTTP 400. Si la solicitud ha agotado el tiempo de espera, reinicia el pod de Identity Service para GKE. Si el error persiste, significa que el servidor HTTP de GKE Identity Service no se inicia. Si necesitas más ayuda, ponte en contacto con el equipo de Asistencia de Google Cloud .

No se ha encontrado la URL de inicio de sesión

El siguiente problema se produce cuando la consola no puede acceder al proveedor de identidades. Google Cloud Se redirige un intento de inicio de sesión a una página con un error URL not found.

Para solucionar este problema, sigue los pasos que se indican a continuación. Después de cada paso, intenta iniciar sesión de nuevo:

Si no se puede acceder al proveedor de identidades a través de Internet público, habilita el proxy HTTP de OIDC para iniciar sesión con la Google Cloud consola. Edite el recurso personalizado ClientConfig y asigne el valor true a useHTTPProxy:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sustituye USER_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Si el proxy HTTP está habilitado y sigues teniendo este error, puede que haya un problema con el inicio del proxy. Consulta los registros del proxy:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sustituye USER_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.

Aunque tu proveedor de identidades tenga una autoridad de certificación conocida, debes proporcionar un valor para oidc.caPath en tu recurso personalizado ClientConfig para que el proxy HTTP se inicie correctamente.
Si el servidor de autorización solicita el consentimiento y no has incluido los parámetros extraparam prompt=consent, edita el recurso personalizado ClientConfig y añade prompt=consent a los parámetros extraparams:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Sustituye USER_CLUSTER_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Si se cambian los ajustes de configuración en el servicio de almacenamiento, es posible que tengas que cerrar sesión explícitamente en las sesiones actuales. En la Google Cloud consola, ve a la página de detalles del clúster y selecciona Cerrar sesión.

Solucionar problemas de LDAP

Si tienes problemas con la autenticación LDAP, asegúrate de haber configurado tu entorno siguiendo uno de los documentos de configuración adecuados:

También debes asegurarte de rellenar el secreto de la cuenta de servicio LDAP y de configurar el recurso ClientConfig para habilitar la autenticación LDAP.

Consulta la guía de solución de problemas del proveedor de identidades de Identity Service para GKE para obtener información sobre cómo habilitar y revisar los registros de identidad, así como probar la conectividad. Después de confirmar que el servicio de gestión de identidades de GKE funciona correctamente o de identificar un problema, consulta la siguiente información para solucionar problemas de LDAP.

Verificar que la autenticación LDAP esté habilitada

Antes de probar la autenticación LDAP, comprueba que esté habilitada en tu clúster.

Examina los registros de Identity Service de GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
El siguiente ejemplo de salida muestra que la autenticación LDAP se ha habilitado correctamente:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Si la autenticación LDAP no está habilitada correctamente, se mostrarán errores similares al siguiente ejemplo:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos que se hayan notificado e intenta corregirlos.

Probar la autenticación LDAP

Para usar la función LDAP, utiliza una estación de trabajo con la interfaz de usuario y el navegador habilitados. No puedes seguir estos pasos desde una sesión SSH basada en texto. Para comprobar que la autenticación LDAP funciona correctamente en tu clúster, sigue estos pasos:

Descarga la CLI de Google Cloud.
Para generar el archivo de configuración de inicio de sesión, ejecuta el siguiente comando gcloud anthos create-login-config:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Sustituye KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario.
Para autenticar al usuario, ejecuta el siguiente comando:
```
gcloud anthos auth login --cluster CLUSTER_NAME \
  --login-config user-login-config.yaml \
  --kubeconfig AUTH_KUBECONFIG
```
Haz los cambios siguientes:
- CLUSTER_NAME con el nombre del clúster de usuario al que quieras conectarte.
- AUTH_KUBECONFIG con el nuevo archivo kubeconfig para crear un archivo que incluya las credenciales para acceder a tu clúster. Para obtener más información, consulta Autenticarse en el clúster.
Deberías ver una página de consentimiento de inicio de sesión en el navegador web predeterminado de tu estación de trabajo local. Proporciona información de autenticación válida para un usuario en esta petición de inicio de sesión.

Una vez que hayas completado correctamente el paso de inicio de sesión anterior, se generará un archivo kubeconfig en tu directorio actual.
Para probar el nuevo archivo kubeconfig que incluye tus credenciales, enumera los pods de tu clúster de usuario:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Sustituye AUTH_KUBECONFIG por la ruta al archivo kubeconfig de tu clúster de usuario que se generó en el paso anterior.
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Problemas habituales de LDAP

Si tienes problemas con la autenticación LDAP, consulta los siguientes problemas habituales. Sigue las instrucciones para solucionar el problema.

Los usuarios no pueden autenticarse si su CN incluye comas

Si usas LDAP, puede que tengas problemas para autenticar a los usuarios si su CN contiene una coma, como CN="a,b". Si habilitas el registro de depuración de GKE Identity Service, se muestra el siguiente mensaje de error:

  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 se produce porque el complemento LDAP de GKE Identity Service escapa dos veces la coma. Este problema solo se produce en las versiones 1.13 y anteriores de Google Distributed Cloud.

Para solucionar este problema, siga uno de estos pasos:

Actualiza tu clúster a Google Distributed Cloud 1.13 o una versión posterior.
Elige otro identifierAttribute, como sAMAccountName, en lugar de usar el CN.
Quita las comas del CN de tu directorio LDAP.

Fallo de autenticación con Google Cloud CLI 1.4.2

Con Google Cloud CLI anthos-auth 1.4.2, es posible que veas el siguiente mensaje de error al ejecutar el 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

En el registro del servicio de identidad de GKE, también se muestra el siguiente error:

  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 solucionar este error, siga estos pasos:

Comprueba si usas la versión 1.4.2 de Google Cloud CLI anthos-auth:
```
gcloud anthos auth version
```
En el siguiente ejemplo de salida se muestra que la versión es 1.4.2:
```
Current Version: v1.4.2
```
Si usas la versión 1.4.2 de Google Cloud CLI anthos-auth, actualiza a la versión 1.4.3 o a una posterior.

Problemas más comunes

En esta sección se detallan los problemas de autenticación habituales y cómo resolverlos.

Se ha perdido el acceso a la estación de trabajo de administrador debido a un error de la clave SSH `permission denied`

Se produce el siguiente error cuando intentas conectarte a tu estación de trabajo de administrador y recibes un mensaje "Permission denied" similar al siguiente ejemplo:

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

Este error se produce porque se usa una clave privada incorrecta o no se usa ninguna clave al conectarse a la estación de trabajo de administrador mediante SSH.

Para solucionar este problema, busca y usa la clave SSH correcta. Si no encuentras la clave SSH correcta, genera un nuevo par de claves SSH para la estación de trabajo del administrador siguiendo estos pasos:

Crea una VM de rescate temporal. Esta VM de recuperación debe conectarse a la misma red y al mismo almacén de datos que la VM de estación de trabajo de administrador actual.
Apaga la VM de la estación de trabajo de administrador y la VM de rescate.
Adjunta el disco de datos de la VM de estación de trabajo de administrador a la VM de rescate. El disco de datos suele tener 512 MB, a menos que hayas especificado un tamaño diferente en el archivo de configuración de la estación de trabajo de administrador, que es distinto del disco de arranque.
Enciende la VM de rescate.
Conéctate a la VM de rescate mediante SSH.
En tu ordenador local, genera un nuevo par de claves SSH.
En tu ordenador local, copia la nueva clave pública SSH en la VM de rescate con el comando ssh-copy-id:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Haz los cambios siguientes:
- NEW_SSH_KEY con el nombre de la nueva clave SSH que has creado en el paso anterior.
- RESCUE_VM con la dirección IP o el FQDN de tu VM de recuperación.
En la VM de rescate, monta el disco de datos en la VM de rescate:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Sustituye DEVICE por el identificador único de tu disco, como /dev/sdb1.
En la VM de rescate, copia la nueva clave pública SSH en el archivo authorized_keys del disco de datos montado de tu VM de estación de trabajo de administrador.

Consulta el contenido del archivo authorized_keys en la VM de rescate, que incluye la nueva clave pública SSH copiada con el comando ssh-copy-id en un paso anterior:
```
ls ~/.ssh/authorized_keys
```
Copia la última entrada de clave pública SSH del archivo authorized_keys y, a continuación, cierra el archivo.
Edita el archivo authorized_keys en el disco de datos montado desde tu máquina virtual de estación de trabajo de administrador:
```
vi /mnt/ext-disk/.ssh/authorized_keys
```
Pega el contenido de la clave pública SSH del archivo authorized_keys de tu máquina virtual de rescate.
Guarda y cierra el archivo authorized_keys en el disco de datos montado desde tu máquina virtual de estación de trabajo de administrador.

Verifica que los archivos de /mnt/ext-disk/.ssh/ tengan los permisos correctos:

chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*

Cierra la conexión SSH a la VM de rescate.
Apaga la VM de rescate.
Desconecta el disco de datos de la VM de rescate y vuelve a conectarlo a la VM de la estación de trabajo de administrador.
Enciende la estación de trabajo de administrador.
Una vez que la VM se esté ejecutando correctamente, conéctate a la estación de trabajo de administrador mediante SSH y el nuevo par de claves SSH.
```
ssh -i ~/.ssh/NEW_SSH_KEY ubuntu@ADMIN_VM
```
Haz los cambios siguientes:
- NEW_SSH_KEY con el nombre de la nueva clave SSH que has creado en un paso anterior y copiado en la VM de la estación de trabajo de administrador.
- RESCUE_VM con la dirección IP o el FQDN de tu máquina virtual de la estación de trabajo de administrador.
Comprueba que puedes conectarte correctamente mediante SSH.
Elimina la VM de rescate.

Siguientes pasos

Si necesitas más ayuda, ponte en contacto con el servicio de atención al cliente de Cloud.

También puedes consultar la sección Obtener asistencia para obtener más información sobre los recursos de asistencia, incluidos los siguientes:

Requisitos para abrir un caso de asistencia.
Herramientas para ayudarte a solucionar problemas, como registros y métricas.
Componentes, versiones y funciones compatibles de Google Distributed Cloud para VMware (solo software).