Versión 1.10. Ya no se admite esta versión. Para obtener más información, consulta la política de asistencia de la versión. Para obtener información sobre cómo actualizar a la versión 1.11, consulta Actualiza Anthos en Bare Metal en la documentación de la versión 1.11.

Versiones compatibles disponibles: 1.14 | 1.13 | 1.12

Soluciona problemas de OIDC en clústeres de Anthos en equipos físicos

En esta página, se muestra cómo identificar y resolver problemas de OpenID Connect (OIDC) con clústeres de Anthos en equipos físicos.

Identifica los problemas de OIDC

Cuando OIDC no funciona en los clústeres de Anthos en equipos físicos, por lo general, la especificación de OIDC dentro del archivo de configuración del clúster se configuró de forma incorrecta. En esta sección, se proporcionan instrucciones para revisar los registros y la especificación de OIDC a fin de identificar la causa de un problema de OIDC.

Revisa los registros del servicio de identidad de Anthos

El servicio de identidad de Anthos es compatible con OIDC en clústeres de Anthos en equipos físicos.

Usa kubectl logs para imprimir los registros del servicio de identidad de Anthos:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n anthos-identity-service logs \
deployment/ais --all-containers=true

Revisa los registros para detectar errores que pueden ayudarte a diagnosticar problemas de OIDC.

Si no puedes autenticarte con OIDC, los registros del servicio de identidad de Anthos proporcionan la información más relevante y útil para depurar el problema.

Por ejemplo, si la especificación de OIDC (en el archivo de configuración del clúster) tiene un error de tipeo en el campo issuerURL, como htps://accounts.google.com (falta una “t” en https), los registros del servicio de identidad de Anthos contendrán una entrada como la siguiente:
```
OIDC (htps://accounts.google.com) - Unable to fetch JWKs needed to validate OIDC ID token.
```
Si identificaste un problema de configuración en los registros, ve a Reconfigura OIDC.
Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con la Atención al cliente de Cloud.

La Atención al cliente de Cloud necesitará los registros del servicio de identidad de Anthos y la especificación de OIDC para diagnosticar y resolver los problemas de OIDC.

Verifica la especificación de OIDC en tu clúster

La información de OIDC para el clúster se especifica en el objeto clientconfig en el espacio de nombres kube-public.

Usa kubectl get a fin de imprimir el recurso OIDC para tu clúster:
```
kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public get \
clientconfig.authentication.gke.io default -o yaml
```
Nota: La especificación clientconfig puede diferir un poco de la especificación de OIDC en el archivo de configuración del clúster. Por ejemplo, la URL del proveedor de OIDC se especifica con el campo issuerURL en el archivo de configuración del clúster, pero el objeto clientconfig muestra esta información en el campo issuerURI.
Revisa los valores de los campos a fin de confirmar que la especificación esté configurada de forma correcta para tu proveedor de OIDC.
Si identificaste un problema de configuración en la especificación, continúa con Reconfiguración de OIDC.
Si no puedes diagnosticar y resolver el problema por tu cuenta, comunícate con la Atención al cliente de Cloud.

La Atención al cliente de Cloud necesitará los registros del servicio de identidad de Anthos y la especificación de OIDC para diagnosticar y resolver problemas de OIDC.

Vuelve a configurar OIDC

Si identificaste problemas en los registros del servicio de identidad de Anthos o en el objeto clientconfig, puedes volver a configurar OIDC en tu clúster (sin volver a crearlo) para solucionarlos. Para volver a configurar OIDC, edita el objeto predeterminado de KRM de tipo clientconfig en el espacio de nombres kube-public:

kubectl --kubeconfig CLUSTER_KUBECONFIG -n kube-public edit clientconfig default

Los detalles de la CRD de ClientConfig se usan a fin de configurar OIDC para Cloud Console y el complemento de autenticación para Anthos. Para obtener más detalles sobre la información de OIDC incluida en la CRD de ClientConfig, consulta el siguiente YAML y la tabla asociada de descripciones de campo.

authentication:
  - name: oidc
    oidc:
      certificateAuthorityData: CERTIFICATE_STRING
      clientID: CLIENT_ID
      clientSecret: CLIENT_SECRET
      cloudConsoleRedirectURI: "http://console.cloud.google.com/kubernetes/oidc"
      deployCloudConsoleProxy: PROXY_BOOLEAN
      extraParams: EXTRA_PARAMS
      groupsClaim: GROUPS_CLAIM
      groupPrefix: GROUP_PREFIX
      issuerURI: ISSUER_URI
      kubectlRedirectURI: KUBECTL_REDIRECT_URI
      scopes: SCOPES
      userClaim: USER_CLAIM
      userPrefix: USER_PREFIX
    proxy: PROXY_URL

En la siguiente tabla, se describen los campos del objeto oidc de la CRD de ClientConfig.

Campo	Obligatorio	Descripción	Formato
nombre	Sí	El nombre de la configuración de OIDC que deseas crear.	String
certificateAuthorityData	No	Un certificado con codificación PEM codificada en `base64` para el proveedor de OIDC. Para crear la string, codifica el certificado, incluidos los encabezados, en `base64`. Incluye la string resultante en `certificateAuthorityData` como una sola línea. Ejemplo: `certificateAuthorityData: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tC...k1JSUN2RENDQWFT==`	String
clientID	Sí	El ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID.	String
clientSecret	No	Secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC	String
extraParams	No	Los parámetros de clave-valor adicionales para enviar al proveedor de OpenID. Si autorizas un grupo, pasa `resource=token-groups-claim`. Si el servidor de autorización solicita consentimiento para la autenticación con Microsoft Azure y Okta, establece `extraParams` en `prompt=consent`. En Cloud Identity, establece `extraParams` en `prompt=consent,access_type=offline`.	Lista delimitada por comas
groupsClaim	No	La reclamación de JWT que el proveedor usa para mostrar los grupos de seguridad.	String
groupPrefix	No	El prefijo que se antepone a las reclamaciones de grupos para evitar conflictos con los nombres existentes. Por ejemplo, si tienes dos grupos llamados `foobar`, agrega un prefijo `gid-`. El grupo resultante es `gid-foobar`.	String
issuerURI	Sí	La URL a la que se envían las solicitudes de autorización al OpenID, como `https://example.com/adfs`. El servidor de la API de Kubernetes usa esta URL a fin de descubrir claves públicas para la verificación de tokens. El URI debe usar HTTPS.	String de URL
kubectlRedirectURI	Sí	La URL de redireccionamiento que usa `kubectl` para la autorización.	String de URL
scopes	Sí	Los permisos adicionales que se deben enviar al proveedor de OpenID. Microsoft Azure y Okta requieren el permiso `offline_access`.	Lista delimitada por comas
userClaim	No	Es la reclamación de JWT que se debe usar como nombre de usuario. Puedes elegir otras reclamaciones, como el correo electrónico o el nombre, según el proveedor de OpenID. Sin embargo, las reclamaciones que no sean de correo electrónico tienen el prefijo de la URL de la entidad emisora para evitar conflictos de nombres.	String
userPrefix	No	El prefijo que se antepone a las reclamaciones de nombre de usuario para evitar conflictos con los nombres existentes.	String
proxy	No	Servidor proxy para usar en el método `auth`, si corresponde. Por ejemplo: `http://user:password@10.10.10.10:8888.`	String