Versión 1.7. Esta versión es compatible como se describe en la política de asistencia de la versión de Anthos, que ofrece los últimos parches y actualizaciones de vulnerabilidades de seguridad, exposiciones y problemas que afectan a los clústeres de Anthos alojados en VMware (GKE On-Prem). Consulta las notas de la versión para obtener más detalles. Esta no es la versión más reciente.

Autentica con OIDC y Google

Obtén más información para configurar clústeres de Anthos alojados en VMware (GKE On-Prem) a fin de usar OpenID Connect (OIDC) con Google como el proveedor de OpenID para la autenticación de clústeres de usuario. En esta página, se describe el proceso en general para ayudarte a comprender cómo configurar Google como el proveedor de OpenID.

Para obtener una descripción general del flujo de autenticación de los clústeres de Anthos alojados en VMware, consulta Autenticación. Para aprender a configurar OIDC con otros proveedores de OpenID, consulta los siguientes recursos:

Los clústeres de Anthos alojados en VMware admiten OIDC como uno de los mecanismos de autenticación para interactuar 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 la herramienta de línea de comandos 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 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 del clúster: 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 URL de redireccionamiento para la herramienta de gcloud y Cloud Console que el proveedor de OpenID podrá usar para mostrar tokens de ID.

URL de redireccionamiento de la herramienta de gcloud

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

http://localhost:PORT/callback

Reemplaza PORT por el número de 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 Cloud Console

Esta es la URL de redireccionamiento para Cloud Console:

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 herramienta de gcloud o Cloud Console.

  1. Ve a la página de 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: GKE on-prem.

  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 VMware 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 URL 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 URL de redireccionamiento. Recuerda que creaste una URL de redireccionamiento para la herramienta de gcloud y una URL de redireccionamiento para Cloud Console.

  6. Haga clic en Crear.

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

Configura oidc en clústeres de los clústeres de Anthos alojados en VMware

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

Para configurar la autenticación de OIDC, necesitas configurar la CRD de ClientConfig del clúster de usuario con detalles de autenticación para un clúster. Para ello, edita el objeto predeterminado de KRM del tipo clientconfig en el espacio de nombres kube-public.

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

Los detalles de la CRD de ClientConfig se usan a fin de configurar OIDC para Cloud Console y el complemento de autenticación para Anthos. La configuración incluye la siguiente información de OIDC:

authentication:
  - name: NAME_STRING
    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 describe cómo completar los campos del objeto oidc de CRD de ClientConfig. Para obtener información general sobre el objeto oidc de ClientConfig, consulta Configura OIDC en clústeres de Anthos alojados en VMware.

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==

Este valor es opcional en las versiones 1.4 y 1.5 y este valor es opcional en la versión 1.6.1 y versiones posteriores. Sin embargo, este valor es obligatorio en la versión 1.6.0. Esto es de especial importancia para las actualizaciones de la versión 1.5 a la 1.6.0. Para obtener más información, consulta Problemas conocidos en las notas de la versión 1.6.0.

String
clientID 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. Se te proporcionó este ID cuando registraste la aplicación cliente en Google. String
clientSecret No Es el secreto de la aplicación cliente. La CLI de gcloud y Cloud Console usan este secreto. Se te proporcionó este ID cuando registraste la aplicación cliente en Google. String
extraParams No Configura esto como "prompt=consent,access_type=offline"..

Lista delimitada por comas
groupsClaim No Déjelo en blanco. String
groupPrefix No Déjelo en blanco. String
issuerURI Configura esto como "https://accounts.google.com". 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 buscar claves públicas para la verificación de tokens. String de URL
kubectlRedirectURI Es la URL de redireccionamiento que configuraste antes para la CLI de gcloud. String de URL
scopes Los permisos adicionales que se deben enviar al proveedor de OpenID. Configura esto como “correo electrónico”. Lista delimitada por comas
userClaim No Configura esto como “correo electrónico”. String
userPrefix No 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. 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

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 un Role y una RoleBinding. Para otorgar acceso a los recursos en un clúster completo, crea un 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 [USER_CLUSTER_KUBECONFIG] apply -f secret-viewer-cluster-role.yaml

En el ejemplo anterior, [USER_CLUSTR_KUBECONFIG] es el archivo kubeconfig del clúster de usuario.

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

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

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

Reemplaza USER_CLUSTER_KUBECONFIG con la ruta de acceso del archivo kubeconfig de tu 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

    Reemplaza 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 usa el nombre de archivo predeterminado y la ubicación que espera la herramienta 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 herramienta 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 herramienta de gcloud a fin de obtener más información sobre cómo usar certificados de PEM para 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 herramienta 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 herramienta 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 mediante la herramienta de gcloud.

Instala la herramienta 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 el SDK de Cloud en su propia máquina. Los comandos de autenticación de Anthos se integraron en la herramienta de gcloud como el componente anthos-auth.

Quita complementos anteriores

Debes desinstalar el complemento anterior antes de poder usar el componente anthos-auth del SDK de Cloud. 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 el SDK de Cloud y la herramienta de gcloud

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

  1. Instala el SDK de Cloud, 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. Verifica que la herramienta de gcloud se haya instalado de forma correcta mediante la ejecución de cualquiera de los siguientes comandos:

    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 herramienta 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 el SDK de Cloud está instalado en tu máquina y que tu administrador te proporcionó el archivo de configuración de autenticación, puedes usar la herramienta de gcloud o Cloud Console para realizar la autenticación con los clústeres.

Realiza la autenticación mediante la herramienta 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

    En el ejemplo anterior, se ilustra lo siguiente:

    • 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

En el ejemplo anterior, se ilustra lo siguiente:

  • 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 Cloud Console:

  1. Abre Cloud Console:

    Visitar la página Clústeres de Kubernetes

  2. Ubica el clúster de clústeres de Anthos alojados en VMware en la lista y, luego, haz clic en Acceder.

  3. Selecciona Authenticate with the Identity Provider configured for the cluster y, luego, haz clic en ACCEDER.

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

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 Cloud Console no puede leer la configuración de OIDC del clúster, el botón ACCEDER estará inhabilitado.
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 Cloud Console.
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 los clústeres de Anthos alojados en VMware y vuelve a generar el archivo de autenticación del cliente con la marca --extra-params prompt=consent.

¿Qué sigue?