En este documento se ofrecen directrices para solucionar problemas de proveedores de identidades de OIDC y AzureAD en Identity Service de GKE.
Formato incorrecto del certificado
Este problema se produce cuando el valor del certificado tiene errores de formato. Los problemas de formato pueden corresponder a valores de certificado que no están codificados en Base64 y a valores que sí lo están, pero son incorrectos. El problema también puede surgir si el certificado no está firmado por una autoridad de certificación raíz o si no se proporciona una cadena de confianza con el formato correcto.
Mensajes de error
A continuación, se muestran ejemplos de mensajes de error en situaciones en las que el formato del certificado es incorrecto:
Certificado que no está codificado en Base64:
Failed creating HTTP client to fetch the Discovery URI "<Discovery-document URI>" with error: Unable to decode data field, the value should be Base64 encoded
Certificado con un formato incorrecto o codificado en base64 de forma incorrecta:
Unable to connect to 'https://example.com', encountered the following error: Problem with the SSL CA cert (path? access rights?). Details: error setting certificate verify locations: CAfile: /tmp/example.pem CApath: none (The certificate could not be read, this is most likely because it's empty or contains a formatting error. Please check your configuration.)
Certificado con un formato incorrecto o codificado en base64 de forma incorrecta:
Failed fetching the Discovery URI "<Discovery-document URI>" with error: Unable to load TLS certificates.
Solución
Puedes resolver los problemas de una de las siguientes formas:
- El valor del certificado que proporcione en ClientConfig debe ser una cadena codificada en Base64 y una cadena con formato PEM. Para obtener más información, consulta Codificar certificados de CA.
- Si tu proveedor no usa certificados firmados por una autoridad de certificación raíz, debes configurar GKE Identity Service con una cadena de confianza de certificados. Para obtener más información, consulta Certificados intermedios.
Valor de certificado incorrecto
Este problema se produce cuando el certificado tiene un valor incorrecto. En este caso, el formato de los certificados es correcto, pero no coincide con el del servidor. También puede indicar que no había ningún certificado en la configuración.
Un valor de certificado se puede considerar incorrecto en cualquiera de los siguientes casos:
- Se ha compartido un valor de certificado incorrecto en ClientConfig. Un valor de certificado es incorrecto cuando el
issuer
del certificado del servidor no coincide con elsubject
del certificado configurado. - El certificado de ClientConfig no es una cadena codificada en Base64.
- La cadena de certificados no se proporciona cuando se usan certificados intermedios para emitir el certificado de servidor.
Mensaje de error
A continuación, se muestran ejemplos de mensajes de error en situaciones en las que no coincide el valor del certificado:
La cadena de certificados no está completa o no coincide con el servidor:
SSL peer certificate was not OK. Details: SSL certificate problem: unable to get local issuer certificate
La cadena de certificados no está completa (corresponde a una cadena parcial no válida que no empieza en la raíz o no es contigua):
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
La cadena de certificados es válida, pero no coincide con el servidor OIDC:
AIS was expecting the server to have a different certificate
La cadena de certificados es válida, pero no coincide con el servidor OIDC:
Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.
Solución
El valor del certificado que proporcione en ClientConfig debe incluir una cadena de certificados con el formato correcto que coincida con el proveedor de identidades. Para obtener más información sobre cómo dar formato y codificar certificados, consulta Codificar certificados de CA.
Los comandos kubectl
fallan al usar un archivo kubeconfig generado por el comando gcloud anthos auth login
Cuando usas el comando gcloud anthos auth login
con OIDC en máquinas Windows para generar un archivo kubeconfig para acceder al clúster, es posible que los comandos kubectl
fallen y se muestre el siguiente mensaje de error: The command line is too long.
Este problema se produce específicamente en sistemas Windows y no afecta a las máquinas Linux que usan el mismo archivo kubeconfig. La causa subyacente está relacionada con el tamaño del token de autenticación que genera Azure Active Directory (Azure AD) cuando un usuario pertenece a un gran número de grupos (aproximadamente entre 70 y 200 grupos, según la longitud de los nombres de los grupos).
Este token de gran tamaño provoca que falle la ejecución de kubectl
comandos porque supera la longitud máxima de la línea de comandos permitida por Windows, que es de 8191 caracteres.
Mensaje de error
$ kubectl --kubeconfig test-kubeconfig.yml get nodes The command line is too long. The command line is too long. E0102 11:02:29.115256 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:29.350238 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 The command line is too long. E0102 11:02:30.062811 24320 memcache.go:265] couldn't get current server API group list: Get "https://10.35.0.86:443/api?timeout=32s": getting credentials: exec: executable gcloud failed with exit code 1 Unable to connect to the server: getting credentials: exec: executable gcloud failed with exit code 1
Solución
Para solucionar este problema, sigue estos pasos:
Actualiza a la versión 1.28 o posterior del clúster de GKE
Si utilizas una versión de clúster de GKE anterior a la 1.28, te recomendamos que actualices a la versión compatible.
Reducir el número de grupos a los que pertenece el usuario afectado
Para solucionar el problema, reduce el número de grupos a los que pertenece el usuario autenticado por debajo del umbral problemático (aproximadamente 70 grupos).
Aumentar el número de grupos a los que pertenece el usuario afectado
La función Microsoft Entra ID tiene un límite en cuanto al número de grupos emitidos en un token. Tener entre 70 y 200 membresías de grupo puede provocar problemas de autenticación. Sin embargo, puede solucionar los problemas del proveedor de identidades aumentando el número de pertenencias a grupos por encima de este límite. Debido al comportamiento de este límite, Azure AD omite grupos del
id_token
cuando el número de miembros es excesivamente grande, lo que evita que la línea de comandos sea demasiado larga y, por lo tanto, resuelve los problemas del proveedor de identidades. Consulta la documentación de Microsoft Entra ID para confirmar el límite y obtener más información.