Autentica con OIDC y AD FS

Aprende a configurar OpenID Connect (OIDC) con los Servicios de federación de Active Directory (AD FS) en clústeres de Anthos en equipos físicos.

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

Para obtener una descripción general del flujo de autenticación de Anthos en equipos físicos, consulta Autenticación. Consulta los siguientes temas para aprender cómo 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:

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

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

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

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

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

  • Los sistemas sin interfaz gráfica no son compatibles. Se usa un flujo de autenticación basado en el navegador para solicitar tu consentimiento y autorizar 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 de tu puerto.

Cuando configuras el servidor de AD FS, debes especificar 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 configuras el servidor de AD FS, debes especificar https://console.cloud.google.com/kubernetes/oidc como una de las URL de redireccionamiento.

Configura AD FS

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

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

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

  2. Selecciona 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. Con él, el servidor de AD FS identifica la CLI de gcloud y la la consola de Google Cloud. Guarda el ID de cliente para usarlo más adelante.

  5. Selecciona Generate a shared secret. La CLI de gcloud y la consola de Google Cloud usan este Secret para autenticarse en el servidor de AD FS. Guarda el secreto para usarlo 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 usuarios comparten la información de su grupo de seguridad con la CLI de gcloud 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 la CLI de gcloud 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 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 de tu proveedor:

authentication:
  oidc:
    issuerURL:
    kubectlRedirectURL:
    clientID:
    clientSecret:
    username:
    usernamePrefix:
    group:
    groupPrefix:
    scopes:
    extraParams:
    proxy:
    deployCloudConsoleProxy:
    certificateAuthorityData:
  • 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. Debe usar HTTPS.
  • kubectlRedirectURL: Obligatorio. Es la URL de redireccionamiento que configuraste antes para la CLI de gcloud.
  • clientID: Obligatorio. Es el ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID. La CLI de gcloud y 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 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.

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

  • certificateAuthorityData: Opcional Un certificado de autoridad certificadora codificado en base64 de tu 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==. 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, entonces se debe proporcionar este valor, incluso para 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

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 de tu 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?