Autenticar con OIDC y ADFS

En esta página, se muestra cómo usar OpenID Connect (OIDC) con servicios federados de Active Directory (ADFS) a fin de configurar la autenticación para los clústeres de usuario de GKE On-Prem.

Para obtener una descripción general del flujo de autenticación, consulta Autenticación.

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. A fin de que el flujo de autenticación sea automático para los usuarios del clúster, GKE On-Prem proporciona el complemento de Kubectl para OIDC, un complemento de kubectl.

En este ejercicio, usarás un conjunto de asistentes de administración de ADFS para configurar una relación entre la herramienta de línea de comandos de kubectl, tu servidor ADFS 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.

Estos temas se aplican 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 los Servicios de federación de Active Directory (ADFS).
  • El servidor ADFS actúa como un proveedor de OpenID.

Descarga el complemento de Kubectl para OIDC

Descarga el complemento y configura los permisos de acceso:

Linux

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/linux_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Windows

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/windows_amd64/kubectl-oidc .

macOS

gsutil cp gs://gke-on-prem-release/oidc-plugin/v1.1alpha/darwin_amd64/kubectl-oidc .
chmod +x kubectl-oidc

Instala el complemento

Para instalar el complemento, mueve el archivo ejecutable a cualquier ubicación en tu PATH. El archivo ejecutable debe llamarse kubectl-oidc. Para obtener más información, consulta Instala complementos de kubectl.

Crea un URI de redireccionamiento

Debes proporcionar un URI de redireccionamiento que pueda usar el proveedor de OpenID a fin de mostrar tokens de ID. Los tokens se envían al complemento de Kubectl para OIDC, que se ejecuta en la máquina local de cada empleado y escucha en el puerto que elijas. Elige un número de puerto superior a 1024 que sea adecuado para este propósito. Entonces, el URI de redireccionamiento es:

http://localhost:[PORT]/callback

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

Configura ADFS

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

Configura el URI de redireccionamiento

  1. Abre el panel de administración de ADFS.

  2. Selecciona Grupos de aplicaciones > Acciones > Agregar un grupo de aplicaciones.

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

  4. Ingresa tu URI de redireccionamiento. Se te proporcionará un ID de cliente. Así es como el proveedor de OpenID identifica la aplicación kubectl. Guarda el ID de cliente para usarlo más adelante.

  5. Selecciona Generate a shared secret. La aplicación kubectl usa este secreto para autenticarse en el proveedor de OpenID. Guarda el secreto para usarlo más adelante.

Configura grupos de seguridad (opcional)

  1. En la administración de ADFS, selecciona Confianza con la parte autenticada > Agrega una nueva relación de confianza con la parte autenticada.

  2. Selecciona Compatible con reclamaciones 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 la información de su grupo de seguridad con kubectl oidc.

  8. Haz clic en Finalizar.

Asigna atributos LDAP a los nombres de reclamaciones

  1. En la administración de ADFS, selecciona Confianza de la parte autenticada > Editar política de emisión de reclamaciones.

  2. Selecciona Enviar atributos LDAP como reclamos y haz clic en Siguiente.

  3. En Claim rule name, ingresa groups.

  4. En Almacén de atributos, selecciona Active Directory.

  5. En la tabla, en LDAP Attribute, selecciona Token Groups - Qualified Names. En Outgoing Claim Type, selecciona grupos.

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

Registra kubectl con ADFS

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"

En el ejemplo anterior, se ilustra lo siguiente:

  • [CLIENT_ID] es el ID de cliente kubectl 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

Durante una instalación, genera un archivo de configuración de GKE On-Prem mediante gkectl create-config. En la configuración, se incluye la siguiente especificación de 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: Es la URL del proveedor de OpenID, como https://example.com/adfs. Las aplicaciones cliente, como el complemento de Kubectl para OIDC, 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. Este campo es obligatorio.
  • kubectlredirecturl: URL de redireccionamiento del localhost para el complemento de Kubectl para OIDC. Debes registrar la URL de redireccionamiento con tu proveedor de OpenID a fin de que la use el ID de cliente asignado a este clúster. Este campo es obligatorio.
  • clientid: El ID de la aplicación cliente, como el complemento de Kubectl para OIDC, que realiza solicitudes de autenticación al proveedor de OpenID. Este campo es obligatorio.
  • clientsecret: El secreto de la aplicación cliente. Este campo es obligatorio.
  • usehttpproxy: Elige si deseas implementar un proxy inverso en el clúster a fin de permitir que el agente de Connect acceda al proveedor de OIDC local para autenticar usuarios. El valor debe ser una string: "true" o "false". Este campo es obligatorio.
  • username: 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 OIDC. 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: Es el prefijo que se antepone a las reclamaciones de nombre de usuario para evitar conflictos con los nombres existentes. Si no se proporciona esta marca y username es un valor distinto de un correo electrónico, el prefijo predeterminado es issueruri#. El valor - se puede usar para inhabilitar todos los prefijos.
  • group: La reclamación JWT para usar como grupo de usuarios. Si la reclamación está presente, debe ser un arreglo de strings.
  • groupprefixes 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.
  • scopes: Los permisos adicionales para enviar al proveedor de OpenID como una lista delimitada por comentarios.
  • extraparams: Los parámetros de clave-valor adicionales para enviar al proveedor de OpenID.
  • capath: Ruta de acceso del certificado de la autoridad certificadora (CA) que firmó el certificado web del proveedor de identidad.

    Los clústeres de GKE On-Prem usan TLS para proteger la comunicación entre sus componentes. Para que Kubernetes genere automáticamente certificados de cliente durante la instalación y el inicio de nodos, GKE On-Prem debe instalarse con una CA.

    De forma predeterminada, GKE On-Prem crea una CA nueva durante la instalación que genera certificados TLS. La CA y los certificados generados se almacenan de forma local en el clúster de administrador.

Ejemplo: Autentica y autoriza un grupo

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 grupo, ya que GID puede ser persistente y, a la vez, fácil de auditar.

Supongamos que tu proveedor crea tokens de OpenID 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-'
...

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 una 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 el certificado de autoridad certificada (CA) del servidor

El kubeconfig del clúster de usuario almacena los datos de CA de su host en el campo certificate-authority-data. Debes decodificar este valor y almacenarlo en un archivo local, como server-ca-cert:

cat [USER_CLUSTER_KUBECONFIG]  | grep certificate-authority-data | awk '{ print $2}' | base64 --decode > server-ca-cert

Genera el archivo de configuración de autenticación del cliente

Después de configurar tu clúster de usuario para OpenID y crearlo, un usuario puede acceder al clúster pasando un archivo de configuración de autenticación de cliente a kubectl oidc login. Para generar un archivo de configuración de autenticación de cliente, ingresa el siguiente comando:

PowerShell

kubectl oidc client-config `
--issuer-uri [ISSUER_URI] `
--redirect-uri [REDIRECT_URI] `
--client-id [CLIENT_ID] `
--client-secret [CLIENT_SECRET] `
--scopes "allatclaims" `
--cluster-name [USER_CLUSTER_NAME] `
--server [CLUSTER_URL] `
--server-ca-file server-ca-cert `
--issuer-ca-file [ADFS_CA_CERT] `
--extra-params "resource=token-groups-claim"
> client-config.yaml
  • [ISSUER_URI] es el URI de la entidad emisora.
  • [REDIRECT_URI] es el URI de redireccionamiento.
  • [CLIENT_ID] es el ID de cliente para la aplicación “kubectl”.
  • [CLIENT_SECRET] es el secreto de cliente que se generó para ti.
  • [USER_CLUSTER_NAME] es el nombre de tu clúster de usuario.
  • [CLUSTER_URL] es la URL del servidor de la API de Kubernetes del clúster.
  • --server-ca-file acepta la ruta de acceso al archivo de CA que creaste en la sección anterior.
  • [ADFS_CA_CERT] es la ruta de acceso al archivo de certificado público para la CA de ADFS.
  • --extra-param envía un par clave-valor con la solicitud de autenticación al proveedor de OIDC.

Linux

kubectl oidc client-config \
--issuer-uri [ISSUER_URI] \
--redirect-uri [REDIRECT_URI] \
--client-id [CLIENT_ID] \
--client-secret [CLIENT_SECRET] \
--scopes "allatclaims" \
--cluster-name [USER_CLUSTER_NAME] \
--server [CLUSTER_URL] \
--server-ca-file server-ca-cert \
--issuer-ca-file [ADFS_CA_CERT] \
--extra-params "resource=token-groups-claim"
> client-config.yaml
  • [ISSUER_URI] es el URI de la entidad emisora.
  • [REDIRECT_URI] es el URI de redireccionamiento.
  • [CLIENT_ID] es el ID de cliente para la aplicación “kubectl”.
  • [CLIENT_SECRET] es el secreto de cliente que se generó para ti.
  • [USER_CLUSTER_NAME] es el nombre de tu clúster de usuario.
  • [CLUSTER_URL] es la URL del servidor de la API de Kubernetes del clúster.
  • --server-ca-file acepta la ruta de acceso al archivo de CA que creaste en la sección anterior.
  • [ADFS_CA_CERT] es la ruta de acceso al archivo de certificado público para la CA de ADFS.
  • --extra-param envía un par clave-valor con la solicitud de autenticación al proveedor de OIDC.

Con este comando se produce un archivo de autenticación de cliente llamado client-config.yaml. No edites este archivo de forma manual. Cada empleado que necesita autenticarse en el clúster del usuario debe recibir client-config.yaml.

Autentica en un clúster de usuario con el complemento de Kubectl para OIDC

Para autenticar en un clúster de usuario con el archivo de autenticación de cliente, sigue estos pasos desde tu máquina local o VM:

  1. Inicializa el complemento mediante el archivo client-config.yaml:

    kubectl oidc login --clientconfig-file=client-config.yaml --user [NAME] \
--kubeconfig [KUBECONFIG_OUTPUT_PATH]

    En el ejemplo anterior, se ilustra lo siguiente:

    • [NAME] es el nombre de usuario que elegiste.
    • [KUBECONFIG_OUTPUT_PATH] es la ubicación de salida del archivo kubeconfig en el que se almacenan las credenciales.

    kubectl oidc login inicia un navegador en el que el usuario o el empleado pueden ingresar sus 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.

  2. Ahora deberías estar autenticado. Para ver si te autenticaste de forma correcta, ingresa cualquier comando kubectl. Por ejemplo:

    kubectl get nodes --kubeconfig [KUBECONFIG_OUTPUT_PATH]

Resumen

Tu empresa ejecuta un servidor ADFS que actúa como tu proveedor de OpenID. Tu proveedor de OpenID conoce la aplicación kubectl y sabe que kubectl puede solicitar los permisos openid y allatclaims.

El atributo Token-Groups Qualified Names de LDAP en tu base de datos de AD se mapea a la reclamación groups en tu proveedor de OpenID. El proveedor muestra los tokens que incluyen el ID del empleado, el ID de la entidad emisora y las reclamaciones openid y groups. Mediante la reclamación groups, se enumeran los grupos de seguridad a los que pertenece un empleado.

¿Qué sigue?

Anterior
Autenticar con OIDC
Siguiente
Registros de auditoría