Uso de proveedores de identidades externos con autenticación estructurada de AKS (versión preliminar)

Azure Kubernetes Service (AKS) admite la autenticación estructurada, que permite configurar proveedores de identidades externos para autenticar a los usuarios en el servidor de API de Kubernetes. Esta característica se basa en la configuración de autenticación estructurada de Kubernetes original. AKS implementa esta funcionalidad a través de autenticadores json Web Token (JWT) que validan tokens de proveedores de identidades externos según la configuración. Con la autenticación estructurada, las organizaciones pueden integrar AKS con su infraestructura de identidad existente más allá de Microsoft Entra ID.

En este artículo se proporciona información general sobre cómo usar proveedores de identidades externos con autenticación estructurada de AKS, incluidos conceptos clave, consideraciones de seguridad y pasos siguientes para la configuración.

Ventajas de la autenticación del proveedor de identidades externo

La autenticación estructurada amplía AKS más allá de la integración tradicional de Microsoft Entra ID mediante la compatibilidad con proveedores de identidades openID Connect (OIDC) estándar del sector. Esta característica permite:

• Autentique a los usuarios con proveedores de identidades externos como Google, GitHub o cualquier proveedor compatible con OIDC.
• Mantenga la administración centralizada de identidades en toda la organización.
• Implemente reglas personalizadas de validación de declaraciones y asignación de usuarios.
• Admite varios proveedores de identidades simultáneamente en un único clúster.

Flujo de autenticación del proveedor de identidades externo

Cuando un usuario intenta acceder al servidor de API de Kubernetes mediante la autenticación estructurada con un proveedor de identidades externo, el flujo de autenticación y autorización es el siguiente:

• Autenticación: los pasos siguientes validan la identidad del usuario:
  • Presentación de tokens: el usuario presenta un token JWT desde su proveedor de identidades configurado.
  • Validación de tokens: el servidor de API valida la firma, el emisor, la audiencia y la expiración del token.
  • Procesamiento de notificaciones: se aplican reglas de validación de notificaciones personalizadas para asegurarse de que el token cumple sus requisitos.
  • Asignación de usuarios: las reclamaciones se asignan a la identidad de usuario de Kubernetes (nombre de usuario, grupos y atributos adicionales).
• Autorización: El Control de acceso basado en roles (RBAC) estándar de Kubernetes determina qué acciones puede realizar un usuario autenticado.

Proveedores de identidad compatibles

Aunque la autenticación estructurada de AKS permite cualquier proveedor de identidades compatible con OIDC, los proveedores comunes incluyen:

• GitHub: autenticación mediante identidades de GitHub o Acciones de GitHub.
• Google OAuth 2.0: use cuentas de Google para la autenticación.
• Proveedores genéricos de OIDC: cualquier proveedor que implemente estándares OIDC.
• Soluciones de identidad personalizadas: implementaciones de OIDC específicas de la organización.

Requisitos para proveedores de identidades externos

Los proveedores de identidades externos deben cumplir los siguientes requisitos para trabajar con la autenticación estructurada de AKS:

• Compatibilidad con estándares OIDC.
• Proporcione puntos de conexión de detección de OIDC accesibles públicamente.
• Emita tokens JWT con reclamaciones adecuadas.
• Sea accesible desde nodos de clúster de AKS para la validación de tokens.

Autenticadores JWT para la autenticación estructurada de AKS

Un autenticador JWT es un objeto de configuración que define cómo AKS valida y procesa los tokens de un proveedor de identidades externo. Por ejemplo, AKS espera un token de ID (JWT) cuya reclamación aud (audiencia) coincida con el valor de audiencia que configura para el autenticador, como "my-api" o un ID de cliente de OAuth. Cada autenticador JWT incluye los siguientes componentes:

• Configuración del emisor: especifica la dirección URL del emisor de OIDC y los valores de audiencia esperados para los tokens.
• Reglas de validación de afirmaciones: usa expresiones CEL (Common Expression Language) para aplicar la lógica de validación personalizada en las afirmaciones de token.
• Mapeos de reclamos: Define cómo los reclamos JWT se asignan a atributos de usuario de Kubernetes, como el nombre de usuario, los grupos y los campos adicionales.
• Reglas de validación de usuario: Aplica lógica de validación adicional después del mapeo de claims para restringir o permitir el acceso.

Expresiones CEL para la validación y mapeo de reclamaciones

La autenticación estructurada usa expresiones CEL para la validación y asignación de afirmaciones flexibles. CEL proporciona un entorno de espacio aislado seguro para evaluar la lógica personalizada frente a reclamos JWT.

Expresiones CEL de ejemplo:

// Validate that the 'sub' claim exists
has(claims.sub)

// Map username with AKS prefix
'aks:jwt:' + claims.sub

// Map groups from comma-separated string
claims.groups.split(',').map(g, 'aks:jwt:' + g)

// Conditional mapping based on claim verification
'aks:jwt:' + (claims.email_verified ? claims.email : claims.sub)

Procedimientos recomendados de seguridad

Tenga en cuenta los siguientes procedimientos recomendados de seguridad al usar proveedores de identidades externos con autenticación estructurada de AKS:

• Usar validación de notificaciones segura: implemente reglas de validación completas para garantizar que solo se acepten tokens autorizados.
• Limitar el ámbito de los tokens: configure el proveedor de identidades para que emita tokens con las notificaciones mínimas necesarias.
• Rotación regular: Cambie periódicamente las claves secretas de cliente y los certificados.
• Supervisión del acceso: habilite los registros de recursos y active kube-apiserver los registros para inspeccionar los posibles problemas con los autenticadores JWT configurados y realizar un seguimiento de los eventos de autenticación.
• Configuraciones de prueba: valide primero la configuración del autenticador JWT en un entorno que no sea de producción.

Consideraciones de seguridad

Tenga en cuenta las siguientes consideraciones de seguridad al usar proveedores de identidades externos con autenticación estructurada de AKS:

• Requisitos de prefijo: todos los nombres de usuario y grupos asignados a través de la autenticación estructurada deben tener el prefijo con aks:jwt: para evitar conflictos con otros métodos de autenticación y cuentas del sistema.
• Acceso a la red: los puntos de conexión del proveedor de identidades deben ser accesibles desde:
  • Nodos de clúster de AKS para la validación de tokens.
  • Sistemas cliente para la adquisición de tokens.
  • Las rutas de acceso de red implicadas en el flujo de autenticación.
• Capas de validación: la autenticación estructurada proporciona varias capas de validación:
  • La validación de firma de tokens garantiza la autenticidad del token.
  • La validación de reclamaciones estándar comprueba el emisor, la audiencia y la caducidad.
  • La validación de reclamaciones personalizada aplica los requisitos específicos de su organización.
  • Comprobaciones finales de Validación de usuario después de la asignación de reclamaciones.

Contenido relacionado

Para obtener más información sobre la autenticación estructurada y las características relacionadas, consulte los siguientes recursos:

• Configuración de la autenticación estructurada para AKS
• Configuración de autenticación estructurada de Kubernetes
• Expresiones CEL en Kubernetes
• Especificación de OpenID Connect