Partekatu honen bidez:

Diseño de flujos de trabajo de Azure Policy as Code

  • Artikulua

A medida que avanza en su recorrido con la gobernanza de la nube, conviene cambiar de la administración manual de cada definición de directiva en Azure Portal o a través de los distintos SDK a un método más fácil de administrar y de repetir a escala empresarial. Dos de los enfoques predominantes para administrar sistemas a escala en la nube son:

  • Infraestructura como código: Práctica de tratar el contenido que define los entornos, desde plantillas de Azure Resource Manager (plantillas de ARM), pasando por definiciones de Azure Policy, hasta Azure Blueprints, como código fuente.
  • DevOps: Unión de personas, procesos y productos para hacer posible la entrega continua de valor a los usuarios finales.

Azure Policy as Code es la combinación de estas ideas. Básicamente, mantenga las definiciones de directivas en el control de código fuente y, cada vez que se realice un cambio, pruebe y valide ese cambio. Sin embargo, eso no debe ser el alcance de la implicación de las directivas con la infraestructura como código ni DevOps.

El paso de validación también debe ser un componente de otros flujos de trabajo de integración continua o implementación continua (CI/CD), como la implementación de un entorno de aplicación o una infraestructura virtual. Al hacer que la validación de Azure Policy sea un componente temprano del proceso de compilación e implementación, los equipos de aplicaciones y operaciones descubren si sus cambios se comportan como se esperaba mucho antes de que sea demasiado tarde y estén intentando implementarlos en producción.

Definiciones e información básica

Antes de entrar en detalles respecto al flujo de trabajo de Azure Policy como código, es importante comprender algunos conceptos fundamentales, entre ellos, cómo crear definiciones de directivas e iniciativas y cómo aprovechar las exenciones en las asignaciones de esas definiciones:

Los nombres de los archivos se corresponden con ciertas partes de las definiciones de directivas o iniciativas y con otros recursos de directivas:

Formato de archivo Contenidos del archivo
policy-v#.json La definición de directiva completa de esa versión
policyset-v#.json Toda la definición de iniciativa de esa versión
policy-v#.parameters.json La parte properties.parameters de la definición de la directiva
policyset-v#.parameters.json La parte properties.parameters de la definición de la iniciativa
policy-v#.rules.json La parte properties.policyRule de la definición de la directiva
policyset-v#.definitions.json La parte properties.policyDefinitions de la definición de la iniciativa
exemptionName.json Exención de directiva dirigida a un recurso o ámbito concreto

Introducción al flujo de trabajo

El flujo de trabajo general recomendado de Azure Policy as Code es similar al de este diagrama:

Diagrama que muestra los cuadros del flujo de trabajo de Azure Policy as Code, que abarcan las fases de creación, pruebas e implementación.

Control de código fuente

Las definiciones de directivas e iniciativas existentes se pueden exportar de distintas formas, por ejemplo, mediante consultas de PowerShell, la CLI o Azure Resource Graph (ARG). El entorno de administración de control de código fuente elegido para almacenar estas definiciones puede ser una de muchas opciones, esto incluye GitHub o Azure DevOps.

Crear y actualizar definiciones de directivas

Las definiciones de directiva se crean mediante JSON y se almacenan en el control de código fuente. Cada directiva tiene su propio conjunto de archivos, como los parámetros, las reglas y los parámetros de entorno, que se deben almacenar en la misma carpeta. La estructura siguiente es una manera recomendada de mantener las definiciones de directiva en el control de código fuente.

.
|
|- policies/  ________________________ # Root folder for policy resources
|  |- policy1/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- assign.<name2>.json _________ # Assignment 2 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- policy2/  ______________________ # Subfolder for a policy
|     |- versions_____________________ # Subfolder for versions of definition
|       |- policy-v#.json _________________ # Policy definition
|       |- policy-v#.parameters.json ______ # Policy definition of parameters
|       |- policy-v#.rules.json ___________ # Policy rule
|     |- assign.<name1>.json _________ # Assignment 1 for this policy definition
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Cuando se agregan una nueva directiva o una nueva versión, o se actualiza una existente, el flujo de trabajo debe actualizar automáticamente la definición de la directiva en Azure. Las pruebas de la definición de la directiva nueva o actualizada se incluyen en un paso posterior.

Creación y actualización de definiciones de iniciativas

Las definiciones de iniciativas también se crean utilizando archivos JSON que deben almacenarse en la misma carpeta que las definiciones de directivas. La definición de la iniciativa requiere que la definición de la directiva ya exista, por lo que no se puede crear ni actualizar hasta que su origen se haya actualizado en el control de código fuente y luego en Azure. La estructura siguiente es una manera recomendada de mantener las definiciones de iniciativa en el control de código fuente:

.
|
|- initiatives/ ______________________ # Root folder for initiatives
|  |- init1/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- assign.<name2>.json _________ # Assignment 2 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
      |- exemptions.<name2>/__________ # Subfolder for exemptions on assignment 2
        | - exemptionName.json________ # Exemption for this particular assignment
|
|  |- init2/ _________________________ # Subfolder for an initiative
|     |- versions ____________________ # Subfolder for versions of initiative
|       |- policyset.json ______________ # Initiative definition
|       |- policyset.definitions.json __ # Initiative list of policies
|       |- policyset.parameters.json ___ # Initiative definition of parameters
|     |- assign.<name1>.json _________ # Assignment 1 for this policy initiative
|     |- exemptions.<name1>/__________ # Subfolder for exemptions on assignment 1
        | - exemptionName.json________ # Exemption for this particular assignment
|

Al igual que con las definiciones de directivas, el flujo de trabajo debe actualizar automáticamente la definición de la iniciativa en Azure cuando se agrega o actualiza una iniciativa existente. Las pruebas de la definición de la iniciativa nueva o actualizada se incluyen en un paso posterior.

Nota:

Se recomienda usar un mecanismo de implementación centralizado, como flujos de trabajo de GitHub o Azure Pipelines para implementar directivas. Esto ayuda a garantizar que solo los recursos de directiva revisados se implementen en su entorno y que se use un mecanismo de implementación gradual y central. Los permisos de escritura en los recursos de directiva se pueden restringir a la identidad usada en la implementación.

Prueba y validación de la definición actualizada

Una vez que la automatización ha tomado las definiciones de directivas o de iniciativas recién creadas o actualizadas, y ha realizado la actualización del objeto en Azure, es el momento de probar los cambios realizados. La directiva o las iniciativas a las que pertenece deben asignarse a los recursos del entorno más alejado de producción. Este entorno suele ser Dev.

Nota:

En este paso, realizamos pruebas de integración de la definición de directiva en su entorno de Azure, lo cual es independiente de la comprobación de la funcionalidad de la definición de directiva que debe producirse durante el proceso de creación de definiciones.

La asignación debe utilizar enforcementMode en disabled para que la creación de recursos y las actualizaciones no se bloqueen, pero que los recursos existentes sigan siendo auditados para el cumplimiento de la definición de directiva actualizada. Incluso con enforcementMode, se recomienda que el ámbito de asignación sea un grupo de recursos o una suscripción específica para validar directivas.

Nota:

Aunque el modo de cumplimiento es útil, no es un sustituto para probar exhaustivamente la definición de una directiva en varias condiciones. La definición de la directiva se debe probar con las llamadas API de REST PUT y PATCH, recursos compatibles y no compatibles, y casos extremos, como una propiedad que falte en el recurso.

Después de implementar la asignación, usa el SDK de Azure Policy, la tarea de evaluación de seguridad y cumplimiento de Azure Pipelines o las consultas de Azure Resource Graph (ARG) (ver ejemplos) para obtener datos de cumplimiento para la nueva asignación. El entorno que se usa para probar las directivas y las asignaciones debe tener recursos con diferentes estados de cumplimiento. Como una buena prueba de unidad para el código, desea probar que los recursos se evalúan como se esperaba, sin falsos positivos ni falsos negativos. Si prueba y valida solo lo que espera, puede haber un impacto inesperado y no identificado de la directiva. Para obtener más información, consulte Evaluación del efecto de una nueva definición de Azure Policy.

Habilitación de tareas de corrección

Si la validación de la asignación cumple las expectativas, el paso siguiente es validar la corrección. Las directivas que usan deployIfNotExists o modify pueden tener una tarea de corrección asociada desencadenada para corregir los recursos de un estado no compatible y llevarlas al cumplimiento.

El primer paso para corregir recursos es conceder a la asignación de directiva la asignación de roles definida en la definición de la directiva. Esta asignación de roles permite que la identidad administrada de la asignación de directivas tenga suficientes derechos para realizar los cambios necesarios para que el recurso sea compatible.

Una vez que la asignación de directiva tiene los derechos adecuados, use el SDK de directivas para desencadenar una tarea de corrección con respecto a un conjunto de recursos que se sabe que no son compatibles. Se deben completar tres pruebas en estas tareas corregidas antes de continuar:

  • Validar que la tarea de corrección se completó correctamente
  • Ejecutar la evaluación de directivas para ver que los resultados de cumplimiento de la directiva se actualicen según lo previsto
  • Ejecutar una prueba unitaria de entorno con los recursos directamente para validar que sus propiedades han cambiado

Probar los resultados de la evaluación de la directiva actualizada y el entorno directamente ofrece la confirmación de que las tareas de corrección cambiaron lo que se esperaba, y que la definición de la directiva vio el cambio de cumplimiento según lo esperado.

Actualizar a asignaciones aplicadas

Una vez completadas todas las validaciones, actualice la asignación para utilizar enforcementMode en enabled. Se recomienda realizar este cambio inicialmente en el mismo entorno alejado de producción. Valide que los efectos deseados se apliquen durante la creación y la actualización de recursos. Una vez que se valida que ese entorno funciona según lo previsto, se debe definir el ámbito del cambio para que incluya el siguiente entorno, y así sucesivamente, hasta que la directiva se implemente en los recursos de producción.

Procesamiento de evaluaciones integradas

El flujo de trabajo general de Azure Policy as Code tiene como finalidad desarrollar e implementar directivas e iniciativas en un entorno a gran escala. Sin embargo, la evaluación de directivas debe formar parte del proceso de implementación de cualquier flujo de trabajo que implemente o cree recursos en Azure, como la implementación de aplicaciones o la ejecución de plantillas de ARM para crear la infraestructura.

En estos casos, una vez que la implementación de la aplicación o infraestructura se ha completado para una suscripción o grupo de recursos de prueba, se debe realizar la evaluación de la directiva para ese ámbito mediante la comprobación de la validación de todas las directivas e iniciativas existentes. Aunque es posible que se configuren como enforcementMode disabled en este entorno, es útil saber pronto si la implementación de una aplicación o infraestructura infringe las definiciones de directivas en un principio. Por lo tanto, esta evaluación de directivas debe ser un paso en esos flujos de trabajo, y hacer fracasar las implementaciones que crean recursos no compatibles.

Revisar

En este artículo se describe el flujo de trabajo general de Azure Policy as Code, así como los casos en los que la evaluación de la directiva debe formar parte de otros flujos de trabajo de implementación. Este flujo de trabajo se puede usar en cualquier entorno que admita pasos con scripts y automatización basada en desencadenadores.

Pasos siguientes