Gobernanza de un extremo a otro de DevOps a Azure
En este artículo se describe cómo administrar e implementar detenidamente prácticas de gobernanza sólidas para el equipo, como los permisos de control de acceso basado en roles.
No basta con planear e implementar un modelo de control de acceso basado en rol (RBAC) de Azure para plantillas de Azure Resource Manager (plantillas de ARM), que restringe el acceso a través de Azure Portal y la CLI de Azure.
Si este modelo no se refleja para la automatización de DevOps, su organización podría dejar abierta una puerta trasera de seguridad. Considere un ejemplo en el que un desarrollador no tenga acceso a través de plantillas de ARM, pero todavía tenga permisos suficientes para cambiar el código de la aplicación o la infraestructura como código y desencadenar un flujo de trabajo de automatización. El desarrollador, indirectamente a través de DevOps, puede acceder a las plantillas de ARM y realizar cambios destructivos en las mismas.
Plano de administración de identidades único con grupos de Microsoft Entra
El primer paso consiste en integrar Microsoft Entra ID para usar el inicio de sesión único por procedimiento recomendado de administración de identidades.
Si no usa un producto de CI de primera entidad de Azure como Azure DevOps, compruebe si su proveedor ofrece la integración de Microsoft Entra.
El segundo paso consiste en usar grupos de Microsoft Entra, los mismos que ya usa para el modelo de RBAC de plantillas de ARM. Es un procedimiento recomendado para asignar roles a los grupos de Microsoft Entra, no a usuarios individuales. Para crear un modelo de gobernanza de un extremo a otro, deberá realizar este paso para plantillas de ARM y DevOps.
Azure DevOps tiene una integración perfecta con Microsoft Entra ID, incluida la pertenencia a grupos de Microsoft Entra, lo que facilita la aplicación de asignaciones de roles al mismo grupo de Microsoft Entra.
Nota:
Si usa otro proveedor de CI, es posible que tenga un contenedor lógico intermediario para administrar pertenencias a grupos, que también necesita para mantener si la pertenencia a grupos de Microsoft Entra no está sincronizada.
En el diagrama siguiente se muestra cómo se usa Microsoft Entra ID como plano de administración de identidades único. En las plantillas de ARM y en nuestras herramientas de DevOps (Azure DevOps en este ejemplo), solo es necesario administrar asignaciones de roles, no pertenencias, que deben administrarse en Microsoft Entra ID. Tenga en cuenta que los nombres de recursos siguen convenciones de nomenclatura y abreviaturas recomendadas para los recursos de Azure.
Escenario de ejemplo: eliminación del acceso del contratista con un solo paso, la pertenencia a Microsoft Entra
Para concretar la gobernanza de un extremo a otro, examinemos las ventajas con un escenario de ejemplo.
Si usa Microsoft Entra ID como plano de administración de identidades único, puede quitar el acceso de un desarrollador a los recursos de Azure con una sola acción, ajustando su pertenencia a grupos de Microsoft Entra. Por ejemplo, si se debe revocar el acceso de un contratista al finalizar el proyecto, al quitar la pertenencia del contratista de los grupos de Microsoft Entra pertinentes, se quita el acceso a las plantillas de ARM y Azure DevOps.
Reflejo del modelo de RBAC con asignaciones de roles
Cuando se planee correctamente, el modelo de RBAC de las herramientas de CI reflejará fielmente el modelo de RBAC de Azure. Aunque los ejemplos de nombre de grupo de Microsoft Entra del diagrama anterior implican reglas de seguridad, la pertenencia por sí sola no aplica la seguridad. Recuerde que RBAC es una combinación de entidades de seguridad, definiciones y ámbitos, que no entra en vigor hasta que se crea la asignación de roles.
- En el diagrama se muestra la asignación de roles para un grupo de Microsoft Entra único,
contoso-admins-group. - A este grupo de Microsoft Entra se le asigna el rol Propietario para las plantillas de Azure ARM en varios ámbitos de suscripción:
- Suscripción
contoso-dev-sub - Suscripción
contoso-prod-sub
- Suscripción
contoso-admins-groupse agrega al grupo Administradores de proyectos para Azure DevOps en un único ámbito del proyecto.
El grupo de Microsoft Entra tiene roles con privilegios similares para las plantillas de ARM y DevOps. Siguiendo esta lógica, si tenemos un grupo de desarrolladores asignado al rol Colaborador para plantillas de ARM, no esperaríamos que pertenecieran al grupo Administradores de proyectos para DevOps.
Ahora que comprende la necesidad de proteger los flujos de trabajo de DevOps y las plantillas de ARM, debe:
- Revisar el modelo de RBAC y pensar en cómo los roles y responsabilidades que ha definido para las plantillas de ARM coinciden con el flujo de trabajo de CI/CD.
- Revise las soluciones de administración de identidades de la plataforma de CI e integre Microsoft Entra ID. Idealmente, querrá incluir la pertenencia a grupos de Microsoft Entra.
- Revisar los roles y niveles de acceso que ofrecen las herramientas de CI y compararlos con el modelo de RBAC de Azure. Los roles y niveles de acceso no se asignarán uno a uno. Compruebe la configuración. Si un desarrollador no tiene acceso para las plantillas de ARM, no debería tener acceso para DevOps. En el ejemplo más sencillo, un desarrollador que no tiene permisos de escritura en los recursos de producción no debe tener acceso directo para desencadenar ejecuciones de la canalización de producción.
Para más información sobre el diseño y los permisos de gobernanza, consulte:
- Método recomendado para conceder y restringir permisos
- Permisos y acceso predeterminados para Azure DevOps
- Administración del acceso de los usuarios a su organización con roles
Pasos siguientes
Ahora que comprende la necesidad de proteger los flujos de trabajo de DevOps y las plantillas de ARM, aprenda a administrar secretos de forma segura.