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.

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

Soluciona problemas de autenticación de Google Distributed Cloud

En este documento, se ayuda a solucionar problemas de autenticación en Google Distributed Cloud. Se proporciona información y orientación generales para solucionar 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 usar Identity Service para GKE con Google Distributed Cloud, debes configurar un proveedor de identidad. Si no configuraste un proveedor de identidad para GKE Identity Service, sigue las instrucciones para 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 de solución de problemas pueden ayudarte con problemas generales de autenticación y autorización en Google Distributed Cloud. Si estos problemas no se aplican o tienes problemas con OIDC o LDAP, continúa con la sección sobre la solución de problemas de GKE Identity Service.

Mantén `gcloud anthos auth` actualizado

Puedes evitar muchos problemas habituales si verificas 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 LOGIN está inhabilitado. Para solucionar los problemas de la configuración de OIDC de tu clúster, consulta la siguiente sección de solución de 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. Esta cuenta podría ser 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, agrega prompt=consent al campo authentication.oidc.extraParams en tu recurso ClientConfig. Luego, vuelve a generar el archivo de autenticación del cliente.

Token de actualización vencido

El siguiente problema se produce cuando venció el token de actualización en el 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 se produce cuando hay un error en las opciones de configuración de las variables 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 ocurrir si faltan los RBAC adecuados o son incorrectos, o hay un error en la configuración de OIDC para el clúster. Es posible que se muestre 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 establecer las marcas --oidc-group-claim y --oidc-username-claim en el servidor de la API de Kubernetes. Cuando se presenta el servidor de API con el token, reenvía el token al servicio de identidad de GKE, que muestra el group-claim y los 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 que especifica username-claim o uno de los grupos enumerados en group-claim del 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 establece 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 Autentica con OIDC.

Nota: Ten en cuenta que el servidor de la API de Kubernetes trata una barra inversa como un carácter de escape. Por lo tanto, si el nombre del usuario o grupo contiene \\, el servidor de la API lo lee como una sola \ cuando analiza el token de ID. Es por eso que la vinculación de función de RBAC aplicado a este usuario o grupo debe contener solo una barra inversa o es posible que se produzca 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: El archivo kubeconfig del clúster de administrador.

Este problema se produce cuando el archivo kubeconfig que se pasa a gkectl create-login-config no es para un clúster de usuarios 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, los 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, por lo general, la especificación de OIDC en el recurso ClientConfig se configuró de forma incorrecta. El recurso ClientConfig proporciona instrucciones para revisar los registros y la especificación de OIDC a fin de identificar la causa de un problema de OIDC.

Revisa la guía de solución de problemas del proveedor de identidad de GKE Identity Service 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 según lo esperado o identificar un problema, revisa la siguiente información para solucionar problemas de OIDC.

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

La información de OIDC para el 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 tu 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 de los campos a fin de confirmar que la especificación esté configurada de forma correcta para tu proveedor de OIDC.
Si identificas un problema de configuración en la especificación, reconfigura OIDC.
Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con el equipo de Google Cloud asistencia.

El equipo de asistencia deGoogle 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 esta 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 correctamente:
```
...
I1011 22:14:21.684580      33 plugin_list.h:139] OIDC_AUTHENTICATION[0] started.
...
```
Si la autenticación de OIDC no está habilitada correctamente, se muestran errores similares al siguiente ejemplo:
```
Failed to start the OIDC_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos informados y trata de 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 de SSH basada en texto. Para probar que OIDC 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 te quieres conectar.
- AUTH_KUBECONFIG con el nuevo archivo kubeconfig para crear uno que incluya las credenciales de acceso a tu clúster. Para obtener más información, consulta Cómo autenticarse 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 esta solicitud de acceso.

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

Es posible que se devuelva el siguiente mensaje de ejemplo que muestra que puedes autenticarte correctamente, pero que no hay controles de acceso basado en roles (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 autenticarte 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 de tipeo en el campo issuerURL, como htps://accounts.google.com (falta un t en https). Los registros del servicio de identidad de GKE contendrán 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, 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 Google Cloud asistencia.

El equipo de asistencia deGoogle 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 instrucciones 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 del servicio de identidad de GKE no está en buen estado. El Pod del servicio de identidad de GKE no puede entregar el webhook de validación.

Para confirmar que el Pod del servicio de identidad de GKE no está en buen 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 del 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 ejemplo de salida, 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 asistencia, comunícate con el Google Cloud equipo de asistencia.

No se pudieron leer los bytes de respuesta del servidor.

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

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

Aparece de forma dispersa en el registro: Es probable que los errores de Spare no sean el problema principal y que se trate de problemas de red intermitentes.

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

Si encuentras errores adicionales en los registros, continúa con los pasos adicionales para solucionar el problema.
Aparece constantemente en el registro o servicio de identidad de GKE nunca logra conectarse correctamente al extremo conocido: Estos problemas constantes indican un problema de conectividad entre servicio de identidad de GKE y tu proveedor de identidad OIDC.

Los siguientes pasos para solucionar problemas pueden ayudarte a diagnosticar estos problemas de conectividad:
1. Asegúrate de que un firewall no esté bloqueando las solicitudes salientes de servicio de identidad de GKE.
2. Verifica que el servidor del proveedor de identidad se ejecute correctamente.
3. Verifica que la URL del emisor de OIDC en el recurso ClientConfig esté configurada correctamente.
4. Si habilitaste el campo de proxy en el recurso ClientConfig, revisa el estado o el 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 acceder al servidor (sin autorización)

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 para verificar la especificación de OIDC en tu clúster y configurar el recurso ClientConfig.

No se pudo realizar la solicitud del autenticador de webhook

En los registros de GKE Identity Service, 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 GKE Identity Service.

Para verificar si se puede acceder al extremo de GKE Identity Service 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 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 del servicio de identidad de GKE. Si el error persiste, significa que el servidor HTTP de GKE Identity Service no se inicia. Para obtener asistencia adicional, comunícate con el equipo de asistencia. Google Cloud

No se encontró la URL de acceso

El siguiente problema se produce cuando la consola de Google Cloud no puede comunicarse con el proveedor de identidad. Cuando se intenta acceder, se redirecciona a una página con un error URL not found.

Para resolver este problema, realiza las siguientes acciones. Después de cada paso, intenta volver a acceder:

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 a través de 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 del clúster de usuario.
Si el proxy HTTP está habilitado y sigues experimentando este error, es posible que se haya generado un problema mientras se iniciaba el proxy. Consulta 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 del 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 para que el proxy HTTP se inicie correctamente.
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 del 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.

Soluciona problemas de LDAP

Si tienes problemas con la autenticación de LDAP, asegúrate de haber configurado tu entorno siguiendo 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 configurar el recurso ClientConfig para habilitar la autenticación de LDAP.

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

Verifica que la autenticación LDAP esté habilitada

Antes de probar la autenticación LDAP, verifica que esta 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 LDAP está habilitada correctamente:
```
...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...
```
Si la autenticación de LDAP no está habilitada correctamente, se muestran errores similares al siguiente ejemplo:
```
Failed to start the LDAP_AUTHENTICATION[0] authentication method with error:
```
Revisa los errores específicos informados y trata de corregirlos.

Prueba la autenticación de LDAP

Para usar la función LDAP, usa una estación de trabajo con la IU y el navegador habilitados. No puedes realizar estos pasos desde una sesión de SSH basada en texto. Para probar que la autenticación de 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 te quieres conectar.
- AUTH_KUBECONFIG con el nuevo archivo kubeconfig que se creará y que incluye las credenciales para acceder a tu clúster. Para obtener más información, consulta Cómo autenticarse 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 esta solicitud de acceso.

Después de completar correctamente el paso de acceso anterior, se genera un archivo kubeconfig en tu directorio actual.
Para probar el nuevo archivo kubeconfig que incluye tus credenciales, enumera los pods en tu clúster de usuario:
```
kubectl get pods --kubeconfig AUTH_KUBECONFIG
```
Reemplaza AUTH_KUBECONFIG por la ruta de acceso al archivo 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, revisa los siguientes problemas comunes. Sigue las instrucciones para resolver el problema.

Los usuarios no pueden autenticarse con comas en su CN

Cuando usas LDAP, es posible que tengas problemas en los que los usuarios no puedan autenticarse si su CN contiene una coma, como CN="a,b". Si habilitas el registro de depuración del servicio de identidad de GKE, se informará 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 del servicio de identidad de GKE aplica una doble virgulilla a la coma. Este problema solo ocurre en las versiones 1.13 y anteriores de Google Distributed Cloud.

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

Actualiza tu clúster a Google Distributed Cloud 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 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 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
```
En el siguiente resultado de ejemplo, se 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 una 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 `permission denied` de la clave SSH

El siguiente error ocurre 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 debido a que usas una clave privada incorrecta o no usas ninguna 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 encuentras la clave SSH correcta, genera un nuevo par de claves SSH para la estación de trabajo de administrador siguiendo estos pasos:

Crea una VM de recuperación temporal. Esta VM de recuperación debe conectarse a la misma red y al mismo almacén de datos 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 recuperación.
Conecta el disco de datos de la VM de la estación de trabajo del administrador a la VM de recuperación. El disco de datos suele ser 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 recuperación.
Conéctate a la VM de recuperación mediante SSH.
En tu computadora local, genera un nuevo par de claves SSH.
En tu computadora local, copia la nueva clave pública SSH a 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 nueva clave SSH que creaste en el paso anterior.
- RESCUE_VM por la dirección IP o el FQDN de tu VM de recuperación.
En la VM de recuperación, activa el disco de datos en la VM de recuperación:
```
sudo mkdir -p /mnt/ext-disk
sudo mount DEVICE /mnt/ext-disk
```
Reemplaza DEVICE por el identificador único de tu disco, como /dev/sdb1.
En la VM de recuperación, copia la nueva clave pública SSH en el archivo authorized_keys del disco de datos activado de la VM de la estación de trabajo de administrador.

Consulta el contenido del archivo authorized_keys en la VM de recuperación, 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, luego, cierra el archivo.
Edita el archivo authorized_keys en el disco de datos activado de 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 de la VM de la estación de trabajo del administrador.
Verifica que los archivos de /mnt/ext-disk/.ssh/ tengan los permisos correctos aplicados:
```
chown -R ubuntu /mnt/ext-disk/.ssh/*
chmod -R 600 /mnt/ext-disk/.ssh/*
```
Sal de tu conexión SSH a la VM de recuperación.
Apaga la VM de recuperación.
Desconecta el disco de datos de la VM de recuperación y vuelve a conectarlo a la VM de la estación de trabajo del administrador.
Enciende la estación de trabajo de administrador
Una vez que la VM se ejecute correctamente, conéctate a la estación de trabajo del administrador con 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 clave SSH que creaste en un paso anterior y 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 que puedas conectarte correctamente con SSH.
Borra la VM de recuperación.

¿Qué sigue?