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, es el resultado de un problema de configuración en la especificación de OIDC del archivo de configuración del clúster. 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.

  1. 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
    
  2. 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.
    
  3. Si identificaste un problema de configuración en los registros, ve a Reconfigura OIDC.

  4. 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.

  1. 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
    
  2. Revisa los valores de los campos a fin de confirmar que la especificación esté configurada de forma correcta para tu proveedor de OIDC.

  3. Si identificaste un problema de configuración en la especificación, continúa con Reconfiguración de OIDC.

  4. 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 la consola de Google Cloud 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 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 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 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 La URL de redireccionamiento que usa kubectl para la autorización. String de URL
scopes 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 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