Autentica con OIDC y AD FS

En esta página, se muestra cómo usar OpenID Connect (OIDC) con Servicios de federación de Active Directory (AD FS) a fin de configurar la autenticación para los clústeres de usuario de GKE On-Prem. Ten en cuenta que AD FS solo es compatible con OIDC en las versiones 2016 y posteriores.

Para obtener una descripción general del flujo de autenticación, consulta Autenticación. Para obtener información sobre el uso de proveedores de OpenID que no sean AD FS, consulta Autentica con OpenID Connect.

Descripción general

GKE On-Prem admite OpenID Connect (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 tu organización para la creación, inhabilitación y habilitación de cuentas de empleado.

Hay dos formas en que un empleado puede usar el flujo de autenticación OIDC:

  • Un empleado puede usar kubectl para iniciar un flujo de OIDC. A fin de que este flujo sea automático, GKE On-Prem proporciona el complemento de Anthos para Kubectl, un complemento de kubectl.
  • Un empleado puede usar Google Cloud Console para iniciar un flujo de autenticación de OIDC.

En este ejercicio, configurarás ambas opciones: kubectl y la consola de Google Cloud. Usa un conjunto de asistentes de administración de AD FS para configurar tu servidor de AD FS y tu base de datos de empleados de AD.

Antes de comenzar

En este tema suponemos que estás familiarizado con OAuth 2.0 y OpenID Connect. En este tema suponemos que estás familiarizado con los alcances de OpenID y las reclamaciones.

Este tema se aplica a las empresas que tienen la siguiente infraestructura:

  • La empresa usa Active Directory (AD) para su base de datos de empleados.
  • La empresa ejecuta un servidor de Active Directory Federation Services (AD FS).
  • El servidor AD FS actúa como un proveedor de OpenID.

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 una URL de redireccionamiento para el complemento de Anthos para Kubectl

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

Como parte de la relación de tu servidor de AD FS, debes especificar una URL de redireccionamiento que el servidor AD FS puede usar a fin de mostrar los tokens de ID al complemento de Anthos para Kubectl. El complemento de Anthos para Kubectl se ejecuta en la máquina local de cada desarrollador y escucha en el puerto que elijas. Elige un número de puerto mayor que 1,024 que sea adecuado para este propósito. A continuación, se muestra la URL de redireccionamiento:

http://localhost:[PORT]/callback

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

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

Configura una URL de redireccionamiento para la consola de Google Cloud

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

Además de tener una URL de redireccionamiento del complemento de Anthos para Kubectl, necesitas una URL de redireccionamiento para 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 servidor de AD FS, especifica https://console.cloud.google.com/kubernetes/oidc como una de tus URL de redireccionamiento.

Configura AD FS

En las siguientes secciones, se explica cómo configurar AD FS para GKE On-Prem.

Configura las URL de redireccionamiento

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

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

  2. Selecciona Application Groups > Acciones > Add an Application Group.

  3. Selecciona Server Application. Ingresa el nombre y la descripción que prefieras. Luego, haz clic en Siguiente.

  4. Ingresa las dos URL de redireccionamiento. Se te proporcionará un ID de cliente. Así es como el servidor de AD FS identifica el complemento de Anthos para Kubectl y la consola de Google Cloud. Guarda el ID de cliente para usarlo más adelante.

  5. Selecciona Generate a shared secret. El complemento de Anthos para Kubectl y la consola de Google Cloud usan este secreto a fin de realizar la autenticación con el servidor de AD FS. Guarda el secreto para más adelante.

Configura grupos de seguridad (opcional)

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

  1. En la administración de AD FS, selecciona Relying party trusts > Add a new relying party trust.

  2. Selecciona Claims aware y haz clic en Iniciar.

  3. Selecciona Enter data about relying party manually.

  4. Ingresa un nombre visible.

  5. Omite los siguientes dos pasos.

  6. Ingresa el identificador de una relación de confianza con la parte autenticada. Sugerencia: token-groups-claim.

  7. En Access control policy, selecciona Permit everyone. Esto significa que todos los empleados comparten su información de grupo de seguridad con el complemento de Anthos para Kubectl y la consola de Google Cloud.

  8. Haz clic en Finalizar.

Mapea atributos de LDAP a nombres de reclamaciones

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

  1. En la administración de AD FS, selecciona Relying party trusts > Edit claim issuance policy.

  2. Selecciona Send LDAP Attributes as Claims y haz clic en Siguiente.

  3. En Claim rule name, ingresa groups.

  4. En Attribute store, selecciona Active Directory.

  5. En la tabla, en LDAP Attribute, selecciona lo siguiente:

    • Para la versión 5.0 y posteriores de AD FS: Token-Groups Qualified by Domain name
    • Para versiones de AD FS anteriores a 5.0: Token Groups - Qualified Names

  6. En Outgoing Claim Type, selecciona lo siguiente:

    • Para la versión 5.0 y posteriores de AD FS: Group
    • Para versiones de AD FS anteriores a 5.0: groups

  7. Haz clic en Finalizar y, luego, en Aplicar.

Registra el complemento de Anthos para Kubectl y la consola de Google Cloud con AD FS

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

Abre una ventana de PowerShell en modo de administrador e 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 la reclamación que ingresaste antes. Recuerda que el identificador sugerido era token-groups-claim.

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. La configuración incluye la siguiente especificación oidc. Debes propagar oidc con valores específicos de tu proveedor:

oidc:
  issuerurl:
  kubectlredirecturl:
  clientid:
  clientsecret:
  username:
  usernameprefix:
  group:
  groupprefix:
  scopes:
  extraparams:
  usehttpproxy:
  capath:
  • issuerurl: obligatorio. Es la URL del proveedor de OpenID, como https://example.com/adfs. Las aplicaciones cliente, como el complemento de Anthos para Kubectl 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 descubrir claves públicas para la verificación de tokens. Debe usar HTTPS.
  • kubectlredirecturl: (Obligatorio). Es la URL de redireccionamiento configurada antes para el complemento de Anthos para Kubectl.
  • clientid: obligatorio. Es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID. Tanto el complemento de Anthos para Kubectl como la consola de Google Cloud usan este ID.
  • clientsecret: Opcional Es el secreto de la aplicación cliente. Tanto el complemento de Anthos para Kubectl como la consola de Google Cloud usan este secreto.
  • 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 en 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.
  • usehttpproxy: 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 a través de la Internet pública y deseas autenticarte mediante Google Cloud Console, este campo se debe configurar como "true".

  • 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 usehttpproxy 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:

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 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 tu primer 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, crea un archivo de configuración de autenticación para tu clúster:

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

En el comando anterior, [USER_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig del clúster de usuario. Cuando creaste tu clúster de usuario, gkectl create cluster generó un archivo kubeconfig para el clúster.

El comando anterior crea un archivo llamado kubectl-anthos-config.yaml en el directorio actual.

Agrega clústeres adicionales a tu archivo de configuración de autenticación

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

Puedes almacenar la configuración de autenticación para varios clústeres en un solo archivo. Luego, puedes distribuir ese archivo a los desarrolladores que deben tener acceso a todos esos clústeres.

Comienza con un archivo de configuración de autenticación existente. Luego, usa el siguiente comando para combinar ese archivo con la configuración de un clúster adicional:

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

donde

  • [USER_CLUSTER_KUBECONFIG]es el archivo kubeconfig del clúster adicional.

  • [IN_AUTH_CONFIG_FILE] es la ruta del archivo de configuración de autenticación existente.

  • [OUT_AUTH_CONFIG_FILE] es la ruta de acceso en la que deseas guardar el archivo que contiene la configuración combinada. Puede ser igual que [IN_AUTH_CONFIG_FILE].

Distribuye el archivo de configuración de autenticación

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

El archivo de configuración de autenticación que distribuyes a tus desarrolladores debe llamarse kubectl-anthos-config.yaml. Puedes distribuir el archivo de configuración de autenticación de varias maneras:

  • Proporciona el archivo de forma manual a cada desarrollador.

  • Aloja el archivo en una URL para que los desarrolladores puedan descargarlo.

  • Envía el archivo a la máquina de cada desarrollador.

Sin importar el método de distribución, el archivo de configuración de autenticación se debe colocar en esta ubicación en la máquina de cada desarrollador:

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

Ubica el archivo de configuración de autenticación

Esta sección está destinada a los desarrolladores.

El archivo de configuración de autenticación contiene los detalles de todos los clústeres a los que puedes autenticarte. No modifiques el contenido de este archivo.

Si el administrador de clústeres te proporcionó un archivo de configuración de autenticación, ubica el archivo en el directorio correcto. Si el administrador del clúster ya instaló la configuración en tu máquina, puedes omitir esta sección.

Copia el archivo de configuración de autenticación en su ubicación predeterminada:

Linux

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

en el que [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación.

macOS

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

en el que [AUTH_CONFIG_FILE] es el nombre de tu archivo de configuración de autenticación.

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.

Obtén el complemento de Anthos para Kubectl

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

El complemento de Anthos para Kubectl se incluye en tu estación de trabajo de administrador en:

Linux

/usr/bin/kubectl_anthos/v1.0beta/linux_amd64/kubectl-anthos

macOS

/usr/bin/kubectl_anthos/v1.0beta/darwin_amd64/kubectl-anthos

Windows

/usr/bin/kubectl_anthos/v1.0beta/windows_amd64/kubectl-anthos

Puedes distribuir el complemento a tus desarrolladores o hacer que descarguen el complemento directamente.

Descarga el complemento de Anthos para Kubectl

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

Cada desarrollador debe tener el complemento de Anthos para Kubectl en su propia máquina. Los desarrolladores pueden descargar el complemento de forma individual o el administrador de clústeres puede descargarlo y, luego, distribuirlo a los desarrolladores.

Nota para los desarrolladores: Pregúntale a tu administrador de clústeres qué versión del complemento debes usar.

Descarga el complemento de Anthos para Kubectl:

Linux

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/linux_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

macOS

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/darwin_amd64/kubectl-anthos ./
chmod +x kubectl-anthos

Windows

gsutil cp gs://gke-on-prem-release/kubectl-anthos/v1.0beta/windows_amd64/kubectl-anthos ./
rename kubectl-anthos kubectl-anthos.exe.

Instala el complemento de Anthos para Kubectl

Esta sección está destinada a los desarrolladores.

El administrador de tu clúster puede proporcionarte el complemento de Anthos para Kubectl. También, es posible que el administrador de tu clúster te solicite descargar el complemento tú mismo.

Si deseas instalar el complemento de Anthos para Kubectl, mueve el archivo ejecutable a cualquier ubicación en tu RUTA. El archivo ejecutable debe llamarse kubectl-anthos. Para obtener más información, consulta Instala complementos de kubectl.

Verifica que esté instalado el complemento de Anthos para Kubectl:

kubectl plugin list
kubectl anthos version

Enumera los clústeres disponibles

Esta sección está destinada a los desarrolladores.

Si tu archivo de configuración de autenticación está en la ruta de acceso predeterminada, ingresa este comando para enumerar los clústeres en los que puedes autenticarte:

kubectl anthos listclusters

Si tu archivo de configuración de autenticación no está en la ruta predeterminada, ingresa este comando para enumerar los clústeres:

kubectl anthos listclusters --loginconfig [AUTH_CONFIG_FILE]

en el que [AUTH_CONFIG_FILE] es la ruta de acceso a tu archivo de configuración de autenticación.

Usa el complemento de Anthos para Kubectl a fin de autenticar

Esta sección está destinada a los desarrolladores.

Accede a un clúster de usuario:

kubectl anthos login --cluster [CLUSTER_NAME] --user [USER_NAME] \
    --loginconfig [AUTH_CONFIG_FILE] --kubeconfig [USER_CLUSTER_KUBECONFIG]

Donde:

  • [CLUSTER_NAME] es el nombre del clúster de usuario. Este nombre se debe seleccionarse de la lista que proporciona el comando kubectl anthos listclusters.

  • [USER_NAME] es un parámetro opcional que especifica el nombre de usuario para las credenciales almacenadas en el archivo kubeconfig. El valor predeterminado es [CLUSTER_NAME]-anthos-default-user.

  • [AUTH_CONFIG_FILE] es la ruta de tu archivo de configuración de autenticación. Si tu archivo de configuración de autenticación está en la ubicación predeterminda, puedes omitir este parámetro.

  • [USER_CLUSTER_KUBECONFIG] es la ruta de acceso del archivo kubeconfig de tu clúster de usuario. Si no existe un archivo kubeconfig, el comando genera un nuevo archivo kubeconfig a partir del archivo de configuración de autenticación y agrega los detalles del clúster y el archivo kubeconfig.

kubectl anthos login inicia un navegador en el que puedes ingresar tus credenciales.

El archivo kubeconfig proporcionado ahora contiene un token de ID que kubectl puede usar para autenticarse en el servidor de la API de Kubernetes en el clúster de usuarios.

El comando kubectl anthos login tiene una marca opcional --dry-run. Si incluyes la marca --dry-run, el comando imprime los comandos kubectl que agregarían tokens al archivo kubeconfig, pero en realidad no guarda los tokens en el archivo kubeconfig.

Ingresa un comando kubectl para verificar que la autenticación se realizó de forma correcta. Por ejemplo:

kubectl get nodes --kubeconfig [USER_CLUSTER_KUBECONFIG]

Usa OIDC con Google Cloud Console

Esta sección está destinada a los desarrolladores.

  1. Verifica que tu clúster esté configurado para OIDC.

  2. Verifica que tu clúster se haya registrado con Google Cloud, ya sea de forma automática durante la creación del clúster o de forma manual.

  3. Visita la página Clústeres de Kubernetes en la consola de Google Cloud.

    Visitar la página Clústeres de Kubernetes

  4. En la lista de clústeres, ubica tu clúster de GKE local y haz clic en Acceder.

  5. Selecciona Autenticar con el proveedor de identidad configurado para el clúster y 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.

Resumen

Tu empresa ejecuta un servidor AD FS que actúa como tu proveedor de OpenID. El proveedor de OpenID conoce tus dos aplicaciones cliente: el complemento de Anthos para Kubectl y la consola de Google Cloud. Tu proveedor de OpenID sabe que tus aplicaciones cliente pueden solicitar los alcances openid y allatclaims.

En la versión AD FS anterior a la 5.0, el atributo LDAP Token-Groups Qualified Names en tu base de datos de AD se mapea a la reclamación groups en tu proveedor de OpenID. En la versión 5.0 y posterior, el atributo es Token-Groups Qualified by Domain name. El proveedor muestra los tokens que incluyen el ID del empleado, 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 un empleado.

Configuración personalizada

De forma predeterminada, el complemento de Anthos para Kubectl espera que el archivo de configuración de autenticación esté en una ubicación determinada. Si no deseas colocar el archivo de configuración de autenticación en la ubicación predeterminada, puedes pasar de forma manual la ruta del archivo de configuración de autenticación a los comandos del complemento mediante la marca --login-config. Por ejemplo, consulta Usa el complemento de Anthos para Kubectl a fin de autenticar.

Soluciona problemas de OIDC en GKE On-Prem

La configuración no es válida

Si la consola de Google Cloud 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 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 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?