Se usó la API de Cloud Translation para traducir esta página.

Soluciona problemas de autenticación de GKE en VMware

En este documento, encontrarás ayuda para solucionar problemas de autenticación en Google Distributed Cloud Virtual for VMware. Se proporciona información y orientación general sobre la solución de problemas, junto con información específica para OpenID Connect (OIDC) y el Protocolo ligero de acceso a directorios (LDAP).

La autenticación de OIDC y LDAP usa GKE Identity Service. Antes de poder usar GKE Identity Service con Google Distributed Cloud Virtual for VMware, debes configurar un proveedor de identidad. Si no configuraste un proveedor de identidad para GKE Identity Service, sigue las instrucciones de uno de los siguientes proveedores más comunes:

Si necesitas asistencia adicional, comunícate con Atención al cliente de Cloud.

Solución de problemas generales

Las siguientes sugerencias para solucionar problemas pueden ayudarte con problemas generales de autenticación y autorización con Google Distributed Cloud Virtual for VMware. Si estos problemas no aplican o tienes problemas con OIDC o LDAP, continúa con la sección sobre solución de problemas de GKE Identity Service.

Mantén `gcloud anthos auth` actualizado

Para evitar muchos problemas habituales, verifica que los componentes de la instalación de gcloud anthos auth estén actualizados.

Hay dos elementos que se deben verificar. 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, haz lo siguiente:
```
gcloud components update
```
Para actualizar el componente anthos-auth, haz lo siguiente:
```
gcloud components install anthos-auth
```

La configuración del proveedor no es válida

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

La configuración no es válida

Si la consola de Google Cloud no puede leer la configuración de OIDC de tu clúster, el botón ACCEDER está inhabilitado. Para solucionar los problemas de la configuración de OIDC del clúster, consulta la siguiente sección para solucionar problemas de OIDC en este documento.

Los permisos no son válidos

Si completas el flujo de autenticación, pero aún no ves los detalles del clúster, asegúrate de haber otorgado los permisos de RBAC correctos a la cuenta que usaste con OIDC. Puede ser una cuenta diferente de la que usas para acceder a la consola de 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 proporcionó el parámetro de autenticación necesario.

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

Para resolver este problema, en tu recurso ClientConfig, agrega prompt=consent al campo authentication.oidc.extraParams. Luego, vuelve a generar el archivo de autenticación del cliente.

Token de actualización vencido

El siguiente problema ocurre cuando vence el token de actualización del archivo kubeconfig:

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

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

gcloud anthos auth login falla con `proxyconnect tcp`

Este problema ocurre cuando hay un error en la configuración de variable de entorno https_proxy o HTTPS_PROXY. Si se especifica https:// en las variables de entorno, las bibliotecas cliente HTTP de GoLang pueden fallar si el proxy está configurado para controlar conexiones HTTPS mediante otros protocolos, como SOCK5.

Es posible que se muestre el siguiente mensaje de error de ejemplo:

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

A fin de resolver este problema, modifica 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.

El acceso al clúster falla cuando se usa kubeconfig que genera `gcloud anthos auth login`

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

Unauthorized

Para resolver este problema, realiza los siguientes pasos:

En el archivo kubeconfig que generó 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 configurar las marcas --oidc-group-claim y --oidc-username-claim en el servidor de la API de Kubernetes. Cuando el servidor de la API se presenta con el token, este lo reenvía al servicio de identidad de GKE, que muestra los objetos 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 usuario correspondiente tenga los permisos correctos.

Verifica que las reclamaciones establecidas para group y user en el recurso ClientConfig estén presentes en el token de ID.
Verifica los RBAC que se aplicaron.

Verifica que haya un RBAC con los permisos correctos para el usuario especificado por username-claim o uno de los grupos enumerados group-claim en el paso anterior. El nombre del usuario o grupo en el RBAC debe tener el prefijo usernameprefix o groupprefix que se especificó en el recurso ClientConfig.

Si usernameprefix está en blanco y username es un valor distinto de email, el prefijo se establecerá de forma predeterminada en issuerurl#. Para inhabilitar los prefijos de nombre de usuario, establece usernameprefix en -.

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

Nota: El servidor de la API de Kubernetes trata una barra inversa 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 \ cuando analiza el token de ID. Por lo tanto, la vinculación de función de RBAC aplicada a este usuario o grupo solo debe contener una sola barra inversa, o es posible que veas un error 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"
  ],
...
}
```
Las siguientes vinculaciones de RBAC otorgan a este grupo y usuario la función de clúster pod-reader. Observa la barra diagonal simple en el campo del nombre en lugar de una barra doble:

Grupo de 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
```
Usuario de 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
```
Revisa los registros del servidor de la API de Kubernetes.

Si el complemento de OIDC configurado en el servidor de la API de Kubernetes no se inicia de forma correcta, el servidor de la API muestra un error Unauthorized cuando se presenta con el token de ID. Para ver si hubo algún problema con el complemento OIDC en el servidor de la API, ejecuta lo siguiente:
```
kubectl logs statefulset/kube-apiserver -n USER_CLUSTER_NAME \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Reemplaza lo siguiente:
- USER_CLUSTER_NAME: Es el nombre del clúster de usuario del que deseas ver los registros.
- ADMIN_CLUSTER_KUBECONFIG: Es el archivo kubeconfig del clúster de administrador.

Este problema ocurre cuando el archivo kubeconfig que se pasó a gkectl create-login-config no es para un clúster de usuario o el recurso ClientConfig no apareció durante la creación del clúster.

Error getting clientconfig using KUBECONFIG

A fin de resolver este problema, asegúrate de tener el archivo kubeconfig correcto para tu clúster de usuario. Luego, verifica si el recurso ClientConfig está en el clúster:

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

Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

Este problema se produce si intentas escribir datos de configuración de acceso que contienen un nombre de clúster que ya existe en el archivo de destino. Cada archivo de configuración de acceso 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

A fin de solucionar este problema, usa la marca --output para especificar un archivo de destino nuevo.

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

Solucionar problemas de OIDC

Cuando la autenticación de OIDC no funciona para Google Distributed Cloud Virtual for VMware, por lo general, la especificación de OIDC en el recurso ClientConfig no está configurada de forma correcta. El recurso ClientConfig proporciona instrucciones para revisar los registros y la especificación de OIDC para ayudar a identificar la causa de un problema de OIDC.

Revisa la guía de solución de problemas del proveedor de identidad del servicio de identidad de GKE para obtener información sobre cómo habilitar y revisar los registros de identidad y probar la conectividad. Después de confirmar que GKE Identity Service funciona como se espera o de identificar un problema, revisa la siguiente información de solución de problemas de OIDC.

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

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

Usa kubectl get a fin de imprimir el recurso OIDC para el clúster de usuario:
```
kubectl --kubeconfig KUBECONFIG -n kube-public get \
  clientconfig.authentication.gke.io default -o yaml
```
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.
Revisa los valores del campo a fin de confirmar que la especificación esté configurada correctamente para tu proveedor de OIDC.
Si identificas un problema de configuración en la especificación, vuelve a configurar OIDC.
Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con el equipo de asistencia de Google Cloud.

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

Verifica que la autenticación de OIDC esté habilitada

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

Examina los registros del servicio de identidad de GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
En el siguiente resultado de ejemplo, se muestra que la autenticación de OIDC está habilitada de forma correcta:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Si la autenticación de OIDC no está habilitada de forma correcta, se muestran errores similares al siguiente ejemplo:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos que se informaron y, luego, intenta corregirlos.

Prueba la autenticación de OIDC

Para usar la función de OIDC, usa una estación de trabajo con la IU y el navegador habilitados. No puedes realizar estos pasos desde una sesión SSH basada en texto. Para probar que OIDC funciona correctamente en tu clúster, completa los siguientes pasos:

Descarga Google Cloud CLI.
Para generar el archivo de configuración de acceso, ejecuta el siguiente comando gcloud anthos create-login-config:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del 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
```
Reemplaza lo siguiente:
- CLUSTER_NAME por el nombre del clúster de usuario al que deseas conectarte.
- AUTH_KUBECONFIG por el nuevo archivo kubeconfig para crear que incluya las credenciales para acceder al clúster. Para obtener más información, consulta Autenticación en el clúster.
Deberías recibir una página de consentimiento de acceso abierta en el navegador web predeterminado de tu estación de trabajo local. Proporciona información de autenticación válida para un usuario en este mensaje de acceso.

Después de completar de forma correcta el paso de acceso anterior, se generará un archivo kubeconfig en el directorio actual.
Para probar el archivo kubeconfig nuevo que incluye tus credenciales, enumera los Pods en el clúster de usuario:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Reemplaza AUTH_KUBECONFIG por la ruta de acceso a tu nuevo archivo kubeconfig que se generó en el paso anterior.

Es posible que se muestre el siguiente mensaje de ejemplo que indica que puedes autenticar con éxito, pero que no hay controles de acceso basados en funciones (RBAC) asignados a la cuenta:
```
Error from server (Forbidden): pods is forbidden: User "XXXX" cannot list resource "pods" in API group "" at the cluster scope
```

Revisa los registros de autenticación de OIDC

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

Usa kubectl logs para imprimir los registros del servicio de identidad de GKE:
```
kubectl --kubeconfig KUBECONFIG \
  -n anthos-identity-service logs \
  deployment/ais --all-containers=true
```
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.
Revisa los registros para detectar errores que pueden 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 un t en https). Los registros de GKE Identity Service contendrán una entrada como el siguiente ejemplo:
```
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, reconfigura OIDC y corrige los problemas de configuración.
Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con el equipo de asistencia de Google Cloud. La asistencia de Google Cloud necesita los registros de GKE Identity Service y la especificación de OIDC para diagnosticar y resolver problemas de OIDC.

Problemas comunes de OIDC

Si tienes problemas con la autenticación de OIDC, revisa los siguientes problemas comunes. Sigue las indicaciones para resolver el problema.

No hay extremos disponibles para el servicio “ais”

Cuando guardas el recurso ClientConfig, se muestra 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 extremo de GKE Identity Service está en mal estado. El Pod del servicio de GKE Identity no puede entregar el webhook de validación.

Para confirmar que el Pod del servicio de identidad de GKE esté en mal estado, ejecuta el siguiente comando:
```
kubectl get pods -n anthos-identity-service \
  --kubeconfig KUBECONFIG
```
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

El siguiente resultado de ejemplo significa que tu Pod de servicio de identidad de GKE falla:
```
NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s
```

Para comprender por qué el Pod tiene un problema, observa los eventos del Pod:

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

Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del clúster de usuario.

En el siguiente resultado de ejemplo, se informa un error de permiso cuando se extrae 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 los eventos del Pod informan un problema, continúa con la solución de problemas en las áreas afectadas. Si necesitas más ayuda, comunícate con el equipo de asistencia de Google Cloud.

Se produjo un error durante la lectura de 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 maneras:

Aparecen dispersas en el registro: es probable que los errores aislados no sean el problema principal y que se trate de problemas intermitentes de la red.

El complemento de OIDC del servicio de identidad de GKE tiene un proceso daemon para sincronizar de forma periódica la URL de descubrimiento de OIDC cada 5 segundos. Si la conexión de red es inestable, esta solicitud de salida puede fallar. Los errores ocasionales no afectan la autenticación de OIDC. Los datos almacenados en caché existentes se pueden volver a usar.

Si encuentras errores adicionales en los registros, continúa con los pasos adicionales para solucionar problemas.
Aparecen constantemente en el registro o GKE Identity Service nunca alcanza de forma correcta el extremo conocido: Estos problemas constantes indican un problema de conectividad entre GKE Identity Service y tu proveedor de identidad de OIDC.

Los siguientes pasos para solucionar problemas pueden ayudar a diagnosticar estos problemas de conectividad:
1. Asegúrate de que un firewall no esté bloqueando las solicitudes salientes del servicio de GKE Identity.
2. Verifica que el servidor del proveedor de identidad se ejecute de forma correcta.
3. Verifica que la URL de la entidad emisora de OIDC en el recurso ClientConfig esté configurada de forma correcta.
4. Si habilitaste el campo de proxy en el recurso ClientConfig, revisa el estado o registro de tu servidor proxy de salida.
5. Prueba la conectividad entre tu Pod de GKE Identity Service y el servidor del proveedor de identidad de OIDC.

Debes haber accedido al servidor (no autorizado)

Cuando intentes acceder con la autenticación de 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, revisa las secciones anteriores Verifica la especificación de OIDC en tu clúster y Configura el recurso ClientConfig.

No se pudo realizar la solicitud del autenticador de webhook

En los registros del servicio de identidad de GKE, es posible 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 de servicio de identidad de GKE.

Para verificar si se puede acceder al extremo del servicio de identidad de GKE desde el exterior, 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 '{}'
```
Reemplaza APISERVER_HOST por la dirección de tu servidor de la API.

La respuesta esperada es un código de estado HTTP 400. Si se agotó el tiempo de espera de la solicitud, reinicia el Pod de servicio de identidad de GKE. Si el error continúa, significa que el servidor HTTP de GKE Identity Service no se inicia. Para obtener asistencia adicional, comunícate con el equipo de Asistencia de Google Cloud.

No se encontró la URL de acceso

El siguiente problema ocurre cuando la consola de Google Cloud no puede comunicarse con el proveedor de identidad. Un intento de acceso se redirecciona a una página con el error URL not found.

Para resolver el problema, revisa los siguientes pasos. Después de cada paso, intenta acceder de nuevo:

Si no se puede acceder al proveedor de identidad a través de la Internet pública, habilita el proxy HTTP de OIDC para acceder con la consola de Google Cloud. Edita el recurso personalizado ClientConfig y establece useHTTPProxy en true:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig de tu clúster de usuario.
Si el proxy HTTP está habilitado y sigues viendo este error, es posible que haya un problema con el inicio del proxy. Visualiza los registros del proxy:
```
kubectl logs deployment/clientconfig-operator -n kube-system --kubeconfig USER_CLUSTER_KUBECONFIG
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig de tu clúster de usuario.

Incluso si tu proveedor de identidad tiene una AC conocida, debes proporcionar un valor para oidc.caPath en tu recurso personalizado ClientConfig de modo que el proxy HTTP se inicie de forma correcta.
Si el servidor de autorización solicita el consentimiento y no incluiste los parámetros prompt=consent de extraparam, edita el recurso personalizado ClientConfig y agrega prompt=consent a los parámetros extraparams:
```
kubectl edit clientconfig default -n kube-public --kubeconfig USER_CLUSTER_KUBECONFIG
```
Reemplaza USER_CLUSTER_KUBECONFIG por la ruta de acceso al archivo kubeconfig de tu clúster de usuario.
Si se cambia la configuración del servicio de almacenamiento, es posible que debas salir de forma explícita de las sesiones existentes. En la consola de Google Cloud, ve a la página de detalles del clúster y selecciona Salir.

Solución de problemas de LDAP

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

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

Verifique que la autenticación LDAP esté habilitada

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

Examina los registros del servicio de identidad de GKE:
```
kubectl logs -l k8s-app=ais -n anthos-identity-service
```
En el siguiente resultado de ejemplo, se muestra que la autenticación LDAP está habilitada de forma correcta:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Si la autenticación LDAP no está habilitada de forma correcta, se muestran errores similares al siguiente ejemplo:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos que se informaron y, luego, intenta corregirlos.

Prueba la autenticación de LDAP

Para usar la función de LDAP, usa una estación de trabajo con la IU y el navegador habilitados. No puedes realizar estos pasos desde una sesión SSH basada en texto. Para probar que la autenticación LDAP funcione correctamente en tu clúster, completa los siguientes pasos:

Descarga Google Cloud CLI.
Para generar el archivo de configuración de acceso, ejecuta el siguiente comando gcloud anthos create-login-config:
```
gcloud anthos create-login-config \
  --output user-login-config.yaml \
  --kubeconfig KUBECONFIG
```
Reemplaza KUBECONFIG por la ruta de acceso al archivo kubeconfig del 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
```
Reemplaza lo siguiente:
- CLUSTER_NAME por el nombre del clúster de usuario al que deseas conectarte.
- AUTH_KUBECONFIG por el nuevo archivo kubeconfig para crear que incluya las credenciales para acceder al clúster. Para obtener más información, consulta Autenticación en el clúster.
Deberías recibir una página de consentimiento de acceso abierta en el navegador web predeterminado de tu estación de trabajo local. Proporciona información de autenticación válida para un usuario en este mensaje de acceso.

Después de completar de forma correcta el paso de acceso anterior, se generará un archivo kubeconfig en el directorio actual.
Para probar el archivo kubeconfig nuevo que incluye tus credenciales, enumera los Pods en el clúster de usuario:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Reemplaza AUTH_KUBECONFIG por la ruta de acceso al kubeconfig del 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 comunes de LDAP

Si tienes problemas con la autenticación de LDAP, consulta los siguientes problemas comunes. Sigue las indicaciones para resolver el problema.

Los usuarios no pueden autenticarse con comas en el CN

Cuando usas LDAP, es posible que tengas problemas por los que los usuarios no puedan autenticarse si su CN contiene una coma, como CN="a,b". Si habilitas el registro de depuración para GKE Identity Service, se informa 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 ocurre en las versiones de Google Distributed Cloud Virtual for VMware 1.13 y anteriores.

Para solucionar este problema, completa uno de los siguientes pasos:

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

Error 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 cuando ejecutes 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 verás 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 resolver este error, completa los siguientes pasos:

Verifica si usas la versión 1.4.2 de anthos-auth de Google Cloud CLI:
```
gcloud anthos auth version
```
El siguiente resultado de ejemplo muestra que la versión es 1.4.2:
```
Current Version: v1.4.2
```
Si ejecutas la versión 1.4.2 de anthos-auth de Google Cloud CLI, actualiza a la versión 1.4.3 o posterior.

Problemas comunes

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

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

El siguiente error se produce cuando intentas conectarte a la 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 debido al uso de una clave privada incorrecta o a la falta de una clave cuando te conectas a la estación de trabajo de administrador con SSH.

Para resolver este problema, busca y usa la clave SSH correcta. Si no puedes encontrar la clave SSH correcta, sigue estos pasos a fin de generar un nuevo par de claves SSH para la estación de trabajo de administrador:

Crear una VM de rescate temporal Esta VM de rescate debe conectarse a la misma red y Datastore que la VM de la estación de trabajo de administrador actual.
Apaga la VM de la estación de trabajo de administrador y la VM de rescate.
Conectar el disco de datos de la VM de la estación de trabajo de administrador a la VM de rescate Por lo general, el disco de datos es de 512 MB, a menos que hayas especificado un tamaño de disco 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 con SSH.
En tu computadora local, genera un nuevo par de claves SSH.
En la computadora local, copia la nueva clave pública SSH en la VM de recuperación con el comando ssh-copy-id:
```
ssh-copy-id -i ~/.ssh/NEW_SSH_KEY ubuntu@RESCUE_VM
```
Reemplaza lo siguiente:
- NEW_SSH_KEY por el nombre de la Llave SSH nueva que creaste en el paso anterior
- RESCUE_VM por la dirección IP o el FQDN de la VM de rescate
En la VM de rescate, activa el disco de datos en la VM de rescate:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Reemplaza DEVICE por el identificador único de tu propio disco, como /dev/sdb1.
En la VM de rescate, copia la nueva clave pública SSH en el archivo authorized_keys en el disco de datos activado desde la VM de la estación de trabajo de administrador.

Visualiza el contenido del archivo authorized_keys en la VM de recuperación, que incluye la nueva clave pública SSH que se copió mediante 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, luego, cierra el archivo.
Edita el archivo authorized_keys en el disco de datos activado desde la VM de la 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 la VM de recuperación.
Guarda y cierra el archivo authorized_keys en el disco de datos activado desde la VM de la estación de trabajo de administrador.
Verifica que se hayan aplicado los permisos correctos a los archivos de /mnt/ext-disk/.ssh/:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Sal de 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 conectar el disco 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 de forma correcta, 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
```
Reemplaza lo siguiente:
- NEW_SSH_KEY por el nombre de la nueva Llave SSH que creaste en un paso anterior y que copiaste en la VM de la estación de trabajo de administrador
- RESCUE_VM por la dirección IP o el FQDN de la VM de la estación de trabajo de administrador
Verifica si puedes conectarte con éxito a través de SSH.
Borra la VM de rescate.

¿Qué sigue?