Autentica con OIDC y AD FS

Obtén más información sobre cómo configurar OpenID Connect (OIDC) con los Servicios de federación de Active Directory (AD FS) en Anthos GKE On-Prem (GKE On-Prem).

En este tema, el servidor de los Servicios de federación de Active Directory se configura como tu proveedor de OpenID y Active Directory se usa como la base de datos del usuario.

Para obtener una descripción general del flujo de autenticación de GKE On-Prem, consulta Autenticación. Consulta los siguientes temas para aprender a configurar OIDC con otros proveedores de OpenID:

Resumen

GKE On-Prem admite OIDC como uno de los mecanismos de autenticación para interactuar con el servidor de la API de Kubernetes del clúster de un usuario. Con OIDC, puedes administrar el acceso a los clústeres de Kubernetes mediante los procedimientos estándar de tu organización para la creación, inhabilitación y habilitación de cuentas de usuario.

Hay dos formas en que los usuarios pueden autorizar sus cuentas:

    • Pueden usar la interfaz de línea de comandos (CLI) de gcloud para iniciar el flujo de OIDC y obtener la autorización del usuario a través de una página de consentimiento basada en el navegador.
  • Usa Google Cloud Console para iniciar el flujo de autenticación de OIDC.

Antes de comenzar

  • En este tema, se asume que estás familiarizado con los siguientes conceptos de la autenticación y de OpenID:

  • Debes tener un servidor AD FS y una base de datos de usuario de Active Directory para completar los pasos de este tema.

  • OIDC solo es compatible con la versión 2016 y posteriores de AD FS.

  • Debes tener en cuenta los siguientes comportamientos en AD FS:

    • En las versiones de AD FS anteriores a 5.0, el atributo de LDAP Token-Groups Qualified Names en tu base de datos de Active Directory se mapea a la reclamación groups. En la versión 5.0 y posterior, el atributo es Token-Groups Qualified by Domain name.

    • El servidor AD FS muestra tokens que incluyen el ID del usuario, el ID de la entidad emisora, las reclamaciones openid y groups. La reclamación groups (Group en 5.0) enumera los grupos de seguridad a los que pertenece el usuario.

  • Los sistemas sin interfaz gráfica no son compatibles. Se usa un flujo de autenticación basado en el navegador para solicitar tu consentimiento y autorizar tu cuenta de usuario.

  • A fin de autenticar a través de Google Cloud Console, cada clúster que desees configurar para la autenticación de OIDC debe estar registrado en Google Cloud.

Personas

En este tema, se hace referencia a tres personas:

  • Administrador de la organización: Esta persona elige un proveedor de OpenID y registra las aplicaciones cliente en este.

  • Administrador de clústeres: Esta persona crea uno o más clústeres de usuarios y crea archivos de configuración de autenticación para los desarrolladores que usan los clústeres.

  • Desarrollador: Esta persona ejecuta cargas de trabajo en uno o más clústeres y usa OIDC para la autenticación.

Cómo crear URL de redireccionamiento

Esta sección es para los administradores de la organización.

Debes crear URL de redireccionamiento para la CLI de gcloud y Cloud Console que el proveedor de OpenID puede usar para mostrar tokens de ID.

URL de redireccionamiento de la CLI de gcloud

El SDK de Cloud se instala en la máquina local de cada desarrollador y, además, incluye la CLI de gcloud. Puedes especificar un número de puerto superior a 1,024 para la URL de redireccionamiento:

http://localhost:[PORT]/callback

en el que [PORT] es tu número de puerto.

Cuando configures el servidor AD FS, especifica http://localhost:[PORT]/callback como una de tus URL de redireccionamiento.

URL de redireccionamiento de Cloud Console

La URL de redireccionamiento de Cloud Console es:

https://console.cloud.google.com/kubernetes/oidc

Cuando configures el servidor AD FS, especifica https://console.cloud.google.com/kubernetes/oidc como una de tus URL de redireccionamiento.

Configura AD FS

Esta sección es para los administradores de la organización.

Usa un conjunto de asistentes de administración de AD FS para configurar tu servidor de AD FS y la base de datos de usuarios de AD.

  1. Abre el panel de administración de AD FS.

  2. Selecciona Grupos de aplicaciones > Acciones > Agregar un grupo de aplicaciones.

  3. Selecciona Aplicación del servidor. Ingresa el nombre y la descripción que prefieras. Haz clic en Siguiente.

  4. Ingresa sus dos URL de redireccionamiento. Se te proporcionará un ID de cliente. Así es como el servidor de AD FS identifica la CLI de gcloud y Cloud Console. Guarda el ID de cliente para más adelante.

  5. Selecciona Generar un secreto compartido. La CLI de gcloud y Cloud Console usan este secreto para autenticarse en el servidor de AD FS. Guarda el secreto para más adelante.

Configura grupos de seguridad (opcional)

Esta sección es para los administradores de la organización.

  1. En la administración de AD FS, selecciona Confianza con la parte autenticada > Agrega una nueva relación de confianza con la parte autenticada.

  2. Selecciona Compatible con reclamaciones y haz clic en Iniciar.

  3. Selecciona Ingresar datos sobre la relación de confianza de forma manual.

  4. Ingresa un nombre visible.

  5. Omite los siguientes dos pasos.

  6. Ingrese un identificador de relación de confianza con la parte autenticada. Suggestion: token-groups-claim.

  7. En Política de control de acceso, selecciona Permitir a todos. Esto significa que todos los usuarios comparten la información de su grupo de seguridad con la CLI gcloud y Cloud Console.

  8. Haz clic en Finalizar.

Asigna atributos LDAP a los nombres de reclamaciones

Esta sección es para los administradores de la organización.

  1. En la administración de AD FS, selecciona Confianza de la parte autenticada > Editar política de emisión de reclamos.

  2. Selecciona Enviar atributos LDAP como reclamos y haz clic en Siguiente.

  3. En Nombre de la regla de reclamación, ingresa groups.

  4. En Almacén de atributos, selecciona Active Directory.

  5. En la tabla, para Atributo de LDAP, selecciona lo siguiente:

    • AD FS versión 5.0 y posteriores: Grupos de token calificados por nombre de dominio
    • Versiones de AD FS anteriores a 5.0: Grupos de tokens: nombres calificados
  6. En Tipo de reclamación saliente, selecciona:

    • AD FS versión 5.0 y posteriores: Grupo
    • Versiones de AD FS anteriores a la 5.0: groupos
  7. Haz clic en Finalizar y, luego, en Aplicar.

Registra la CLI de gcloud y Cloud Console con AD FS

Esta sección es para los administradores de la organización.

Abre una ventana de PowerShell en modo de administrador y, luego, ingresa este comando:

Grant-AD FSApplicationPermission `
    -ClientRoleIdentifier "[CLIENT_ID]" `
    -ServerRoleIdentifier [SERVER_ROLE_IDENTIFIER] `
    -ScopeName "allatclaims", "openid"

Donde:

  • [CLIENT_ID] es el ID de cliente que obtuviste antes.

  • [SERVER_ROLE_IDENTIFIER] es el identificador de reclamo que ingresaste antes. Recuerda que el identificador sugerido era token-groups-claim.

Propaga la especificación oidc en el archivo de configuración local de GKE

Esta sección es para los administradores de clústeres.

Antes de crear un clúster de usuarios, genera un archivo de configuración de GKE On-Prem mediante gkectl create-config cluster. La configuración incluye la siguiente especificación oidc. Debes propagar oidc con los valores específicos en tu proveedor:

oidc:
  issuerURL:
  kubectlRedirectURL:
  clientID:
  clientSecret:
  username:
  usernamePrefix:
  group:
  groupPrefix:
  scopes:
  extraParams:
  deployCloudConsoleProxy:
  caPath:
  • issuerURL: obligatorio. URL de tu proveedor de OpenID, como https://example.com/adfs. Las aplicaciones cliente, como la CLI de gcloud y Cloud Console, envían solicitudes de autorización a esta URL. El servidor de la API de Kubernetes usa esta URL a fin de descubrir claves públicas para la verificación de tokens. Debe usar HTTPS.
  • kubectlRedirectURL: (Obligatorio). Es la URL de redireccionamiento que configuraste antes para la CLI de gcloud.
  • clientID: obligatorio. Es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID. La CLI de gcloud y Cloud Console usan este ID.
  • clientSecret: Opcional El secreto de la aplicación cliente. La CLI de gcloud y Cloud Console usan este secreto.
  • username: Opcional Es la reclamación de JWT para usar como nombre de usuario. El valor predeterminado es sub, que se espera que sea un identificador único del usuario final. Puedes elegir otras reclamaciones, como email o name, según el proveedor de OpenID. Sin embargo, las reclamaciones que no sean email tienen el prefijo de la URL de la entidad emisora para evitar conflictos de nombres con otros complementos.
  • usernamePrefix: Opcional Es el prefijo que se antepone a los reclamos de nombre de usuario para evitar conflictos con los nombres existentes. Si no proporcionas este campo y username es un valor distinto de email, el prefijo se configura de forma predeterminada como issuerurl#. Puedes usar el valor - para inhabilitar todos los prefijos.
  • group: Opcional Reclamación de JWT que el proveedor usará para mostrar tus grupos de seguridad.
  • groupPrefix: Opcional Es el prefijo que se antepone a las reclamaciones de grupo para evitar conflictos con los nombres existentes. Por ejemplo, con un grupo foobar y un prefijo gid-, gid-foobar. De forma predeterminada, este valor está vacío, y no hay prefijo.
  • scopes: Opcional Alcances adicionales para enviar al proveedor de OpenID como una lista delimitada por comas.
    • Para la autenticación con Microsoft Azure, pasa el offline_access.

  • extraParams: Opcional Parámetros de clave-valor adicionales para enviar al proveedor de OpenID como una lista delimitada por comas.
  • deployCloudConsoleProxy: Opcional Especifica si se debe implementar un proxy inverso en el clúster a fin de permitir que Google Cloud Console acceda al proveedor de OIDC local para autenticar usuarios. El valor debe ser una string: "true" o "false". Si tu proveedor de identidad no es accesible a través de la Internet pública y deseas autenticarte con Google Cloud Console, este campo debe configurarse como "true".
  • caPath: Opcional Es la ruta de acceso al certificado de la autoridad certificada (CA) que emitió el certificado web de tu proveedor de identidad. Es posible que este valor no sea necesario. Por ejemplo, si el certificado de tu proveedor de identidad lo emitió una CA pública conocida, entonces no deberías proporcionar un valor aquí. Sin embargo, si deployCloudConsoleProxy es “true”, se debe proporcionar este valor, incluso para una CA pública conocida.

Ejemplo: Autorización de usuarios y grupos

Muchos proveedores codifican las propiedades de identificación del usuario, como los ID de correo electrónico y de usuario, en un token. Sin embargo, estas propiedades tienen riesgos implícitos para las políticas de autenticación:

  • Los ID de usuario pueden dificultar la lectura y auditoría de las políticas.
  • Los correos electrónicos pueden crear un riesgo de disponibilidad (si un usuario cambia su correo electrónico principal) y, un posible riesgo de seguridad (si se puede reasignar un correo electrónico).

Por lo tanto, se recomienda usar políticas de grupo, ya que un ID de grupo puede ser persistente y más fácil de auditar.

Supongamos que tu proveedor crea tokens de identidad que incluyen los siguientes campos:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

En este formato de token, propagarías la especificación oidc del archivo de configuración de la siguiente manera:

issueruri: 'https://server.example.com'
username: 'sub'
usernameprefix: 'uid-'
group: 'groupList'
groupprefix: 'gid-'
extraparams: 'resource=token-groups-claim'
...

Después de crear el clúster de usuario, puedes usar el control de acceso según la función (RBAC) de Kubernetes para otorgar acceso privilegiado a los usuarios autenticados. Por ejemplo, puedes crear un ClusterRole que otorgue a sus usuarios acceso de solo lectura a los secretos del clúster y crear un recurso ClusterRoleBinding para vincular la función al grupo autenticado:

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  # The resource type for which access is granted
  resources: ["secrets"]
  # The permissions granted by the ClusterRole
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Cómo crear y distribuir el archivo de configuración de autenticación

Esta sección es para los administradores de clústeres.

Después de crear un clúster de usuarios, debes crear un archivo de configuración de autenticación para ese clúster. Puedes configurar varios clústeres en un solo archivo de configuración de autenticación. Debes proporcionar cada archivo de configuración de autenticación a los usuarios que desean autenticarse en cada uno de esos clústeres.

Crea el archivo de configuración de autenticación

Para crear el archivo de configuración de autenticación en el directorio actual, ejecuta el siguiente comando gkectl:

gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG]

En el ejemplo anterior, [USER_CLUSTER_KUBECONFIG] es la ruta de acceso al archivo kubeconfig de tu clúster de usuarios. Cuando ejecutaste gkectl create cluster para crear tu clúster de usuarios, se creó el archivo kubeconfig.

Resultado: Tu archivo de configuración de autenticación, llamado kubectl-anthos-config.yaml, se crea en el directorio actual.

Agrega varios clústeres al archivo de configuración de autenticación

Puedes almacenar los detalles de la configuración de autenticación de varios clústeres dentro de un solo archivo de configuración de autenticación.

Puedes usar el comando siguiente para combinar detalles de la autenticación de los clústeres de usuarios adicionales en un archivo de configuración de autenticación existente. Si tienes un archivo de configuración de autenticación existente, puedes combinar o los detalles de la autenticación de los clústeres de usuarios adicionales:

  • Combinar los detalles adicionales de la autenticación del clúster de usuarios en ese archivo de configuración de autenticación existente.
  • Combina los detalles de la autenticación de los clústeres de usuarios adicionales en un archivo nuevo.

Por ejemplo, es posible que debas administrar los archivos de configuración de autenticación anthos-config-1cluster.yaml y anthos-config-3clusters.yaml para satisfacer las necesidades de acceso de los diversos grupos de usuarios de tu organización.

Para agregar clústeres de usuarios adicionales a tu archivo de configuración de autenticación existente, haz lo siguiente:

  1. Asegúrate de que cada clúster tenga un nombre único. Si tus clústeres tienen los mismos nombres, no puedes combinarlos en el mismo archivo de configuración de autenticación. Ten en cuenta que después de que se crea un clúster, no se le puede cambiar el nombre.

  2. Ejecuta el siguiente comando de gkectl para combinar detalles de configuración:

    gkectl create-login-config --kubeconfig [USER_CLUSTER_KUBECONFIG] \
    --merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

    donde

    • [USER_CLUSTER_KUBECONFIG] especifica el archivo kubeconfig del clúster de usuarios que deseas agregar.

    • [IN_AUTH_CONFIG_FILE] especifica la ruta del archivo de configuración de autenticación existente que deseas combinar con la información de los clúster adicionales.

    • [OUT_AUTH_CONFIG_FILE] especifica la ruta del archivo en el que deseas almacenar la configuración de autenticación combinada:

      • Especifica el mismo archivo que [IN_AUTH_CONFIG_FILE] para combinar la información de los clústeres adicionales en ese archivo existente.
      • Especifica una ruta de acceso y un nombre de archivo nuevos para combinar los detalles de la configuración de autenticación en un archivo nuevo.

Cómo distribuir el archivo de configuración de autenticación

Para permitir que tus usuarios se autentiquen en tus clústeres de usuarios, debes otorgarles acceso a uno o más de los archivos de configuración de autenticación que creaste. Ten en cuenta que, en los pasos siguientes, se usa el nombre de archivo predeterminado y la ubicación que espera la CLI de gcloud. Para obtener información sobre el uso de nombres y ubicaciones alternativos, consulta Configuración personalizada.

Considera la posibilidad de distribuir los archivos de configuración de autenticación de la siguiente manera:

  • Aloja el archivo en una URL accesible. Si incluyes la marca --login-config en el comando gcloud anthos auth login, la CLI de gcloud obtendrá el archivo de configuración de autenticación de esa ubicación.

    Considera la posibilidad de alojar el archivo en un host seguro. Consulta la marca --login-config-cert de la CLI de gcloud a fin de obtener más información sobre el uso de certificados de PEM para el acceso HTTPS seguro.

  • Proporciona manualmente el archivo a cada usuario. Después de que los usuarios descarguen el archivo, debes indicarles cómo almacenarlo en la ubicación predeterminada y con el nombre de archivo predeterminado que espera la CLI de gcloud.

    Por ejemplo, los usuarios pueden ejecutar los siguientes comandos para almacenar el archivo de configuración de autenticación con el nombre de archivo kubectl-anthos-config.yaml predeterminado en la ubicación predeterminada:

    Linux

    mkdir -p  $HOME/.config/google/anthos/
    cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

    macOS

    mkdir -p  $HOME/Library/Preferences/google/anthos/
    cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

    Windows

    md "%APPDATA%\google\anthos"
    copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

    En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

  • Usa tus herramientas internas para enviar el archivo de configuración de autenticación a la máquina de cada usuario. Por ejemplo, puedes usar tus herramientas para enviar archivos mediante el nombre de archivo predeterminado kubectl-anthos-config.yaml a sus ubicaciones predeterminadas en la máquina de cada usuario:

    Linux

    $HOME/.config/google/anthos/kubectl-anthos-config.yaml

    macOS

    $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

    Windows

    %APPDATA%\google\anthos\kubectl-anthos-config.yaml

Configuración personalizada

La CLI de gcloud espera que el archivo de configuración de autenticación se almacene en la ubicación predeterminada con el nombre de archivo predeterminado kubectl-anthos-config.yaml como se mencionó en la sección anterior. Sin embargo, tienes la opción de cambiar el nombre del archivo de configuración de autenticación o almacenarlo en una ubicación alternativa. Si el nombre y la ubicación del archivo son diferentes de los predeterminados, debes agregar la marca --login-config en cada comando que ejecutes cuando te autentiques con el clúster. La marca del comando adicional pasa a la ruta de acceso y al nombre de archivo personalizados. Para obtener más información sobre la marca del comando, consulta Cómo autenticar a través de la CLI de gcloud.

Instala la CLI de gcloud

Esta sección es para los desarrolladores y los administradores de clústeres.

Cada desarrollador o usuario que necesite autenticarse con un clúster debe instalar el SDK de Cloud en su propia máquina. Los comandos de autenticación de Anthos se integraron en la CLI de gcloud como el componente anthos-auth.

Cómo quitar complementos anteriores

Debes desinstalar el complemento anterior antes de poder usar el componente anthos-auth del SDK de Cloud. Puedes verificar si en tu máquina existe uno de los complementos anteriores basados en kubectl mediante la ejecución del siguiente comando:

kubectl anthos version

  • Si el comando responde con Error: unknown command "anthos" for "kubectl", significa que no se encontró ningún complemento y puedes pasar a la siguiente sección.

  • Si se encontró una versión 1.0beta del complemento, debes localizar el objeto binario del complemento y borrarlo. Ejecuta el siguiente comando a fin de enumerar la ubicación y, luego, usa esa ubicación para quitar el objeto binario de tu máquina:

    kubectl plugin list

Instala el SDK de Cloud y la CLI de gcloud

Para instalar la CLI de gcloud, primero debes instalar el SDK de Cloud:

  1. Instala el SDK de Cloud, pero omite el comando de gcloud init.

  2. Ejecuta los siguientes comandos para instalar el componente de anthos-auth:

    gcloud components update
    gcloud components install anthos-auth
  3. Ejecuta cualquiera de los siguientes comandos para verificar que la CLI de gcloud se haya instalado correctamente:

    gcloud anthos auth
    gcloud anthos auth login

    Resultado: cada comando debe responder con detalles de los argumentos obligatorios y las opciones disponibles.

Cómo obtener el archivo de configuración de autenticación

Esta sección es para los desarrolladores.

Tu administrador es responsable de crear el archivo de configuración de autenticación y de proporcionarlo. Para obtener más detalles, consulta Distribuye el archivo de configuración de autenticación.

De forma predeterminada, la CLI de gcloud usa un nombre de archivo y una ubicación de almacenamiento predeterminados para tu archivo de configuración de autenticación. Si se proporcionó el archivo de forma manual y necesitas guardarlo en tu máquina, usa los valores predeterminados para simplificar los comandos de autenticación de gcloud.

Usa los siguientes comandos para copiar el archivo de configuración de autenticación en la ubicación predeterminada:

Linux

mkdir -p  $HOME/.config/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/.config/google/anthos/kubectl-anthos-config.yaml

En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

macOS

mkdir -p  $HOME/Library/Preferences/google/anthos/
cp [AUTH_CONFIG_FILE] $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml

En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

Windows

md "%APPDATA%\google\anthos"
copy [AUTH_CONFIG_FILE] "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

En el ejemplo anterior, [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación. Por ejemplo: kubectl-anthos-config.yaml.

Si eliges usar un nombre de archivo o una ubicación diferentes, tienes la opción de incluir la marca --login-config en cada una de tus solicitudes de autenticación. Consulta la siguiente sección para obtener detalles sobre el uso del comando gcloud anthos auth login.

Autentica mediante clústeres de usuarios

Esta sección es para los desarrolladores.

Ahora que el SDK de Cloud está instalado en tu máquina y que el administrador te proporcionó el archivo de configuración de autenticación, puedes usar la CLI de gcloud o Cloud Console para autenticarte con tus clústeres.

Autentica a través de la CLI de gcloud

Ejecuta los comandos gcloud para autenticar con tus clústeres:

  1. Ejecuta el comando gcloud anthos auth login para iniciar el flujo de autenticación:

    gcloud anthos auth login \
     --cluster [CLUSTER_NAME] \
     --user [USER_NAME] \
     --login-config [AUTH_CONFIG_FILE_PATH] \
     --login-config-cert [CA_CERT_PEM_FILE] \
     --kubeconfig [USER_CLUSTER_KUBECONFIG]

    Donde:

    • [CLUSTER_NAME] (opcional) especifica el nombre de tu clúster de usuarios. Si se omite esta marca, se te solicitará que elijas entre los clústeres de usuarios que se especifican en el archivo de configuración de autenticación.

    • [USER_NAME] (opcional) especifica el nombre de usuario de las credenciales almacenadas en el archivo kubeconfig. El valor predeterminado es [CLUSTER_NAME]-anthos-default-user.

    • [AUTH_CONFIG_FILE_PATH] (opcional) especifica la ruta de acceso o la URL personalizada en la que se almacena o aloja el archivo de configuración de autenticación. Puedes omitir este parámetro si el archivo está en la ubicación predeterminada. Ejemplo: --login-config /path/to/custom/authentication-config.yaml

    • [CA_CERT_PEM_FILE] (opcional) especifica la ruta a un archivo de certificado de PEM de tu CA. Si tu archivo de configuración de autenticación está alojado de forma segura, puedes usar una conexión HTTPS para acceder a este. Ejemplo: --login-config-cert my-cert.pem

    • [USER_CLUSTER_KUBECONFIG] (opcional) especifica la ruta de acceso personalizada al archivo kubeconfig de tu clúster de usuarios. Los tokens de ID de OIDC que muestra tu proveedor de OpenID se almacenan en el archivo kubeconfig.

      Usa esta marca si tu archivo kubeconfig se encuentra en una ubicación que no sea la predeterminada. Si se omite esta marca, se crea un nuevo archivo kubeconfig en la ubicación predeterminada. Ejemplo: --kubeconfig /path/to/custom.kubeconfig

    Ejemplos:

    • Autentica en un clúster específico:

      gcloud anthos auth login --cluster my-production-cluster
      
    • Usa un mensaje para seleccionar con qué clúster realizar la autenticación:

      gcloud anthos auth login
      

      Resultado:

      Please use the --cluster flag to specify a cluster from the list below:
      Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
      1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
      2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
      3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
      
    • Usa un archivo de configuración de autenticación alojado:

      gcloud anthos auth login \
       --cluster my-production-cluster \
       --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
       --login-config-cert my-cert.pem
      
  2. Ingresa tus credenciales en la pantalla de consentimiento basada en el navegador que se abre.

  3. Verifica que la autenticación se haya realizado correctamente mediante la ejecución de uno de los comandos kubectl para recuperar los detalles de tu clúster. Por ejemplo:

    kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

Resultado: Tu archivo kubeconfig ahora contiene un token de ID que tus comandos kubectl usarán para autenticarse en el servidor de la API de Kubernetes de tu clúster de usuarios.

Usa SSH para autenticarte desde una máquina remota

Supongamos que deseas establecer una conexión SSH a una máquina remota y autenticarte en un clúster de usuarios desde esta. Para ello, el archivo de configuración de autenticación debe estar en la máquina remota y debes poder acceder al proveedor de Open ID desde tu máquina local.

En tu máquina local, ejecuta el siguiente comando:

ssh [USER_NAME]@[REMOTE_MACHINE] -L [LOCAL_PORT]:localhost:[REMOTE_PORT]

Donde:

  • [USER_NAME] y [REMOTE_MACHINE] son los valores estándar que se usan para acceder con SSH.

  • [LOCAL_PORT] es un puerto abierto de tu elección que se encuentra en tu máquina local y que usarás para acceder a la máquina remota.

  • [REMOTE_PORT] es el puerto que configuraste para tu URL de redireccionamiento de OIDC. Puedes encontrarlo en el campo kubectlRedirectURI del archivo de configuración de autenticación.

En la shell SSH, ejecuta el siguiente comando para iniciar la autenticación:

gcloud anthos auth login --login-config [AUTH_CONFIG_FILE]

En el ejemplo anterior, [AUTH_CONFIG_FILE] es la ruta de tu archivo de configuración de autenticación en la máquina remota.

En tu máquina local, en un navegador, ve a http://localhost:[LOCAL_PORT]/login y completa el flujo de acceso de OIDC.

Ahora, el archivo kubeconfig de tu máquina remota tiene el token que necesitas para acceder al clúster de usuarios.

En tu shell SSH, verifica que tengas acceso al clúster de usuarios:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

Autentícate a través de Google Cloud Console

Inicia el flujo de autenticación desde la página de clústeres de Kubernetes en Cloud Console:

  1. Abre Cloud Console.

    Visitar la página Clústeres de Kubernetes

  2. Localiza tu clúster de GKE On-Prem en la lista y haz clic en Acceder.

  3. Selecciona Autenticar con el proveedor de identidad configurado para el clúster y, luego, haz clic en ACCEDER.

    Se te redireccionará a tu proveedor de identidad, en el que es posible que debas acceder a Cloud Console o consentir que este acceda a tu cuenta. Luego, se te redireccionará a la página Clústeres de Kubernetes en Cloud Console.

Soluciona problemas de la configuración de OIDC

Revisa los siguientes comportamientos y errores para ayudarte a resolver los problemas de OIDC:

La configuración no es válida
Si Cloud Console no puede leer la configuración de OIDC de tu clúster, el botón ACCEDER estará inhabilitado.
La configuración del proveedor no es válida
Si la configuración de tu proveedor de identidad no es válida, verás una pantalla de error del proveedor de identidad después de hacer clic en ACCEDER. Sigue las instrucciones específicas del proveedor para configurar correctamente el proveedor o el clúster.
Los permisos no son válidos
Si completas el flujo de autenticación, pero aún no ves los detalles del clúster, asegúrate de haber otorgado los permisos de RBAC correctos a la cuenta que usaste con OIDC. Ten en cuenta que podría ser una cuenta diferente de la que usas para acceder a Cloud Console.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Es posible que aparezca este error si el servidor de autorización solicita el consentimiento, pero no se proporcionó el parámetro de autenticación requerido. Proporciona el parámetro prompt=consent en el campo oidc: extraparams del archivo de configuración de GKE On-Prem y vuelve a generar el archivo de autenticación del cliente con la marca --extra-params prompt=consent.

Próximos pasos