Autentica con OIDC y Google

Aprende a configurar OpenID Connect (OIDC) en clústeres de Anthos en equipos físicos y usa Google como proveedor de OpenID.

Para obtener una descripción general del flujo de autenticación de los clústeres de Anthos en equipos físicos, consulta Autenticación. Consulta los siguientes temas para aprender a configurar OIDC con otros proveedores de OpenID:

Descripción general

Los clústeres de Anthos en equipos físicos admiten OIDC como uno de los mecanismos de autenticación para interactuar con el servidor de la API de Kubernetes de un clúster. 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:

  • El proveedor de OpenID de Google no es compatible con los grupos. Cuando usas el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar funciones a usuarios autenticados, debes otorgarlas a cada usuario individual, no a un grupo.

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

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 el proveedor de OpenID de Google, especifica http://localhost:[PORT]/callback como una de las URL de redireccionamiento.

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 el proveedor de OpenID de Google, especifica https://console.cloud.google.com/kubernetes/oidc como una de las URL de redireccionamiento.

En esta sección, deberás configurar la pantalla de consentimiento de OAuth de Google. Cuando un desarrollador de la organización inicia la autenticación de un clúster de usuario, se lo dirige a esta pantalla de consentimiento. En ese momento, demuestran la identidad a Google y le dan permiso a este para crear un token que proporcione información de identificación al cliente de OAuth. En el contexto de este tema, el cliente de OAuth es la CLI de gcloud o la consola de Google Cloud.

  1. Ve a la página Pantalla de consentimiento de OAuth en Google Cloud Console.

    Configurar la pantalla de consentimiento de OAuth

  2. Selecciona Interna y haz clic en Crear.

  3. En Tipo de aplicación, selecciona Interna.

  4. En Nombre de la aplicación, ingresa el nombre que desees. Sugerencia: bare metal.

  5. En Dominios autorizados, agrega google.com.

  6. Completa los campos adicionales que consideres adecuados.

  7. Haz clic en Guardar.

Registra una aplicación cliente en Google

En esta sección, registras los clústeres de Anthos alojados en equipos físicos con Google, a fin de que Google pueda actuar como proveedor de OpenID para los desarrolladores de tu organización. Como parte del registro, debes proporcionar las dos URLs de redireccionamiento que creaste antes.

  1. Ve a la página Credenciales en Google Cloud Console.

    Ir a la página Credenciales

  2. Haz clic en Crear credenciales y, luego, selecciona ID de cliente de OAuth.

  3. En Tipo de aplicación, selecciona Aplicación web.

  4. En Nombre, ingresa el nombre que desees.

  5. En URI de redireccionamiento autorizados, agrega las dos URLs de redireccionamiento. Recuerda que creaste una URL de redireccionamiento para la CLI de gcloud y una URL de redireccionamiento para la consola de Google Cloud.

  6. Haga clic en Crear.

  7. Se te proporcionará un ID de cliente y un secreto del cliente. Guárdalos para usarlos luego.

Propaga la especificación oidc en el archivo de configuración de los clústeres de Anthos en equipos físicos

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

Antes de crear un clúster, debes generar un archivo de configuración de Anthos en equipos físicos con bmctl create config. En la configuración, se incluye la siguiente especificación oidc. Debes propagar oidc con los valores específicos del proveedor:

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:
  • issuerURL: Configura esto como "https://accounts.google.com". 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.
  • kubectlRedirectURL: Obligatorio. Es la URL de redireccionamiento que configuraste antes para la CLI de gcloud.
  • clientID: 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. Se te proporcionó este ID cuando registraste la aplicación cliente en Google.
  • clientSecret: El secreto de la aplicación cliente. La CLI de gcloud y la consola de Google Cloud usan este Secret. Se te proporcionó este ID cuando registraste la aplicación cliente en Google.
  • username: Configura esto como "email".
  • 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: Deja esto en blanco.
  • groupPrefix: Deja esto en blanco.
  • scopes: Configura esto como "email".
  • extraParams: Configura esto como "prompt=consent,access_type=offline".
  • proxy: Opcional A partir de los clústeres de Anthos en equipos físicos 1.6.1, puedes especificar un servidor proxy que se usará para que el clúster se conecte a tu proveedor de OIDC, si corresponde. Por ejemplo: http://user:password@10.10.10.10:8888. Si se deja en blanco, el valor predeterminado no tendrá ningún proxy.
  • deployCloudConsoleProxy: Configura esto como false.
  • certificateAuthorityData: Deja esto en blanco.

Crea una política de RBAC para el clúster de usuario

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

Después de crear un clúster, usa el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar acceso a los usuarios del clúster autenticados. Para otorgar acceso a los recursos en un espacio de nombres en particular, crea una Role y una RoleBinding. Para otorgar acceso a los recursos en la totalidad de un clúster, crea una ClusterRole y una ClusterRoleBinding.

Cuando usas Google como proveedor de OpenID, debes otorgar acceso a usuarios individuales. No sirve para otorgar acceso a grupos. Esto se debe a que el token que muestra el proveedor de OpenID de Google no tiene información sobre los grupos a los que pertenece un usuario individual.

Por ejemplo, supongamos que quieres que jane@example.com pueda ver todos los objetos Secreto del clúster.

A continuación, se muestra un manifiesto para una ClusterRole con el nombre secret-viewer. Una persona a la que se le otorga esta función puede obtener, visualizar y enumerar cualquier Secreto en el clúster.

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

A continuación, se muestra un manifiesto para una ClusterRoleBinding con el nombre people-who-view-secrets. La vinculación otorga la función secret-viewer a un usuario llamado jane@example.com.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: people-who-view-secrets
subjects:
- kind: User
  name: jane@example.com
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-viewer
  apiGroup: rbac.authorization.k8s.io

Para crear la ClusterRole, guarda el manifiesto en un archivo llamado secret-viewer-cluster-role.yaml y, luego, ingresa este comando:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

En el ejemplo anterior, [CLUSTR_KUBECONFIG] es el archivo kubeconfig para el clúster.

Para crear la ClusterRoleBinding, guarda el manifiesto en un archivo llamado secret-viewer-cluster-role-binding.yaml y, luego, ingresa este comando:

kubectl --kubeconfig [CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role-binding.yaml

Instala la CLI de gcloud

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

Los administradores de clústeres que deseen crear archivos de configuración de autenticación de clúster y cada desarrollador o usuario que necesite autenticarse 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 la CLI de gcloud:

  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.

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 gcloud:

gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG]

En el ejemplo anterior, [CLUSTER_KUBECONFIG] es la ruta al archivo kubeconfig del clúster de usuario. Cuando ejecutaste bmctl 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 fusionar detalles de autenticación de clústeres 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 autenticación de clústeres adicionales:

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

    gcloud anthos create-login-config --kubeconfig [CLUSTER_KUBECONFIG] \
--merge-from [IN_AUTH_CONFIG_FILE] --output [OUT_AUTH_CONFIG_FILE]

    donde

    • [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 usa el nombre de archivo predeterminado y la ubicación 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.

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.

Autentica con clústeres

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 [CLUSTER_KUBECONFIG]

    Donde:

    • [CLUSTER_NAME] (opcional) especifica el nombre de tu clúster. Si se omite esta marca, se te solicitará que elijas entre los clústeres 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

    • [CLUSTER_KUBECONFIG] (opcional) especifica la ruta de acceso personalizada al archivo kubeconfig del clúster. 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 [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.

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 tu shell de SSH, verifica que tengas acceso al clúster:

kubectl --kubeconfig [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. Ubica el clúster de Anthos en equipos físicos 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 Anthos en equipos físicos y vuelve a generar el archivo de autenticación de cliente con la marca --extra-params prompt=consent.

¿Qué sigue?