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:
- Asegúrate de que tienes el archivo kubeconfig correcto para tu clúster.
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:
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 camposgroup
yusername
, 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 elementosgroup-claim
yusername-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
yuser
en la secciónauthentication.oidc
del archivo de configuración del clúster estén presentes en el token de ID.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
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 archivokubeconfig
, en el campoid-token
. Usa jwt.io para decodificar el token de ID y verificar si contiene la información del grupo del usuario como se espera.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.
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ónoidc
.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 sergroups
en la secciónoidc
.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.
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 nivel3
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.
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.
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.
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.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.
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.