Autentica con OpenID Connect (OIDC)

Aprende a configurar GKE On-Prem a fin de usar OpenID Connect (OIDC) para la autenticación en clústeres de usuario. En este tema, se cubre el proceso en general para ayudarte a comprender cómo configurar cualquier proveedor de OpenID.

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

Descripción general

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

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

  • Usa Google Cloud CLI 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 supone que estás familiarizado con los siguientes conceptos de autenticación y de OpenID:

  • 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 la cuenta de usuario.

  • Si quieres realizar la autenticación 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 con este.

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

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

Elige un proveedor de OpenID

Esta sección está destinada a los administradores de la organización.

Puedes usar el proveedor de OpenID que desees. Para ver una lista de proveedores certificados, consulta OpenID Certification (Certificación de OpenID).

Para los siguientes proveedores de OpenID, consulta los pasos de configuración específicos en los siguientes temas:

Crea URL de redireccionamiento

Esta sección está destinada a los administradores de la organización.

Debes crear las URL de redireccionamiento para la CLI de gcloud y la consola de Google Cloud que el proveedor de OpenID podrá usar a fin de mostrar tokens de ID.

URL de redireccionamiento de la CLI de gcloud

Google Cloud CLI se instala en la máquina local de cada desarrollador e incluye la CLI de gcloud. Puedes especificar un número de puerto superior a 1024 para la URL de redireccionamiento:

http://localhost:[PORT]/callback

En el ejemplo anterior, [PORT] es el número del puerto.

Cuando configures tu proveedor de OpenID, especifica http://localhost:[PORT]/callback como una de las URL de redireccionamiento. La forma de hacerlo dependerá del proveedor.

URL de redireccionamiento de la consola de Google Cloud

La URL de redireccionamiento de la consola de Google Cloud es la siguiente:

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

Cuando configures tu proveedor de OIDC, especifica https://console.cloud.google.com/kubernetes/oidc como una de las URL de redireccionamiento. La forma en que lo hagas depende del proveedor.

Registra las aplicaciones cliente con el proveedor de OpenID

Esta sección está destinada a los administradores de la organización.

Antes de que los desarrolladores puedan usar la CLI de gcloud o la consola de Google Cloud con el proveedor de OpenID, debes registrar esos dos clientes con el proveedor de OpenID. El registro incluye estos pasos:

  • Obtén más información sobre el URI de la entidad emisora del proveedor. Aquí es donde la CLI de gcloud o la consola de Google Cloud envía solicitudes de autenticación.

  • Proporcionar al proveedor la URL de redireccionamiento de la CLI de gcloud.

  • Proporciona al proveedor la URL de redireccionamiento para la consola de Google Cloud. Esta es https://console.cloud.google.com/kubernetes/oidc

  • Establece un ID de cliente. Este es el ID que el proveedor usa para identificar la CLI de gcloud y la consola de Google Cloud.

  • Establece un único secreto del cliente. La CLI de gcloud y la consola de Google Cloud usan este secreto para la autenticación con el proveedor de OpenID.

  • Establece un permiso personalizado que la CLI de gcloud o la consola de Google Cloud puedan usar para solicitar los grupos de seguridad del usuario.

  • Establecer un nombre de reclamación personalizado que el proveedor usará para mostrar los grupos de seguridad del usuario

La forma en la que realices estos pasos depende del proveedor de OpenID.

Propaga la especificación oidc en el archivo de configuración de GKE On-Prem

Esta sección está destinada a los administradores de clústeres.

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

oidc:
  issuerURL:
  kubectlRedirectURL:
  clientID:
  clientSecret:
  username:
  usernamePrefix:
  group:
  groupPrefix:
  scopes:
  extraParams:
  deployCloudConsoleProxy:
  caPath:
  • issuerURL: Obligatoria. Es la URL del proveedor de OpenID, como "https://example.com/adfs". Las aplicaciones cliente, como la CLI de gcloud y la consola de Google Cloud, envían solicitudes de autorización a esta URL. El servidor de la API de Kubernetes usa esta URL a fin de buscar claves públicas para la verificación de tokens. Debes usar HTTPS.
  • kubectlRedirectURL:: Obligatoria. 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 la consola de Google Cloud usan este ID.
  • clientSecret: Opcional. Es el secreto de la aplicación cliente. La CLI de gcloud y la consola de Google Cloud usan este Secret.
  • username: Opcional. Es la reclamación de JWT que se debe 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, en función del proveedor de OpenID. Sin embargo, a las reclamaciones que no sean email se les agrega 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 las reclamaciones 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 configurará de forma predeterminada como issuerurl#. Puedes usar el valor - para inhabilitar todos los prefijos.
  • group: Opcional. Es la reclamación de JWT que el proveedor usará para mostrar los grupos de seguridad.
  • groupPrefix: Opcional. Es el prefijo que se antepone a las reclamaciones de grupos para evitar conflictos con los nombres existentes. Por ejemplo, con un grupo foobar y un prefijo gid-, el valor es gid-foobar. De forma predeterminada, este valor se encuentra vacío y no tiene un prefijo.
  • scopes: Opcional. Son los permisos adicionales que se deben enviar al proveedor de OpenID como una lista separada por comas.
    • Para la autenticación con Okta o Microsoft Azure, pasa offline_access.

  • extraParams: Opcional. Son los parámetros adicionales de clave-valor que se deben enviar al proveedor de OpenID como una lista separada por comas.
  • deployCloudConsoleProxy: Opcional Especifica si se debe implementar un proxy inverso en el clúster con el fin de permitir que Google Cloud Console acceda al proveedor de OIDC local para la autenticación de usuarios. El valor debe ser una string: "true" o "false". Si no se puede acceder al proveedor de identidad no a través de la Internet pública y deseas autenticarte mediante Google Cloud Console, este campo se debe configurar como "true". Si queda en blanco, el valor predeterminado de este campo es "false".

  • caPath: Opcional. Es la ruta al certificado de la autoridad certificada (CA) que emitió el certificado web del proveedor de identidad. Es posible que este valor no sea necesario. Por ejemplo, si al certificado del proveedor de identidad lo emitió una CA pública conocida, no es necesario proporcionar un valor aquí. Sin embargo, si deployCloudConsoleProxy es “true”, se debe proporcionar este valor, incluso en el caso de una CA pública conocida.

Ejemplo: Autoriza usuarios y grupos

Muchos proveedores codifican las propiedades de identificación de los usuarios, como el correo electrónico y los ID 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 la auditoría de las políticas.
  • Los correos electrónicos pueden generar 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 grupos, ya que el ID de un grupo puede ser persistente y más sencillo de auditar.

Supongamos que tu proveedor crea tokens de identidad en los que se 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, deberías propagar la especificación oidc del archivo de configuración de la siguiente manera:

issuerURL: '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 usuarios, podrías usar el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar acceso con privilegios a los usuarios autenticados. Por ejemplo, podrías 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

Crea y distribuye el archivo de configuración de autenticación

Esta sección está destinada a los administradores de clústeres.

Después de crear un clúster de usuario, 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 todos los archivos de configuración de autenticación a los usuarios que desean realizar la autenticación con 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 de gkectl:

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

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

Resultado: El 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 siguiente comando para integrar los detalles de la autenticación de los clústeres de usuario adicionales en un archivo de configuración de autenticación existente. Si tienes un archivo de configuración de autenticación existente, puedes integrar o combinar los detalles de la autenticación de los clústeres de usuario adicionales:

  • Puedes integrar los detalles de la autenticación de los clústeres de usuario adicionales en ese archivo de configuración de autenticación existente.
  • Puedes combinar los detalles de la autenticación de los clústeres de usuario 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 la organización.

Para agregar clústeres de usuario adicionales al archivo de configuración de autenticación existente, haz lo siguiente:

  1. Asegúrate de que cada clúster tenga un nombre único. Si los clústeres tienen el mismo nombre, 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 integrar o combinar los detalles de configuración:

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

    En el ejemplo anterior, se ilustra lo siguiente:

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

    • [IN_AUTH_CONFIG_FILE] especifica la ruta del archivo de configuración de autenticación existente que deseas integrar en 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 integrada:

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

Distribuye el archivo de configuración de autenticación

Para permitir que los usuarios se autentiquen en los clústeres de usuario, 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 usan el nombre de archivo y la ubicación predeterminados que espera la CLI de gcloud. Para obtener información sobre el uso de ubicaciones y nombres de archivos alternativos, consulta Configuración personalizada.

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

  • Aloja el archivo en una URL a la que se pueda acceder. 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 alojar el archivo en un host seguro. Consulta la marca --login-config-cert de la CLI de gcloud si deseas obtener más información sobre el uso de certificados de PEM para el acceso HTTPS seguro.

  • Proporciona el archivo a cada usuario de forma manual. Después de que los usuarios descarguen el archivo, debes indicarles cómo almacenarlo en la ubicación predeterminada 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 predeterminado kubectl-anthos-config.yaml 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 del 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 del 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 del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.

  • Usa las herramientas internas para enviar el archivo de configuración de autenticación a la máquina de cada usuario. Por ejemplo, puedes usar las 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 realizas la autenticación con el clúster. La marca del comando adicional pasa la ruta de acceso y el nombre de archivo personalizados. Para obtener más información sobre la marca del comando, consulta Autentica a través de la CLI de gcloud.

Instala la CLI de gcloud

Esta sección está destinada a los desarrolladores y administradores de clústeres.

Todos los desarrolladores o usuarios que necesiten realizar la autenticación con un clúster deben instalar Google Cloud CLI en su propia máquina. Los comandos de autenticación de Anthos se integraron en la CLI de gcloud como el componente anthos-auth.

Quita complementos anteriores

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

kubectl anthos version

  • Si la respuesta del comando es Error: unknown command "anthos" for "kubectl", significa que no se encontró ningún complemento, por lo que 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 con el fin de mostrar la ubicación y, luego, úsala para quitar el objeto binario de la máquina:

    kubectl plugin list

Instala la CLI de gcloud y la CLI de gcloud

Para instalar la CLI de gcloud, primero debes instalar gcloud CLI:

  1. Instala gcloud CLI, pero omite el comando gcloud init.

  2. Ejecuta los siguientes comandos para instalar el componente 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 de forma adecuada:

    gcloud anthos auth
gcloud anthos auth login

    Resultado: Cada comando debe responder con detalles sobre los argumentos obligatorios y las opciones disponibles.

Obtén el archivo de configuración de autenticación

Esta sección está destinada a los desarrolladores.

El administrador es responsable de crear el archivo de configuración de autenticación y de proporcionártelo. 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 el archivo de configuración de autenticación. Si se te 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 del 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 del 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 del 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 las solicitudes de autenticación. Consulta la siguiente sección para obtener detalles sobre el uso del comando gcloud anthos auth login.

Realiza la autenticación con clústeres de usuario

Esta sección está destinada a los desarrolladores.

Ahora que la CLI de gcloud está instalada en la máquina y que el administrador te proporcionó el archivo de configuración de autenticación, puedes usar la CLI de gcloud o la consola de Google Cloud para realizar la autenticación con los clústeres.

Autentica a través de la CLI de gcloud

Ejecuta los comandos de gcloud para realizar la autenticación con los 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 del clúster de usuario. Si se omite esta marca, se te solicitará que elijas entre los clústeres de usuario 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 hacia la ubicación en la que se almacena o se aloja el archivo de configuración de autenticación. Puedes omitir este parámetro si el archivo se encuentra en la ubicación predeterminada. Ejemplo: --login-config /path/to/custom/authentication-config.yaml

    • [CA_CERT_PEM_FILE] (opcional) especifica la ruta de acceso a un archivo de certificado de PEM de la CA. Si el archivo de configuración de autenticación se encuentra 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 del clúster de usuario. Los tokens de ID de OIDC que muestra el proveedor de OpenID se almacenan en el archivo kubeconfig.

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

    Ejemplos:

    • Realiza la autenticación en un clúster específico:

      gcloud anthos auth login --cluster my-production-cluster

    • Usa una solicitud 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 las credenciales en la pantalla de consentimiento basada en el navegador que se abre.

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

    kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

Resultado: El archivo kubeconfig ahora contiene un token de ID que los comandos de kubectl usarán para realizar la autenticación con el servidor de la API de Kubernetes en el clúster de usuario.

Usa SSH para realizar la autenticación desde una máquina remota

Supongamos que deseas establecer una conexión SSH con una máquina remota y autenticarte en un clúster de usuario desde esta máquina. 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 la máquina local.

En la 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 la máquina local y que usarás para acceder a la máquina remota.

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

En la shell con 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 acceso del archivo de configuración de autenticación en la máquina remota.

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

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

En la shell con SSH, verifica que tengas acceso al clúster de usuario:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

Realiza la autenticación a través de Google Cloud Console

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

  1. Abre la consola de Google Cloud:

    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 Authenticate with the Identity Provider configured for the cluster y, luego, haz clic en ACCEDER.

    Se te redireccionará al proveedor de identidad, en el que es posible que debas acceder u otorgar consentimiento a la consola de Google Cloud para que acceda a tu cuenta. Luego, se te redireccionará a la página Clústeres de Kubernetes en la consola de Google Cloud.

Soluciona los problemas de la configuración de OIDC

Consulta los siguientes comportamientos y errores para ayudarte a solucionar los problemas de OIDC:

La configuración no es válida
Si Google Cloud Console no puede leer la configuración de OIDC desde el clúster, se inhabilitará el botón ACCEDER.
La configuración del proveedor no es válida
Si la configuración del 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 de forma adecuada el proveedor o el clúster.
Los permisos no son válidos
Si completaste el flujo de autenticación, pero aún no puedes ver los detalles del clúster, asegúrate de haber proporcionado los permisos adecuados de RBAC a la cuenta que usaste con OIDC. Ten en cuenta que esta cuenta podría ser diferente de la que usas para acceder a la consola de Google Cloud.
Error: missing 'RefreshToken' field in 'OAuth2Token' in credentials struct
Es posible que se genere 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.

¿Qué sigue?