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.

Versiones disponibles

Autentica con OIDC y AD FS

Obtén más información sobre cómo configurar los clústeres de Anthos alojados en VMware (GKE On-Prem) para usar OpenID Connect (OIDC) con Servicios de federación de Active Directory (AD FS) para la autenticación en clústeres de usuario. En esta página, se abarca el proceso en general para ayudarte a comprender cómo configurar un servidor de AD FS como proveedor de OpenID con Active Directory como la base de datos del usuario.

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

Reemplaza PORT por el número de 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 Active Directory:

Abre el panel de administración de AD FS.
Selecciona Application Groups > Acciones > Add an Application Group.
Selecciona Server Application. Ingresa el nombre y la descripción que prefieras. Luego, haz clic en Siguiente.
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.
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.

En la administración de AD FS, selecciona Relying party trusts > Add a new relying party trust.
Selecciona Claims aware y haz clic en Iniciar.
Selecciona Enter data about relying party manually.
Ingresa un nombre visible.
Omite los siguientes dos pasos.
Ingresa el identificador de una relación de confianza con la parte autenticada. Sugerencia: token-groups-claim.
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.
Haz clic en Finalizar.

Mapea atributos de LDAP a nombres de reclamaciones

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

En la administración de AD FS, selecciona Relying party trusts > Edit claim issuance policy.
Selecciona Send LDAP Attributes as Claims y haz clic en Siguiente.
En Claim rule name, ingresa groups.
En Attribute store, selecciona Active Directory.
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
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
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-AdfsApplicationPermission `
     -ClientRoleIdentifier "CLIENT_ID" `
     -ServerRoleIdentifier SERVER_ROLE_IDENTIFIER `
     -ScopeName "allatclaims", "openid"

Reemplaza lo siguiente:

CLIENT_ID es el ID de cliente que obtuviste antes.
SERVER_ROLE_IDENTIFIER: El identificador de reclamación que ingresaste anteriormente. El identificador sugerido era token-groups-claim

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 la consola de Google Cloud 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: "https://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 describen los campos del objeto oidc de la CRD de ClientConfig.

Campo	Obligatorio	Descripción	Formato
nombre	sí	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==`	String
clientID	Sí	El ID de la aplicación cliente que realiza solicitudes de autenticación al proveedor de OpenID.	String
clientSecret	No	Secreto compartido entre la aplicación cliente de OIDC y el proveedor de OIDC	String
extraParams	No	Los parámetros de clave-valor adicionales para enviar al proveedor de OpenID. Si autorizas un grupo, pasa `resource=token-groups-claim`. Si el servidor de autorización solicita consentimiento para la autenticación con Microsoft Azure y Okta, establece `extraParams` en `prompt=consent`. En Cloud Identity, establece `extraParams` en `prompt=consent,access_type=offline`.	Lista delimitada por comas
groupsClaim	No	La reclamación de JWT que el proveedor usa para mostrar los grupos de seguridad.	String
groupPrefix	No	El prefijo que se antepone a las reclamaciones de grupos para evitar conflictos con los nombres existentes. Por ejemplo, si tienes dos grupos llamados `foobar`, agrega un prefijo `gid-`. El grupo resultante es `gid-foobar`.	String
issuerURI	Sí	La URL a la que se envían las solicitudes de autorización al OpenID, como `https://example.com/adfs`. El servidor de la API de Kubernetes usa esta URL a fin de descubrir claves públicas para la verificación de tokens. El URI debe usar HTTPS.	String de URL
cloudConsoleRedirectURI	Sí	La URL de redireccionamiento que usa `Google Cloud console` para la autorización. El valor debe ser `https://console.cloud.google.com/kubernetes/oidc`.	String de URL
kubectlRedirectURI	Sí	La URL de redireccionamiento que usa `kubectl` para la autorización.	String de URL
scopes	Sí	Los permisos adicionales que se deben enviar al proveedor de OpenID. Microsoft Azure y Okta requieren el permiso `offline_access`.	Lista delimitada por comas
userClaim	Sí	Es la reclamación de JWT que se debe usar como nombre de usuario. Puedes elegir otras reclamaciones, como el correo electrónico o el nombre, según el proveedor de OpenID. Sin embargo, las reclamaciones que no sean de correo electrónico tienen el prefijo de la URL de la entidad emisora para evitar conflictos de nombres.	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 `userClaim` 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

Ejemplo: Autoriza usuarios y grupos

Muchos proveedores codifican las propiedades de identificación de los usuarios, como el correo electrónico y los ID de usuario, en un token. Sin embargo, estas propiedades tienen riesgos implícitos para las políticas de autenticación:

Los ID de usuario pueden dificultar la lectura y la auditoría de las políticas.
Los correos electrónicos pueden generar un riesgo de disponibilidad (si un usuario cambia su correo electrónico principal) y un posible riesgo de seguridad (si se puede reasignar un correo electrónico).

Por lo tanto, se recomienda usar políticas de grupos, ya que el ID de un grupo puede ser persistente y más sencillo de auditar.

Supongamos que tu proveedor crea tokens de identidad en los que se incluyen los siguientes campos:

{
  'iss': 'https://server.example.com'
  'sub': 'u98523-4509823'
  'groupList': ['developers@example.corp', 'us-east1-cluster-admins@example.corp']
  ...
}

En este formato de token, deberías propagar la especificación oidc del archivo de configuración de la siguiente manera:

issuerURL: 'https://server.example.com'
username: 'sub'
usernamePrefix: 'uid-'
group: 'groupList'
groupPrefix: 'gid-'
extraParams: 'resource=token-groups-claim'
...

Después de crear el clúster de usuarios, podrías usar el control de acceso basado en funciones (RBAC) de Kubernetes para otorgar acceso con privilegios a los usuarios autenticados. Por ejemplo, podrías crear un ClusterRole que otorgue a sus usuarios acceso de solo lectura a los secretos del clúster y crear un recurso ClusterRoleBinding para vincular la función al grupo autenticado:

ClusterRole

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

ClusterRoleBinding

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-admins
subjects:
  # Allows anyone in the "us-east1-cluster-admins" group to
  # read Secrets in any namespace within this cluster.
- kind: Group
  name: gid-us-east1-cluster-admins # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
  # Allows this specific user to read Secrets in any
  # namespace within this cluster
- kind: User
  name: uid-u98523-4509823
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Ten en cuenta que el servidor de la API de Kubernetes trata una barra inversa como un carácter de escape. Por lo tanto, si el nombre del usuario o grupo contiene una barra inversa doble (\\), el servidor de la API la leerá como una sola \ cuando se analice el valor del campo. Para garantizar que el servidor de la API interprete de forma correcta un \\ en un campo de texto, debes reemplazarlo con \\\\. Por ejemplo, el servidor de la API de Kubernetes analizará

"unique_name": "EXAMPLE\\\\cluster-developer" como

"unique_name": "EXAMPLE\\cluster-developer"

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:

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.
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 usan el nombre de archivo y la ubicación predeterminados que espera la CLI de gcloud. Para obtener información sobre el uso de ubicaciones y nombres de archivos alternativos, consulta Configuración personalizada.

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

Aloja el archivo en una URL a la que se pueda acceder. Si incluyes la marca --login-config en el comando gcloud anthos auth login, la CLI de gcloud obtendrá el archivo de configuración de autenticación de esa ubicación.

Considera alojar el archivo en un host seguro. Consulta la marca --login-config-cert de la CLI de gcloud si deseas obtener más información sobre el uso de certificados de PEM para el acceso HTTPS seguro.
Proporciona el archivo a cada usuario de forma manual. Después de que los usuarios descarguen el archivo, debes indicarles cómo almacenarlo en la ubicación predeterminada con el nombre de archivo predeterminado que espera la CLI de gcloud.

Por ejemplo, los usuarios pueden ejecutar los siguientes comandos para almacenar el archivo de configuración de autenticación con el nombre de archivo predeterminado kubectl-anthos-config.yaml en la ubicación predeterminada:
Linux
```
mkdir -p  $HOME/.config/google/anthos/
cp AUTH_CONFIG_FILE $HOME/.config/google/anthos/kubectl-anthos-config.yaml
```
En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.
macOS
```
mkdir -p  $HOME/Library/Preferences/google/anthos/
cp AUTH_CONFIG_FILE $HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
```
En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.
Windows
```
md "%APPDATA%\google\anthos"
copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"
```
En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.
Usa las herramientas internas para enviar el archivo de configuración de autenticación a la máquina de cada usuario. Por ejemplo, puedes usar las herramientas para enviar archivos mediante el nombre de archivo predeterminado kubectl-anthos-config.yaml a sus ubicaciones predeterminadas en la máquina de cada usuario:
Linux
```
$HOME/.config/google/anthos/kubectl-anthos-config.yaml
```
macOS
```
$HOME/Library/Preferences/google/anthos/kubectl-anthos-config.yaml
```
Windows
```
%APPDATA%\google\anthos\kubectl-anthos-config.yaml
```

Configuración personalizada

La CLI de gcloud espera que el archivo de configuración de autenticación se almacene en la ubicación predeterminada con el nombre de archivo predeterminado kubectl-anthos-config.yaml, como se mencionó en la sección anterior. Sin embargo, tienes la opción de cambiar el nombre del archivo de configuración de autenticación o almacenarlo en una ubicación alternativa. Si el nombre y la ubicación del archivo son diferentes de los predeterminados, debes agregar la marca --login-config en cada comando que ejecutes cuando realizas la autenticación con el clúster. La marca del comando adicional pasa la ruta de acceso y el nombre de archivo personalizados. Para obtener más información sobre la marca del comando, consulta Autentica a través de la CLI de gcloud.

Instala la CLI de gcloud

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

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

Si tienes una versión anterior del “complemento de Anthos para Kubectl”, debes desinstalarlo antes de instalar la CLI de gcloud y el componente anthos-auth.
Si tienes una versión existente de la CLI de gcloud, instala la versión más reciente y 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:

Instala gcloud CLI, pero omite el comando gcloud init.
Ejecuta los siguientes comandos para instalar el componente anthos-auth:
```
gcloud components update
gcloud components install anthos-auth
```
Ejecuta cualquiera de los siguientes comandos para verificar que la CLI de gcloud se haya instalado de forma adecuada:
```
gcloud anthos auth
gcloud anthos auth login
```
Resultado: Cada comando debe responder con detalles sobre los argumentos obligatorios y las opciones disponibles.

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

Esta sección está destinada a los desarrolladores.

El administrador es responsable de crear el archivo de configuración de autenticación y de proporcionártelo. Para obtener más detalles, consulta Distribuye el archivo de configuración de autenticación.

De forma predeterminada, la CLI de gcloud usa un nombre de archivo y una ubicación de almacenamiento predeterminados para el archivo de configuración de autenticación. Si se te proporcionó el archivo de forma manual y necesitas guardarlo en tu máquina, usa los valores predeterminados para simplificar los comandos de autenticación de gcloud.

Usa los siguientes comandos para copiar el archivo de configuración de autenticación en la ubicación predeterminada:

Linux

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

En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.

macOS

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

En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.

Windows

md "%APPDATA%\google\anthos"
copy AUTH_CONFIG_FILE "%APPDATA%\google\anthos\kubectl-anthos-config.yaml"

En el ejemplo anterior, AUTH_CONFIG_FILE es el nombre del archivo de configuración de autenticación. Por ejemplo, kubectl-anthos-config.yaml.

Si eliges usar un nombre de archivo o una ubicación diferentes, tienes la opción de incluir la marca --login-config en cada una de las solicitudes de autenticación. Consulta la siguiente sección para obtener detalles sobre el uso del comando gcloud anthos auth login.

Realiza la autenticación con clústeres de usuario

Esta sección está destinada a los desarrolladores.

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

Autentica a través de la CLI de gcloud

Ejecuta los comandos de gcloud para realizar la autenticación con los clústeres:

Ejecuta el comando gcloud anthos auth login para iniciar el flujo de autenticación:
```
gcloud anthos auth login \
 --cluster CLUSTER_NAME \
 --user USER_NAME \
 --login-config AUTH_CONFIG_FILE_PATH \
 --login-config-cert CA_CERT_PEM_FILE \
 --kubeconfig USER_CLUSTER_KUBECONFIG
```
Donde:
- CLUSTER_NAME (opcional) especifica el nombre del clúster de usuario. Si se omite esta marca, se te solicitará que elijas entre los clústeres de usuario que se especifican en el archivo de configuración de autenticación
- USER_NAME (opcional) especifica el nombre de usuario de las credenciales almacenadas en el archivo kubeconfig. El valor predeterminado es CLUSTER_NAME-anthos-default-user
- AUTH_CONFIG_FILE_PATH (opcional) especifica la ruta de acceso o la URL personalizada hacia la ubicación en la que se almacena o se aloja el archivo de configuración de autenticación. Puedes omitir este parámetro si el archivo se encuentra en la ubicación predeterminada. Ejemplo: --login-config /path/to/custom/authentication-config.yaml
- CA_CERT_PEM_FILE (opcional) especifica la ruta de acceso a un archivo de certificado de PEM de la CA. Si el archivo de configuración de autenticación se encuentra alojado de forma segura, puedes usar una conexión HTTPS para acceder a este. Ejemplo: --login-config-cert my-cert.pem
- USER_CLUSTER_KUBECONFIG (opcional) especifica la ruta de acceso personalizada al archivo kubeconfig del clúster de usuario. Los tokens de ID de OIDC que muestra el proveedor de OpenID se almacenan en el archivo kubeconfig.
  
  Usa esta marca si el archivo kubeconfig se encuentra en una ubicación que no sea la predeterminada. Si se omite esta marca, se crea un archivo kubeconfig nuevo en la ubicación predeterminada. Ejemplo: --kubeconfig /path/to/custom.kubeconfig
Ejemplos:
- Realiza la autenticación en un clúster específico:
```
gcloud anthos auth login --cluster my-production-cluster
```
- Usa una solicitud para seleccionar con qué clúster realizar la autenticación:
```
gcloud anthos auth login
```
  Resultado:
```
Please use the --cluster flag to specify a cluster from the list below:
Source: $HOME/.config/google/anthos/kubectl-anthos-config.yaml
1. Cluster: test-cluster ServerIP: https://192.168.0.1:6443
2. Cluster: test-cluster-2 ServerIP: https://192.168.0.2:6443
3. Cluster: my-production-cluster ServerIP: https://192.168.0.3:6443
```
- Usa un archivo de configuración de autenticación alojado:
```
gcloud anthos auth login \
 --cluster my-production-cluster \
 --login-config HTTPS://my-secure-server/kubectl-anthos-config.yaml \
 --login-config-cert my-cert.pem
```
Ingresa las credenciales en la pantalla de consentimiento basada en el navegador que se abre.
Verifica que la autenticación se haya realizado de forma adecuada mediante la ejecución de uno de los comandos de kubectl para recuperar los detalles del clúster. Por ejemplo:
```
kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
```

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

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

Supongamos que deseas establecer una conexión SSH con una máquina remota y autenticarte en un clúster de usuario desde esta máquina. Para ello, el archivo de configuración de autenticación debe estar en la máquina remota y debes poder acceder al proveedor de Open ID desde la máquina local.

En la máquina local, ejecuta el siguiente comando:

ssh USER_NAME@REMOTE_MACHINE -L LOCAL_PORT:localhost:REMOTE_PORT

Donde:

USER_NAME y REMOTE_MACHINE son los valores estándar que se usan para acceder con SSH.
LOCAL_PORT es un puerto abierto de tu elección que se encuentra en la máquina local y que usarás para acceder a la máquina remota.
REMOTE_PORT es el puerto que configuraste para la URL de redireccionamiento de OIDC. Puedes encontrarlo en el campo kubectlRedirectURI del archivo de configuración de autenticación.

En la shell con SSH, ejecuta el siguiente comando para iniciar la autenticación:

gcloud anthos auth login --login-config AUTH_CONFIG_FILE

En el ejemplo anterior, AUTH_CONFIG_FILE es la ruta de acceso del archivo de configuración de autenticación en la máquina remota.

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

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

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

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

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

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

Abre la consola de Google Cloud:

Visitar la página Clústeres de Kubernetes
Ubica el clúster de clústeres de Anthos alojados en VMware en la lista y, luego, haz clic en Acceder.
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 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?

Obtén más información sobre los permisos y las reclamaciones.
Obtén más información sobre las reclamaciones personalizadas en los tokens de ID.

Autentica con OIDC y AD FS

Antes de comenzar

Personas

Crea URL de redireccionamiento

URL de redireccionamiento de la CLI de gcloud

URL de redireccionamiento de la consola de Google Cloud

Configura AD FS

Configura grupos de seguridad (opcional)

Mapea atributos de LDAP a nombres de reclamaciones

Registra la CLI de gcloud y la consola de Google Cloud con AD FS

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

Ejemplo: Autoriza usuarios y grupos

ClusterRole

ClusterRoleBinding

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

Crea el archivo de configuración de autenticación

Agrega varios clústeres al archivo de configuración de autenticación

Distribuye el archivo de configuración de autenticación

Linux

macOS

Windows

Linux

macOS

Windows

Configuración personalizada

Instala la CLI de gcloud

Quita complementos anteriores

Instala la CLI de gcloud y la CLI de gcloud

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

Linux

macOS

Windows

Realiza la autenticación con clústeres de usuario

Autentica a través de la CLI de gcloud

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

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

Soluciona los problemas de la configuración de OIDC

¿Qué sigue?

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