Resumen

  • 2 minutos

La prueba de penetración de Contoso Retail identificó tres brechas de seguridad en su entorno de Azure Kubernetes Service (AKS): asignaciones de roles permanentes sin requisito de expiración o aprobación, un servidor de API público sin restricciones de IP de origen y cargas de trabajo que se ejecutan sin directivas de aislamiento de pod. En este módulo se aborda cada brecha con controles que funcionan en cuatro capas de seguridad distintas.

Los controles de identidad cerraron la primera brecha. Se habilitó la integración con Microsoft Entra ID y se deshabilitaron las cuentas locales, lo que garantiza que todos los flujos de autenticación del clúster pasen por la infraestructura de gobernanza de identidades de Contoso Retail. Las asociaciones de roles se asignaron a grupos de Microsoft Entra, por lo que los cambios de acceso solo requieren actualizaciones de pertenencia a los grupos en lugar de modificar los objetos RBAC de Kubernetes. Azure RBAC rige quién recupera las credenciales del clúster de Azure; RBAC de Kubernetes rige lo que las identidades autenticadas pueden hacer dentro del clúster.

Los controles de red abordaron la segunda brecha. Los clústeres privados y los intervalos IP autorizados limitan quién puede llegar al servidor de API en el nivel de red. Las políticas de red de Kubernetes sustituyeron el modelo predeterminado de permitir toda la comunicación entre pods por reglas explícitas de entrada y salida: el tráfico solo fluye donde la política lo permite. Una directiva de salida dedicada bloquea el acceso de pod al servicio de metadatos de instancia de Azure, lo que elimina una de las rutas de acceso más confiables que usan los atacantes para obtener credenciales de nivel de nodo.

La identidad de carga de trabajo eliminó el almacenamiento de credenciales en el clúster. Id. de carga de trabajo de Microsoft Entra reemplazó los secretos de identidades de servicio y las claves de API estáticas por tokens federados de corta duración generados a petición. El controlador CSI del almacén de secretos de Key Vault montó secretos directamente en los pods sin escribirlos en etcd. La integración de ACR eliminó por completo los secretos para extraer imágenes de las especificaciones de los pods.

Los estándares de seguridad de los pods permitieron subsanar la tercera vulnerabilidad. El Estándar de seguridad restringido de Pods bloqueó la escalada de privilegios, exigió la ejecución sin privilegios de root e impuso un perfil de seccomp a nivel de espacio de nombres. La configuración del contexto de seguridad en las especificaciones del pod hizo explícitas y auditables estas restricciones para cada contenedor. Los espacios de nombres de usuario y los perfiles de AppArmor proporcionaron una capa adicional de aislamiento del host.

Cada capa se dirigió a una superficie expuesta a ataques distinta. Juntos, transformaron la configuración de seguridad de AKS de Contoso Retail, pasando de valores predeterminados permisivos a controles de seguridad definidos de forma explícita y alineados con las responsabilidades del ingeniero de seguridad.

Aprende más