Soluciona problemas de acceso de los usuarios

En este documento, se proporciona orientación para solucionar problemas de acceso de los usuarios en GKE Identity Service.

gcloud anthos create-login-config no puede obtener clientconfig

Este problema ocurre en uno de los siguientes casos:

• El archivo kubeconfig que se pasó a gcloud anthos create-login-config es incorrecto.
• El recurso personalizado ClientConfig no está presente en el clúster (GKE Identity Service 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, haz lo siguiente:

1. Asegúrate de tener 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. Si deseas obtener más información sobre las opciones de configuración del clúster, consulta Opciones de configuración para clústeres.

gcloud anthos create-login-config falla debido a un nombre de clúster duplicado

Este problema se produce si intentas crear la configuración de acceso de un clúster en un archivo que ya contiene una configuración de acceso para este.

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

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.

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.

Mensaje de error

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

Solución

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 por uno de los siguientes motivos:

• Hay un error en la configuración que se usa para acceder 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, haz lo siguiente:

1. Verifica la configuración que se usa para acceder.

   Configuración de OIDC

   La sección authentication.oidc en el archivo de configuración del clúster de usuario tiene los campos group y username que se usan para establecer las marcas --oidc-group-claim y --oidc-username-claim en el servidor de la API de Kubernetes. Cuando el servidor de la API recibe el token de identidad de un usuario, lo reenvía a GKE Identity Service, que muestra los 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 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.

   Si deseas obtener información sobre cómo configurar las políticas de RBAC correctas para GKE Identity Service, consulta Configura el control de acceso basado en roles (RBAC).

RBAC para grupos que no funcionan para proveedores de OIDC

Nota: Las siguientes instrucciones de solución de problemas se aplican solo si tu proveedor se configuró en la sección oidc del recurso personalizado ClientConfig y el campo enableAccessToken está configurado como false.

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

   Después de ejecutar el comando de gcloud anthos auth login para iniciar el flujo de autenticación de 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 de grupo del usuario como se esperaba.

2. Si el token de ID no tiene información de grupo del usuario, configura correctamente el proveedor de OIDC para mostrar la información de grupo según la documentación de tu proveedor de OIDC. Por ejemplo, si usas la configuración de OIDC del proveedor de identidad Okta, sigue la documentación del proveedor de Okta Identity para configurar grupos en el token de ID.

3. Si el token de ID tiene información de grupo, verifica si la clave de información de grupo en el 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 enumeran en Configura el acceso de usuario y Accede a clústeres.

Soluciona problemas de proveedores de identidad

Si tienes problemas para usar OIDC o LDAP con tu clúster de GKE, sigue los pasos que se indican en esta sección para solucionar problemas de GKE Identity Service y ayudar a determinar si hay un problema con la configuración de tu proveedor de identidad.

Habilita el registro de depuración de GKE Identity Service

Para ayudar a solucionar problemas relacionados con la identidad en tu clúster, habilita el registro de depuración de GKE Identity Service.

1. Aplica un parche a tu clúster existente 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
   

   Reemplaza lo siguiente:

   • LOG_LEVEL: para obtener los registros más detallados, establece este valor en el nivel 3 cuando soluciones problemas.

     Nota: Este valor se puede establecer más alto en 9. Sin embargo, en este nivel, es posible que revele información de la credencial en la consola.

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

Verifica el registro del contenedor de GKE Identity Service

Revisa el contenido de los registros de contenedores de GKE Identity Service en busca de errores o advertencias.

1. Para revisar los registros, usa kubectl logs:

   kubectl logs -f -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.

Reinicia el Pod de GKE Identity Service

Si los registros de contenedores muestran problemas, reinicia el Pod de GKE Identity Service.

1. Para reiniciar el Pod de GKE Identity Service, borra el Pod existente. Se crea un Pod nuevo automáticamente como reemplazo.

   kubectl delete 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.

Soluciona problemas de conectividad con el proveedor de identidad

Si el Pod de GKE Identity Service parece ejecutarse de forma correcta, prueba la conectividad con el proveedor de identidad remoto.

1. Inicia un Pod de Busybox en el mismo espacio de nombres que el Pod de GKE Identity Service:

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

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

2. Para verificar si puedes recuperar la URL de descubrimiento, ejecuta en el Pod de Busybox y ejecuta el comando curl:

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

   Reemplaza lo siguiente:

   • ISSUER_URL: la URL de la entidad emisora de tu proveedor de identidad.
   • KUBECONFIG: la ruta de acceso al archivo de kubeconfig del clúster de usuario.

   Una respuesta correcta es un resultado de JSON con los extremos del proveedor de identidad detallados.

3. Si el comando anterior no muestra el resultado esperado, comunícate con el administrador de tu proveedor de identidad para obtener asistencia adicional.

El acceso LDAP no funciona para el clúster de administrador de Google Distributed Cloud

Actualmente, LDAP solo es compatible con el clúster de usuario de Google Distributed Cloud.