Soluciona 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 general para la solución de problemas y orientación, 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, debes configurar un proveedor de identidad. Si no configuraste un proveedor de identidad para el servicio de identidad de GKE, sigue las instrucciones de uno de los siguientes proveedores más comunes:

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.

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. Si estos problemas no se aplican o tienes problemas con OIDC o LDAP, continúa con la sección para solucionar problemas del servicio de identidad de GKE.

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 partes 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.

  1. Para actualizar Google Cloud CLI, sigue estos pasos:

    gcloud components update

  2. 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 del clúster, el botón ACCEDER está inhabilitado. Para solucionar los problemas de configuración de OIDC del clúster, consulta la siguiente sección 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. 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 se vence 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 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. Se podría mostrar el siguiente error de ejemplo:

Unauthorized

Para resolver este problema, realiza los siguientes pasos:

  1. 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

  2. Instala jwt-cli y ejecuta lo siguiente:

    jwt ID_TOKEN

  3. 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, lo reenvía al servicio de identidad de GKE, que muestra los group-claim y username-claim extraídos de vuelta 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.

  4. 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 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 establece de forma predeterminada como 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.

    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

  5. Revisa 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 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 se deben ver los registros.
    • ADMIN_CLUSTER_KUBECONFIG: Es el archivo kubeconfig del clúster de administrador.

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 con el 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 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.

  1. Usa kubectl get para imprimir el recurso de 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.

  2. Revisa los valores de los campos a fin de confirmar que la especificación se configuró de forma correcta para tu proveedor de OIDC.

  3. Si identificas un problema de configuración en la especificación, reconfigura OIDC.

  4. Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con la 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 la autenticación de OIDC esté habilitada en tu clúster.

  1. Examina los registros de GKE Identity Service:

    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 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, utiliza 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:

  1. Descarga Google Cloud CLI.

  2. 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.

  3. 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 conectarás
    • AUTH_KUBECONFIG por el archivo kubeconfig nuevo que se debe crear y que incluye las credenciales para acceder al clúster. Para obtener más información, consulta Autentícate en el clúster.

  4. 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.

  5. Para probar el archivo kubeconfig nuevo 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 nuevo que se generó en el paso anterior.

    Es posible que se muestre el siguiente mensaje de ejemplo que indica que puedes autenticarte de forma correcta, pero 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 autenticarte con OIDC, los registros de GKE Identity Service proporcionan la información más relevante y útil para depurar el problema.

  1. Usa kubectl logs para imprimir los registros de GKE Identity Service:

    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.

  2. Revisa los registros para detectar errores que pueden ayudarte a diagnosticar problemas de OIDC.

    Por ejemplo, el recurso ClientConfig puede 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án una entrada como el siguiente ejemplo:

    OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.

  3. Si identificas un problema de configuración en los registros, reconfigura OIDC y corrige los problemas de configuración.

  4. 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 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 de GKE Identity Service está en mal estado. El Pod del servicio de identidad de GKE no puede entregar el webhook de validación.

  1. 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 el Pod del servicio de identidad de GKE falla:

    NAME                  READY  STATUS            RESTARTS  AGE
ais-5949d879cd-flv9w  0/1    ImagePullBackOff  0         7m14s

  2. 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.

    El siguiente resultado de ejemplo 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"

  3. 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 la Asistencia de Google Cloud.

Se produjo un error al 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 maneras:

  • Aparecen poco en el registro: Es probable que los errores discretos no sean el problema principal y podrían ser problemas de red intermitentes.

    El complemento OIDC de GKE Identity Service tiene un proceso de 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 existentes almacenados en caché se pueden volver a usar.

    Si encuentras errores adicionales en los registros, continúa con los pasos adicionales para solucionar problemas.

  • Aparecen de manera constante en el registro o GKE Identity Service nunca llegará de forma correcta al extremo conocido: Estos problemas constantes indican un problema de conectividad entre GKE Identity Service 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 del servicio de identidad de GKE.
    2. Comprueba 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 el registro de tu servidor proxy de salida.
    5. Prueba la conectividad entre el Pod de Identity Service de GKE y el servidor del proveedor de identidad de OIDC.

Debes acceder 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 de autenticación general 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 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 del servicio de identidad de GKE.

  1. Para verificar si se puede acceder al extremo de GKE Identity Service desde el exterior, ejecuta el siguiente comando de 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 del 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 un error URL not found.

Para resolver este problema, revisa los siguientes pasos de solución de problemas. Después de cada paso, intenta acceder de nuevo:

  1. 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 del clúster de usuario.

  2. Si el proxy HTTP está habilitado y aún experimentas 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 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 a fin de que el proxy HTTP se inicie de manera correcta.

  3. 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.

  4. Si se cambian los parámetros de configuración en el 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.

Solucionar problemas de LDAP

Si tienes problemas con la autenticación LDAP, asegúrate de haber configurado tu entorno mediante 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.

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 de identificar un problema, revisa la siguiente información de solución de problemas de LDAP.

Verifica que la autenticación de LDAP esté habilitada

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

  1. Examina los registros de GKE Identity Service:

    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 correctamente:

    ...
I1012 00:14:11.282107      34 plugin_list.h:139] LDAP[0] started.
...

    Si la autenticación de 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 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 SSH basada en texto. Para probar que la autenticación LDAP funcione correctamente en tu clúster, completa los siguientes pasos:

  1. Descarga Google Cloud CLI.

  2. 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.

  3. 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 conectarás
    • AUTH_KUBECONFIG por el nuevo archivo kubeconfig que se debe crear y que incluye las credenciales para acceder al clúster. Para obtener más información, consulta Autentícate en el clúster.

  4. 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.

  5. Para probar el archivo kubeconfig nuevo 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 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 para 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 del servicio de identidad de GKE escapa dos veces la coma. Este problema solo ocurre en las versiones Google Distributed Cloud 1.13 y anteriores.

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

  1. Actualiza tu clúster a Google Distributed Cloud 1.13 o una versión posterior.
  2. Elige un identifierAttribute diferente, como sAMAccountName, en lugar de usar el CN.
  3. Quite las comas del CN de su directorio de LDAP.

Error de autenticación con Google Cloud CLI 1.4.2

Con anthos-auth 1.4.2 de Google Cloud CLI, 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 de GKE Identity Service, 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 solucionar este error, completa los siguientes pasos:

  1. Verifica si usas la versión 1.4.2 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

  2. Si ejecutas la versión 1.4.2 anthos-auth de Google Cloud CLI, actualiza a la versión 1.4.3 o posterior.

¿Qué sigue?

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