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

Al desarrollar un modelo de gobernanza para la organización, es importante recordar que Azure Resource Manager es solo una manera de administrar los recursos. Azure DevOps y la automatización de la integración continua y entrega continua (CI/CD) pueden ser una puerta trasera de seguridad involuntaria si no están protegidos correctamente. Estos recursos se deben proteger 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 descrita aquí usa Azure DevOps, pero también se mencionan brevemente las alternativas.

Posibles casos de uso

Esta implementación y demostración de referencia es de código abierto y está pensada para usarse como una herramienta de enseñanza para las organizaciones que son nuevas en DevOps y necesitan crear un modelo de gobernanza para la implementación en Azure. Lea detenidamente este escenario para comprender las decisiones que hay detrás del modelo que se usa en este repositorio de ejemplo.

Cualquier modelo de gobernanza debe estar vinculado a las reglas de negocio de la organización, que se reflejan en cualquier implementación técnica de los controles de acceso. Este modelo de ejemplo 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 de negocio verticales, como "frutas" y "verduras", que funcionan en gran medida de forma independiente. En cada dominio de negocio, hay dos niveles o privilegios, que se asignan a los grupos *-admins o *-devs de Microsoft Entra. Esto permite a los desarrolladores ser el destino 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
  Todas las aplicaciones deben 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 empezó con un modelo de proyecto aislado para acelerar el recorrido a la nube. Pero ahora están explorando opciones para acabar con los silos y fomentar la colaboración mediante la creación de los proyectos "colaboración" y "supermercado".

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

Descargue un archivo SVG de este diagrama.

Architecture

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 integral.

Descargue un archivo SVG de esta arquitectura.

Flujo de trabajo

La numeración refleja el orden en que los administradores de TI y los arquitectos empresariales piensan y configuran los 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 usará la misma cuenta de Microsoft Entra tanto para Azure DevOps como para Resource Manager. Los usuarios no se agregan individualmente. En su lugar, la pertenencia se asigna mediante grupos de Microsoft Entra para que se pueda 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 (se describen más adelante en los pasos 4 y 5 de este artículo).
   • Entidades de servicio. Una entidad de servicio explícita 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 está limitado únicamente 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 Resource Manager

   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 Colaborador en el entorno de producción.

   Entidad de seguridad de Microsoft Entra	Entorno de desarrollo (Resource Manager)	Entorno de producción (Resource Manager)
   veggies-devs-group	Propietario	Lector
   veggies-admins-group	Propietario	Propietario
   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 los razonamientos detrás de las asignaciones de roles individuales, consulte la sección de 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 se asignan al grupo de seguridad Administrador de proyecto para obtener permisos elevados, lo que les permite configurar los permisos de seguridad.

   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 -admins y -devs debe ser mutuamente excluyente. De lo contrario, las personas afectadas tendrían menos acceso del esperado en Azure DevOps.

   Nombre del grupo	Rol de Resource Manager	Rol de Azure DevOps
   fruits-all	–	–
   fruits-devs	Colaborador	Colaborador
   fruits-admins	Propietario	Project Administrators
   veggies-all	–	–
   veggies-devs	Colaborador	Colaborador
   veggies-admins	Propietario	Project Administrators
   infra-all	–	–
   infra-devs	Colaborador	Colaborador
   infra-admins	Propietario	Project Administrators

   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 los razonamientos detrás de las asignaciones de roles individuales, consulte la sección de 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 del proyecto pueden configurar el acceso a este recurso protegido cuando sea necesario; por ejemplo, cuando se requiera 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 vinculadas a ramas mediante controles de rama, es fundamental configurar los permisos para los repositorios de Git y aplicar 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, se puede usar Azure DevOps Server como sustituto en el entorno 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 con opciones como Jenkins y GitLab.

Tanto Azure Repos como GitHub son plataformas que se han creado 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 sólidas funcionalidades de CI/CD.

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

Consideraciones

Para lograr una gobernanza integral en Azure, es importante comprender el perfil de seguridad y permisos de la ruta de acceso desde el equipo del desarrollador a producción. En el siguiente diagrama, se ilustra un flujo de trabajo de CI/CD de línea base con Azure DevOps. El icono de candado rojo indica los permisos de seguridad que debe configurar el usuario. Si no se configuran los permisos o se configuran incorrectamente, las cargas de trabajo serán vulnerables.

Descargue un archivo SVG 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 se extienda también a ambas canalizaciones y al código. A menudo, estas se ejecutan con identidades con privilegios y pueden destruir 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.

Es importante tener en cuenta los siguientes conceptos y preguntas 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 las 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 planear el modelo de gobernanza integral, los usuarios con privilegios (veggies-admins) serán responsables de configurar la protección de rama. Entre las comprobaciones comunes de protección de ramas 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 la revisión por homólogos. Haga otra doble comprobación humana de que el código funciona según lo previsto. Tenga mucho cuidado cuando se realicen cambios en el código de la canalización. Combine con compilaciones de CI para que las revisiones por homólogos sean menos tediosas.

¿Qué ocurre si un desarrollador intenta enviar cambios 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 de Git rechazará automáticamente dicho envío de cambios. 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 aceptado el código en una rama protegida, el servidor de compilación aplicará la siguiente capa de controles de acceso (por ejemplo, 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 que 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 se deben realizar mediante canalizaciones protegidas diseñadas para ese propósito.

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 dice que lo haga. Para evitar cambios destructivos irreversibles, creamos un rol personalizado que:

• Quita 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, se crea un rol personalizado y se quitan las acciones 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 esto elimina demasiados permisos para sus fines, consulte la lista completa en la documentación oficial de 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 el código fuente e instrucciones detalladas, visite el repositorio de GitHub Demostración de gobernanza en Azure: de DevOps a ARM.

Precios

El costo de Azure DevOps dependerá del número de usuarios de la organización que requieran acceso, además de 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 a grupos necesario para este escenario se proporciona en las ediciones P1 Premium y P2 Premium. Los precios de estos niveles se calculan por usuario. Para más información, vea Precios de Microsoft Entra.

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Autor principal:

• Julie Ng | Ingeniera sénior de servicios

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)?
• Plataforma de adopción de la nube: Administración del acceso a recursos de Azure
• Roles de Azure Resource Manager
  • Propietario (integrado)
  • Colaborador (integrado)
  • Lector (integrado)
  • Rol personalizado
• Grupos de seguridad de Azure DevOps
  • Project Administrators
  • Colaborador
  • Lector

Recursos relacionados

• Diseño de una canalización de CI/CD con Azure DevOps
• Cadena de custodia del análisis forense de equipos en Azure
• Implementación y administración híbridas de Azure Arc para clústeres de Kubernetes
• Examinar arquitecturas de Azure: CI/CD