Solucionar problemas de acceso de usuarios

En este documento se ofrece información para solucionar problemas de acceso de usuarios en GKE Identity Service.

gcloud anthos create-login-config no puede obtener clientconfig

Este problema se produce en uno de los siguientes casos:

  • El archivo kubeconfig transferido a gcloud anthos create-login-config no es correcto.
  • El recurso personalizado ClientConfig no está presente en el clúster (el servicio de identidad de GKE no está instalado en el clúster).

Mensaje de error

  failed to get clientconfig default in namespace kube-public
  

Solución

Para solucionar este problema, sigue estos pasos:

  1. Asegúrate de que tienes el archivo kubeconfig correcto para tu clúster.
  2. Para verificar si el recurso personalizado ClientConfig está en el clúster, ejecuta el siguiente comando:

    kubectl --kubeconfig KUBECONFIG  get clientconfig default -n kube-public
    

    Si ClientConfig no está presente en el clúster, instala y configura GKE Identity Service en el clúster. Para obtener más información sobre las opciones de configuración de clústeres, consulta Opciones de configuración de clústeres.

gcloud anthos create-login-config falla debido a que el nombre del clúster está duplicado

Este problema se produce si intentas crear una configuración de inicio de sesión para un clúster en un archivo que ya contiene una configuración de inicio de sesión para ese clúster.

Mensaje de error

  error merging with file FILENAME because FILENAME contains a
    cluster with the same name as the one read from KUBECONFIG.
  

Solución

Para resolver este problema, utilice la marca --output para especificar un nuevo archivo de destino.

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

gcloud anthos auth login falla con proxyconnect tcp

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

Mensaje de error

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

Solución

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

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

Este problema se produce cuando el servidor de la API de Kubernetes no puede autorizar al usuario por uno de los siguientes motivos:

  • Hay un error en la configuración utilizada para iniciar sesión con el comando gcloud anthos auth login.
  • Las políticas de RBAC necesarias son incorrectas o faltan para el usuario.

Mensaje de error

  Unauthorized
  

Solución

Para solucionar este problema, sigue estos pasos:

  1. Verifica la configuración utilizada para iniciar sesión.

    Configuración de OIDC

    La sección authentication.oidc del archivo de configuración del clúster de usuarios tiene los campos group y username, que se usan para definir las marcas --oidc-group-claim y --oidc-username-claim en el servidor de la API de Kubernetes. Cuando el servidor de la API recibe un token de identidad de un usuario, reenvía el token al servicio de identidad de GKE, que devuelve los elementos group-claim y username-claim extraídos al servidor de la API. El servidor de la API usa la respuesta para verificar que el grupo o el usuario correspondiente tiene los permisos correctos.

    Verifica que las reclamaciones definidas para group y user en la sección authentication.oidc del archivo de configuración del clúster estén presentes en el token de ID.

  2. Verifica las políticas de RBAC aplicadas.

    Para saber cómo configurar las políticas de RBAC correctas para GKE Identity Service, consulta Configurar el control de acceso basado en roles (RBAC).

Los controles de acceso basados en roles de los grupos no funcionan con los proveedores de OIDC

  1. Verificar si el token de ID tiene la información del grupo

    Después de ejecutar el comando gcloud anthos auth login para iniciar el flujo de autenticación OIDC, el token de ID se almacena en el archivo kubeconfig, en el campo id-token. Usa jwt.io para decodificar el token de ID y verificar si contiene la información del grupo del usuario como se espera.

  2. Si el token de ID no tiene información de grupo del usuario, configura correctamente el proveedor de OIDC para que devuelva la información de grupo según la documentación de tu proveedor de OIDC. Por ejemplo, si utilizas la configuración de OIDC del proveedor de identidades Okta, sigue la documentación de dicho proveedor para configurar los grupos en el token de ID.

  3. Si el token de ID tiene información de grupo, comprueba si la clave de información de grupo del token de ID coincide con el campo groupsClaim configurado en la sección oidc.

    Por ejemplo, si el token de ID contiene información de grupo en la clave groups:

    "groups" : ["group1", "group2" ...]
    

    El valor del campo groupsClaim debe ser groups en la sección oidc.

    Después de modificar la configuración en la sección oidc, asegúrate de volver a ejecutar las instrucciones que se indican en Configurar el acceso de los usuarios y Acceder a clústeres.

Solucionar problemas con proveedores de identidades

Si tienes problemas para usar OIDC o LDAP con tu clúster de GKE, sigue los pasos de esta sección para solucionar problemas de GKE Identity Service y determinar si hay algún problema con la configuración de tu proveedor de identidades.

Habilitar el registro de depuración de Identity Service de GKE

Para solucionar problemas relacionados con la identidad en tu clúster, habilita el registro de depuración del servicio de identidad de GKE.

  1. Aplica un parche a tu clúster con kubectl patch:

    kubectl patch deployment ais \
      -n anthos-identity-service --type=json \
      -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value":"--vmodule=cloud/identity/hybrid/charon/*=LOG_LEVEL"}]' \
      --kubeconfig KUBECONFIG
    

    Haz los cambios siguientes:

    • LOG_LEVEL: Para obtener los registros más detallados, asigna el nivel 3 a este valor cuando tengas que solucionar problemas.

    • KUBECONFIG: la ruta al archivo kubeconfig de tu clúster de usuario.

Consultar el registro del contenedor de GKE Identity Service

Revisa el contenido de los registros de contenedores de GKE Identity Service para ver si hay errores o advertencias.

  1. Para revisar los registros, haz lo siguiente: kubectl logs

    kubectl logs -f -l k8s-app=ais \
      -n anthos-identity-service \
      --kubeconfig KUBECONFIG
    

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

Reiniciar el pod de GKE Identity Service

Si los registros del contenedor muestran problemas, reinicia el pod del servicio de identidad de GKE.

  1. Para reiniciar el pod de Identity Service para GKE, elimina el pod. Se crea automáticamente un nuevo pod como sustituto.

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

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

Solucionar problemas de conectividad con el proveedor de identidades

Si parece que el pod de Identity Service de GKE se está ejecutando correctamente, prueba la conectividad con el proveedor de identidades remoto.

  1. Inicia un pod de busybox en el mismo espacio de nombres que el pod de Identity Service de GKE:

    kubectl run curl --image=radial/busyboxplus:curl \
      -n anthos-identity-service -- sleep 3000 \
      --kubeconfig KUBECONFIG
    

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

  2. Para comprobar si puedes obtener la URL de descubrimiento, ejecuta el pod de busybox y ejecuta el comando curl:

    kubectl exec pod/curl -n anthos-identity-service -- \
      curl ISSUER_URL \
      --kubeconfig KUBECONFIG
    

    Haz los cambios siguientes:

    • ISSUER_URL: URL del emisor de su proveedor de identidades.
    • KUBECONFIG: la ruta al archivo kubeconfig de tu clúster de usuario.

    Si la respuesta es correcta, se devuelve un resultado JSON con los endpoints detallados del proveedor de identidades.

  3. Si el comando anterior no devuelve el resultado esperado, ponte en contacto con el administrador de tu proveedor de identidades para obtener más ayuda.

El inicio de sesión LDAP no funciona en el clúster de administrador de Google Distributed Cloud

Actualmente, LDAP solo se admite en clústeres de usuarios de Google Distributed Cloud.