Gobernanza de un extremo a otro en Azure al usar CI/CD

Al desarrollar un modelo de gobernanza para su organización, es importante recordar que azure Resource Manager es solo una manera de administrar recursos. Azure DevOps y la automatización de la integración y entrega continua (CI/CD) pueden ser una puerta trasera de seguridad involuntaria si no se protegen correctamente. Estos recursos deben protegerse mediante la creación de reflejo del modelo de control de acceso basado en rol (RBAC) que se usa para Resource Manager.

El concepto de gobernanza integral es independiente del proveedor. La implementación que se describe aquí usa azure DevOps, pero también se mencionan brevemente alternativas.

Casos de uso potenciales

Esta implementación de referencia y demostración es de código abierto y está pensada para usarse como herramienta de enseñanza para las organizaciones que no están familiarizados con DevOps y necesitan crear un modelo de gobernanza para la implementación en Azure. Lea este escenario cuidadosamente para comprender las decisiones detrás del modelo usado en este repositorio de ejemplo.

Cualquier modelo de gobernanza debe estar vinculado a las reglas de negocios de la organización, que se reflejan en cualquier implementación técnica de los controles de acceso. En este modelo de ejemplo se usa una empresa ficticia con el siguiente escenario común (con requisitos empresariales):

• Grupos de Microsoft Entra alineados con los dominios de negocio y los modelos de permisos
  La organización tiene muchos dominios empresariales verticales, como "frutas" y "verduras", que funcionan en gran medida de forma independiente. En cada dominio empresarial, hay dos niveles o privilegios, que se asignan a distintos grupos de *-admins o *-devs Microsoft Entra. Esto permite orientar específicamente a los desarrolladores al configurar permisos en la nube.

• Entornos de Implementación
  Cada equipo tiene dos entornos:

  • Producción. Solo los administradores tienen privilegios elevados.
  • No de producción. Todos los desarrolladores tienen privilegios elevados (para fomentar la experimentación y la innovación).

• objetivos de automatización
  Cada aplicación debe implementar Azure DevOps no solo para la integración continua (CI), sino también para la implementación continua (CD). Por ejemplo, las implementaciones se pueden desencadenar automáticamente mediante cambios en el repositorio de Git.

• Recorrido en la nube hasta ahora
  La organización comenzó con un modelo de proyecto aislado para acelerar el recorrido a la nube. Pero ahora están explorando opciones para romper silos y fomentar la colaboración mediante la creación de los proyectos de "colaboración" y "supermercado".

En este diagrama simplificado se muestra cómo las ramas de un repositorio de Git se asignan a entornos de desarrollo, almacenamiento provisional y producción:

Descargar un SVG de este diagrama.

Arquitectura

En este diagrama se muestra cómo la vinculación de Resource Manager y CI/CD a Microsoft Entra ID es la clave para tener un modelo de gobernanza de un extremo a otro.

Descargue un SVG de esta arquitectura.

Nota

Para que el concepto sea más fácil de entender, en el diagrama solo se ilustra el dominio "verduras" . El dominio "frutas" tendría un aspecto similar y usaría las mismas convenciones de nomenclatura.

Flujo de trabajo

La numeración refleja el orden en el que los administradores de TI y los arquitectos empresariales piensan y configuran sus recursos en la nube.

1. Microsoft Entra ID

   Se integra Azure DevOps con Microsoft Entra ID para tener un único plano para la identidad. Esto significa que un desarrollador usa la misma cuenta de Microsoft Entra para Azure DevOps y Resource Manager. Los usuarios no se agregan individualmente. En su lugar, los grupos de Microsoft Entra asignan la pertenencia para que podamos quitar el acceso de un desarrollador a los recursos en un solo paso mediante la eliminación de sus pertenencias a grupos de Microsoft Entra. Para cada dominio, creamos:

   • Grupos de Microsoft Entra. Dos grupos por dominio (descritos más adelante en el paso 4 y 5 más adelante en este artículo).
   • Entidades de servicio. Un principal de servicio explícito por entorno.

2. entorno de producción

   Para simplificar la implementación, esta implementación de referencia usa un grupo de recursos para representar el entorno de producción. En la práctica, debe usar otra suscripción.

   El acceso con privilegios a este entorno solo se limita a los administradores.

3. entorno de desarrollo

   Para simplificar la implementación, esta implementación de referencia usa un grupo de recursos para representar el entorno de desarrollo. En la práctica, debe usar otra suscripción.

4. Asignaciones de roles en el Gestor de Recursos

   Aunque los nombres de grupo de Microsoft Entra implican un rol, los controles de acceso no se aplican hasta que se configura una asignación de roles. Esto asigna un rol a una entidad de seguridad de Microsoft Entra para un ámbito específico. Por ejemplo, los desarrolladores tienen el rol de Colaborador en el entorno de producción.

   Entidad de seguridad de Microsoft Entra	Entorno de desarrollo (Resource Manager)	Entorno de producción (Administrador de Recursos)
   veggies-devs-group	Propietario	Lector
   veggies-admins-group	Dueño	Dueño
   veggies-ci-dev-sp	Rol personalizado *	–
   veggies-ci-prod-sp	–	Rol personalizado *

   * Para simplificar la implementación, esta implementación de referencia asigna el rol Owner a las entidades de servicio. Pero debe crear un rol personalizado en producción que impida que una entidad de servicio quite los bloqueos de administración que ha colocado en los recursos. Esto ayuda a proteger los recursos frente a daños accidentales, como la eliminación de la base de datos.

   Para comprender el razonamiento que subyace a las asignaciones de roles individuales, consulte la sección consideraciones más adelante en este artículo.

5. Asignaciones de grupos de seguridad en Azure DevOps

   Los grupos de seguridad funcionan como roles en Resource Manager. Aproveche los roles integrados y utilice el valor predeterminado Colaborador para los desarrolladores. Los administradores son asignados al grupo de seguridad Administrador de Proyectos para obtener permisos elevados, lo que les permite configurar los permisos.

   Tenga en cuenta que Azure DevOps y Resource Manager tienen modelos de permisos diferentes:

   • Azure Resource Manager usa un modelo de permisos aditivos.
   • Azure DevOps usa un modelo de permisos mínimos.

   Por este motivo, la pertenencia a los grupos de -admins y -devs debe ser mutuamente excluyente. De lo contrario, las personas afectadas tendrán menos acceso de lo esperado en Azure DevOps.

   Nombre del grupo	Rol de Resource Manager	Rol de Azure DevOps
   fruits-all	–	–
   fruits-devs	Colaborador	Colaborador
   fruits-admins	Dueño	Administradores de proyectos
   veggies-all	–	–
   veggies-devs	Colaborador	Colaborador
   veggies-admins	Dueño	Administradores de proyectos
   infra-all	–	–
   infra-devs	Colaborador	Colaborador
   infra-admins	Dueño	Administradores de proyectos

   En un escenario de colaboración limitada como, por ejemplo, que el equipo de frutas invite al equipo de verduras a colaborar en un único repositorio, usarían el grupo veggies-all.

   Para comprender el razonamiento subyacente a las asignaciones de roles individuales, consulte la sección consideraciones más adelante en este artículo.

6. Conexiones de servicio

   En Azure DevOps, una conexión de servicio es un contenedor genérico alrededor de una credencial. Creamos una conexión de servicio que contiene el identificador de cliente y el secreto de cliente de la entidad de servicio. Los administradores de proyectos pueden configurar el acceso a este recurso protegido cuando sea necesario, por ejemplo, al requerir la aprobación humana antes de la implementación. Esta arquitectura de referencia tiene dos protecciones mínimas en la conexión de servicio:

   • Los administradores deben configurar permisos de canalización para controlar qué canalizaciones pueden acceder a las credenciales.
   • Los administradores también deben configurar una comprobación de control de rama para que solo las canalizaciones que se ejecutan en el contexto de la rama production puedan usar el elemento prod-connection.

7. Repositorios de Git

   Dado que nuestras conexiones de servicio están ligadas a ramas a través de los controles de rama , es fundamental configurar permisos en los repositorios de Git y aplicar las directivas de rama . Además de requerir que se pasen las compilaciones de CI, también es necesario que las solicitudes de incorporación de cambios tengan al menos dos aprobadores.

Componentes

• Azure DevOps
• Microsoft Entra ID
• Azure Resource Manager
• Azure Repos
• Azure Pipelines

Alternativas

El concepto de gobernanza integral es independiente del proveedor. Aunque este artículo se centra en Azure DevOps, azure DevOps Server podría usarse como sustituto local. Como alternativa, también puede usar un conjunto de tecnologías para una canalización de desarrollo de CI/CD de código abierto mediante opciones como Jenkins y GitLab.

Tanto Azure Repos como GitHub son plataformas creadas para usar el sistema de control de versiones de Git de código abierto. Aunque sus conjuntos de características son algo diferentes, ambos se pueden integrar en modelos de gobernanza global para CI/CD. GitLab es otra plataforma basada en Git que proporciona funcionalidades sólidas de CI/CD.

En este escenario, se usa Terraform como herramienta de Infraestructura como código (IaC). Entre las alternativas se incluyen Jenkins, Ansibley Chef.

Consideraciones

Para lograr la gobernanza de un extremo a otro en Azure, es importante comprender el perfil de seguridad y permisos de la ruta de acceso del equipo del desarrollador a producción. En el diagrama siguiente se muestra un flujo de trabajo de CI/CD de línea base con Azure DevOps. El icono de bloqueo rojo indica los permisos de seguridad que el usuario debe configurar. No configurar ni mal configurar los permisos dejará vulnerables las cargas de trabajo.

Diagrama de
Descargue un SVG de de este flujo de trabajo.

Para proteger correctamente las cargas de trabajo, debe usar una combinación de configuraciones de permisos de seguridad y comprobaciones humanas en el flujo de trabajo. Es importante que cualquier modelo de RBAC también debe extenderse a las canalizaciones y el código. A menudo se ejecutan con identidades privilegiadas y destruirán las cargas de trabajo si se les indica que lo hagan. Para evitar que esto suceda, debe configurar directivas de rama en el repositorio para requerir aprobación humana antes de aceptar cambios que desencadenen canalizaciones de automatización.

Fases de implementación	Responsabilidad	Descripción
Solicitudes de incorporación de cambios	Usuario	Los ingenieros deben revisar su trabajo, incluido el propio código de canalización.
Protección de rama	Compartido	Configure Azure DevOps para rechazar los cambios que no cumplan ciertos estándares, como las comprobaciones de CI y las revisiones por homólogos (mediante solicitudes de incorporación de cambios).
Canalización como código	Usuario	Un servidor de compilación eliminará todo el entorno de producción si el código de canalización le indica que lo haga. Ayude a evitarlo mediante una combinación de solicitudes de incorporación de cambios y reglas de protección de ramas, como la aprobación humana.
conexiones de servicio	Compartido	Configure Azure DevOps para restringir el acceso a estas credenciales.
Recursos de Azure	Compartido	Configure RBAC en Resource Manager.

Los siguientes conceptos y preguntas son importantes tener en cuenta al diseñar un modelo de gobernanza. Tenga en cuenta los posibles casos de uso de esta organización de ejemplo.

1. Protección de los entornos con directivas de rama

Dado que el código fuente define y desencadena implementaciones, la primera línea de defensa es proteger el repositorio de administración de código fuente (SCM). En la práctica, esto se logra mediante el uso del flujo de trabajo de solicitudes de incorporación de cambios en combinación con directivas de rama, que definen comprobaciones y requisitos antes de que se pueda aceptar el código.

Al planificar el modelo de gobernanza integral, los usuarios con privilegios (veggies-admins) serán responsables de configurar la protección de la rama. Entre las comprobaciones comunes de protección de rama que se usan para proteger las implementaciones se incluyen:

• Requerir que se pase la compilación de CI. Resulta útil para establecer la calidad del código de línea base, como el linting de código, las pruebas unitarias e incluso comprobaciones de seguridad como exámenes de virus y credenciales.

• Requerir revisión del mismo nivel Haga que otro usuario compruebe que el código funciona según lo previsto. Tenga cuidado adicional cuando se realicen cambios en el código de canalización. Combine con compilaciones de CI para que las revisiones por homólogos sean menos tediosas.

¿Qué ocurre si un desarrollador intenta empujar directamente a producción?

Recuerde que Git es un sistema SCM distribuido. Un desarrollador puede confirmar directamente en su rama production local. Pero cuando Git está configurado correctamente, el servidor Git rechazará automáticamente dicho push. Por ejemplo:

remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "continuous-integration" is expected.
To https://github.com/Azure/devops-governance
 ! [remote rejected] main -> main (protected branch hook declined)
error: failed to push some refs to 'https://github.com/Azure/devops-governance'

Tenga en cuenta que el flujo de trabajo del ejemplo es independiente del proveedor. Las características de protección de rama y solicitud de incorporación de cambios están disponibles en varios proveedores de SCM, incluidos Azure Repos, GitHub y GitLab.

Una vez que el código se haya aceptado en una rama protegida, el servidor de compilación aplicará el siguiente nivel de controles de acceso (como Azure Pipelines).

2. ¿Qué acceso necesitan las entidades de seguridad?

En Azure, una entidad de seguridad puede ser una entidad de seguridad de usuario o una entidad de seguridad no personal, como una entidad de servicio o una identidad administrada. En todos los entornos, las entidades de seguridad deben seguir el principio de privilegios mínimos. Aunque las entidades de seguridad podrían haber ampliado el acceso en entornos de preproducción, los entornos de producción de Azure deberán minimizar los permisos permanentes, lo que favorecerá el acceso Just-In-Time (JIT) y el acceso condicional de Microsoft Entra. Diseñe las asignaciones de roles de RBAC de Azure para que las entidades de seguridad de usuario se alineen con estos principios de privilegios mínimos.

También es importante modelar RBAC de Azure de forma distinta a RBAC de Azure DevOps. El propósito de la canalización es minimizar el acceso directo a Azure. Excepto en casos especiales, como la innovación, el aprendizaje y la resolución de problemas, la mayoría de las interacciones con Azure deben realizarse a través de canalizaciones diseñadas y controladas específicamente.

Para las entidades de servicio de la canalización de Azure, considere la posibilidad de usar un rol personalizado que impida quitar bloqueos de recursos y realizar otras acciones destructivas fuera del ámbito de su propósito.

3. Creación de un rol personalizado para la entidad de servicio que se usa para acceder a producción

Es un error común conceder permisos y roles de propietario a los agentes de compilación de CI/CD. Los permisos de colaborador no son suficientes si la canalización también debe realizar asignaciones de roles de identidad u otras operaciones con privilegios, como la administración de directivas de Key Vault.

Pero un agente de compilación de CI/CD eliminará todo el entorno de producción si se le indica que lo haga. Para evitar cambios destructivos irreversibles, creamos un rol personalizado que:

• Quita las directivas de acceso de Key Vault.
• Quita los bloqueos de administración, que, por naturaleza, deben impedir que se eliminen los recursos (un requisito común en los sectores regulados)

Para ello, creamos un rol personalizado y quitamos las acciones de Microsoft.Authorization/*/Delete.

{
  "Name": "Headless Owner",
  "Description": "Can manage infrastructure.",
  "actions": [
    "*"
  ],
  "notActions": [
    "Microsoft.Authorization/*/Delete"
  ],
  "AssignableScopes": [
    "/subscriptions/{subscriptionId1}",
    "/subscriptions/{subscriptionId2}",
    "/providers/Microsoft.Management/managementGroups/{groupId1}"
  ]
}

Si eso quita demasiados permisos para sus propósitos, consulte la lista completa de la documentación oficial de para las operaciones del proveedor de recursos de Azure y ajuste la definición de roles según sea necesario.

Implementación de este escenario

Este escenario se extiende más allá de Resource Manager. Este es el motivo por el que se usa Terraform, que también nos permite crear entidades de seguridad en Microsoft Entra ID y arrancar Azure DevOps mediante una única herramienta de infraestructura como código.

Para obtener código fuente e instrucciones detalladas, visite el repositorio de GitHub Governance en la demostración de Azure: desde DevOps a ARM.

Precios

Los costos de Azure DevOps dependen del número de usuarios de su organización que requieren acceso, junto con otros factores, como el número de versiones o compilaciones simultáneas necesarias y el número de usuarios. Azure Repos y Azure Pipelines son características del servicio Azure DevOps. Para más información, consulte Precios de Azure DevOps.

En Microsoft Entra ID, el tipo de administración de acceso de grupo necesario para este escenario se proporciona en las ediciones Premium P1 y Premium P2. Los precios de estos planes se calculan por usuario. Para más información, vea Precios de Microsoft Entra.

Colaboradores

Microsoft mantiene este artículo. Originalmente fue escrito por los siguientes colaboradores.

Autor principal:

• Julie Ng | Ingeniero de servicio sénior

Pasos siguientes

• Visite el repositorio de código de este escenario en Demostración de gobernanza en Azure: de DevOps a ARM.
• Revise las Guías de gobernanza en la nube de Cloud Adoption Framework.
• ¿Qué es el control de acceso basado en rol de Azure (RBAC de Azure)?
• Cloud Adoption Framework: administración del acceso a recursos en Azure
• Roles de Azure Resource Manager
  • Propietario (integrado)
  • Colaborador (integrado)
  • Lector (integrado)
  • Rol personalizado
• Grupos de seguridad de Azure DevOps
  • Administradores de proyectos
  • Colaborador
  • Lector