Consideraciones sobre la administración de identidades y acceso para AKS

En este artículo se proporcionan recomendaciones y consideraciones de diseño para la administración de identidades y acceso cuando usa Azure Kubernetes Service (AKS). Hay numerosos aspectos de la administración de identidades y accesos, incluidas las identidades de clúster, las identidades de carga de trabajo y el acceso de operador.

Consideraciones de diseño

• Decida qué identidad de clúster se va a usar (identidad administrada o entidad de servicio).
• Decida cómo autenticar el acceso al clúster: en función de los certificados de cliente o mediante Microsoft Entra ID.
• Decida si va a tener un clúster multiinquilino y cómo se va a configurar el control de acceso basado en rol (RBAC) en Kubernetes.
  • Elija un método de aislamiento. Los métodos incluyen el espacio de nombres, la directiva de red (solo permitida por Azure CNI), el proceso (grupo de nodos) y el clúster.
  • Determine los roles RBAC de Kubernetes y la asignación de proceso por equipo de aplicación, para el aislamiento.
  • Decida si los equipos de aplicación pueden leer otras cargas de trabajo en sus clústeres o en otros clústeres.
• Determine los permisos para los roles RBAC de Azure personalizados de su zona de aterrizaje de AKS.
  • Decida qué permisos se necesitan para que el rol de ingeniería de fiabilidad del sitio (SRE) pueda administrar todo el clúster y solucione los problemas que puedan surgir.
  • Decida qué permisos se necesitan en SecOps.
  • Decida qué permisos necesita el propietario de la zona de aterrizaje.
  • Decida qué permisos necesitarán los equipos de aplicación para implementar en el clúster.
• Decida si necesita identidades de carga de trabajo (Id.de carga de trabajo de Microsoft Entra). Puede que las necesite para servicios como la integración de Azure Key Vault y Azure Cosmos DB.

Recomendaciones de diseño

• Identidades de clúster.
  • Utilice su propia identidad administrada para el clúster de AKS.
  • Defina roles RBAC de Azure personalizados para la zona de aterrizaje de AKS con el fin de simplificar la administración de los permisos necesarios para la identidad administrada del clúster.
• Acceso al clúster.
  • Use RBAC de Kubernetes con Microsoft Entra ID para limitar los privilegios y minimizar los privilegios de administrador. Esto ayuda a proteger el acceso a los secretos y la configuración.
  • Use la integración de Microsoft Entra administrada por AKS a fin de que pueda usar Microsoft Entra ID para la autenticación y el acceso de operadores y desarrolladores.
• Defina los roles RBAC y los enlaces de rol necesarios en Kubernetes.
  • Use los roles y los enlaces de rol de Kubernetes con los grupos de Microsoft Entra para el acceso de los roles de ingeniería de fiabilidad del sitio (SRE), SecOps y desarrolladores.
  • Considere la posibilidad de usar Azure RBAC para Kubernetes, que permite la administración unificada y el control de acceso en los recursos de Azure, AKS y los recursos de Kubernetes. Cuando Azure RBAC para Kubernetes está habilitado, no es necesario administrar por separado las credenciales y las identidades de usuario de Kubernetes. Las entidades de seguridad de Microsoft Entra se validarán exclusivamente con Azure RBAC, pero las cuentas de servicio y los usuarios de Kubernetes normales se validarán exclusivamente mediante el RBAC de Kubernetes.
• Conceda a SRE acceso completo Just-In-Time, según sea necesario.
  • Use Privileged Identity Management en Microsoft Entra ID y la administración de identidades y acceso en zonas de aterrizaje de Azure.
• Use el id. de carga de trabajo de Microsoft Entra para Kubernetes. Al implementar esta federación, los desarrolladores pueden usar cuentas de servicio nativas de Kubernetes y la federación para acceder a los recursos que administra Microsoft Entra ID, como Azure y Microsoft Graph.