Puedes autenticarte con clústeres de Anthos alojados en equipos físicos con OpenID Connect (OIDC). OIDC es una capa de autenticación basada en OAuth 2.0, que especifica una API de HTTP de RESTful y usa JSON como formato de datos.
OIDC te permite usar tu proveedor de identidad existente para administrar la autenticación de usuarios y grupos en los clústeres de Anthos alojados en clústeres físicos. Con OIDC, puedes administrar el acceso a un clúster de clústeres de Anthos alojados en equipos físicos mediante los procedimientos estándar de tu organización para crear, habilitar y habilitar cuentas. También puedes usar los grupos de seguridad de tu organización para configurar el acceso a un clúster o a servicios específicos de un clúster. El acceso administrado funciona en cualquier tipo de clúster de clústeres de Anthos alojados en equipos físicos: administrador, usuario, híbrido o independiente.
Clústeres de Anthos alojados en equipos físicos admite proveedores de identidad locales y de acceso público. Por ejemplo, localmente, podrías usar un componente de Servicios de federación de Active Directory. También puedes usar servicios de proveedor de identidad de acceso público de Google o Okta. Además, una autoridad certificadora (CA) conocida o una CA privada puede emitir certificados de proveedor de identidad.
Existen dos métodos de autenticación de OIDC disponibles para los usuarios:
Autenticación de OIDC a través de una interfaz de línea de comandos (CLI) en la que los usuarios ejecutan un comando de gcloud y se autentican a través de una página de acceso o de consentimiento basado en el navegador
Autenticación de OIDC a través de la IU de la consola de Google Cloud, donde los usuarios acceden a un clúster directamente desde la página de clústeres de Kubernetes. Este método requiere que tu clúster se registre en Google Cloud. Los clústeres se registran de forma automática durante la instalación de un clúster de clústeres de Anthos alojados en equipos físicos.
Ten en cuenta que OIDC no admite flujos de trabajo sin interfaz gráfica: OIDC requiere una autenticación basada en navegador para redireccionar a los usuarios a la página web del proveedor de identidad y solicitar a los usuarios que proporcionen su consentimiento y acceso de cuenta/contraseña.
OIDC y control de acceso de Kubernetes
La autenticación de OIDC suele combinarse con el Control de acceso según la función de Kubernetes (RBAC). RBAC te permite crear políticas de autorización detalladas que definen qué usuarios o grupos pueden realizar operaciones específicas en un conjunto determinado de recursos de clúster.
Descripción general de la autenticación de OIDC
Una autenticación de OIDC típica incluye los pasos siguientes:
- Un usuario puede acceder a un proveedor de OpenID si presenta un nombre de usuario y una contraseña.
El proveedor de OpenID emite un token de ID para el usuario.
El token es firmado por el proveedor y se devuelve a través de una URL de devolución de llamada preconfigurada.
Una aplicación, que actúa en nombre del usuario, envía una solicitud HTTPS al servidor de la API de Kubernetes. La aplicación incluye el token de ID del usuario en el encabezado de la solicitud.
El servidor de la API de Kubernetes verifica el token de ID con el certificado del proveedor y analiza el token para conocer la identidad del usuario y, si están presentes, los grupos del usuario.
Por lo general, en la configuración y la autenticación de OIDC están involucradas tres personas:
El administrador de la organización, que elige un proveedor de OpenID y registra aplicaciones cliente con el proveedor.
Un administrador de plataforma, que crea uno o más clústeres y archivos de configuración de autenticación para los usuarios que usan los clústeres.
Un operador o desarrollador de apps, que ejecuta cargas de trabajo en uno o más clústeres y usa OIDC para autenticarse
Puedes usar cualquier proveedor certificado de OpenID (los proveedores cuentan con la certificación de OpenID Foundation). El proceso de registro específico depende del proveedor, pero, por lo general, incluye los siguientes pasos:
Obtén más información sobre el URI de la entidad emisora del proveedor. Aquí es donde la CLI de gcloud o Google Cloud Console envía solicitudes de autenticación.
Proporciona al proveedor las URL de redireccionamiento para la CLI de gcloud y la consola de Google Cloud.
Establece un ID de cliente y un secreto del cliente. Tanto la CLI de gcloud como la consola de Google Cloud usan este ID/secreto del cliente para autenticarse en el proveedor de OpenID.
Establece un alcance personalizado y reclama los grupos de seguridad. En general, debes definir las políticas de RBAC de tu clúster según los grupos, en lugar de los usuarios, para que las políticas sean más estables y auditables. La mayoría de los proveedores de OIDC incluyen reclamaciones de grupo en tokens de ID si se solicitaron alcances adecuados. Los reclamos y reclamaciones de grupo específicos difieren entre los proveedores de OIDC, por lo que establecer estas reclamaciones y alcances específicos del proveedor requiere personalización.
Antes de instalar un nuevo clúster de clústeres Anthos alojados en equipos físicos, el administrador de la plataforma suele obtener la configuración de OIDC del administrador de la organización y configura los campos OIDC relevantes en la configuración del clúster.
Una vez que se complete la instalación del clúster, el administrador de la plataforma obtendrá los archivos de configuración de autenticación y los compartirá con los usuarios de la CLI. Por lo general, el administrador de la plataforma comparte la configuración de autenticación mediante el alojamiento de los archivos en un host seguro o mediante el uso de herramientas internas para enviar los archivos de configuración a la máquina de cada usuario. Luego, los usuarios de la CLI autentican el clúster nuevo con los archivos de configuración compartidos.
El administrador de la plataforma también puede almacenar los detalles de configuración de la autenticación para varios clústeres dentro de un mismo archivo de configuración de autenticación.
Ten en cuenta que los usuarios de la consola de Google Cloud no necesitan estos archivos de configuración.
Cuando los usuarios acceden a la consola de Google Cloud, pueden seleccionar Authenticate
with the Identity Provider configurado para el clúster y, luego, hacer clic en Login..