Soluciona problemas del proveedor de OIDC

En este documento, se proporciona orientación para solucionar problemas relacionados con los proveedores de identidad de OIDC y AzureAD en GKE Identity Service.

El formato del certificado es incorrecto

Este problema ocurre cuando el valor del certificado tiene errores de formato. Los problemas de formato pueden deberse a valores de certificado que no están codificados en base64 y a valores que están codificados en base64, pero son incorrectos. También puede surgir un problema si el certificado no está firmado por una autoridad de certificación raíz o no se proporciona una cadena de confianza con el formato correcto.

Mensajes de error

Los siguientes ejemplos son de mensajes de error para situaciones en las que el formato del certificado es incorrecto:

  • Certificado sin codificación 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 formato incorrecto o codificado en base64, pero incorrecto: 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 formato incorrecto o codificado en base64, pero incorrecto: 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 maneras:

  • El valor del certificado que proporcionas en ClientConfig debe ser una cadena codificada en base64 y una cadena con formato PEM. Para obtener más información, consulta Codifica certificados de la AC.
  • 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.

El valor del certificado es incorrecto

Este problema ocurre cuando el certificado tiene un valor que no coincide. En este caso, el formato es correcto, pero no coincide con el servidor. También puede indicar que no había certificados en la configuración.

Un valor de certificado se puede considerar incorrecto en cualquiera de las siguientes situaciones:

  • Se comparte un valor de certificado incorrecto en ClientConfig. Un valor de certificado es incorrecto cuando el issuer del certificado del servidor no coincide con el subject del certificado configurado.
  • El certificado de la ClientConfig no es una cadena codificada en base64.
  • Cuando se usan certificados intermedios para emitir el certificado del servidor, no se proporciona la cadena de certificados.

Mensaje de error

Los siguientes ejemplos son de mensajes de error que aparecen en situaciones en las que hay una falta de coincidencia en el valor de los certificados:

  • 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 de OIDC: AIS was expecting the server to have a different certificate

  • La cadena de certificados es válida, pero no coincide con el servidor de OIDC: Failed fetching the Discovery URI "<Discovery-document URI>" with error: The server's TLS certificate did not match expectations.

Solución

El valor de los certificados que proporcionas en la ClientConfig debe incluir una cadena de certificados con el formato correcto que coincida con el proveedor de identidad. Para obtener más información sobre cómo dar formato a los certificados y codificarlos, consulta Codifica certificados de la AC.

Los comandos de kubectl fallan cuando se usa un archivo kubeconfig generado con el comando gcloud anthos auth login

Cuando usas el comando gcloud anthos auth login con OIDC en máquinas Windows con el objetivo de generar un archivo kubeconfig para el acceso al clúster, es posible que los comandos kubectl fallen con el siguiente mensaje de error: The command line is too long. Este problema ocurre específicamente en sistemas Windows y no afecta a las máquinas Linux que usan el mismo archivo kubeconfig. La causa subyacente se relaciona con el tamaño del token de autenticación generado por Azure Active Directory (Azure AD) cuando un usuario pertenece a una gran cantidad de grupos (alrededor de entre 70 y 200 grupos, según la longitud de los nombres de los grupos).

Este token grande hace que falle la ejecución de los comandos de kubectl porque supera la longitud máxima de la línea de comandos permitida en Windows, que es de 8,191 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, haz lo siguiente:

  • Actualiza a la versión 1.28 o posterior del clúster de GKE

    Si ejecutas una versión del clúster de GKE anterior a la 1.28, te recomendamos que actualices a la versión compatible.

  • Reduce la cantidad de membresías a grupos a los que pertenece el usuario afectado

    Reducir la cantidad de grupos a los que pertenece el usuario que se autentica por debajo del umbral problemático (alrededor de 70 grupos) puede resolver el problema.

  • Aumenta la cantidad de membresías a grupos a los que pertenece el usuario afectado

    La función de Microsoft Entra ID tiene un límite para la cantidad de grupos que se emiten en un token. Tener entre 70 y 200 membresías a grupos puede causar problemas de autenticación. Sin embargo, puedes resolver los problemas del proveedor de identidad aumentando la cantidad de membresías a grupos más allá de este límite. Debido al comportamiento de este límite, Azure AD omite grupos de id_token cuando la cantidad de membresías se vuelve demasiado grande. Esto evita que la línea de comandos se vuelva demasiado larga, lo que resuelve los problemas del proveedor de identidad. Revisa la Documentación de Microsoft Entra ID para confirmar el límite y obtener más detalles.