Compartir vía

Aspectos básicos del efecto de las definiciones de Azure Policy

  • Artículo

Cada definición de directiva de Azure Policy tiene una sola effect en su policyRule. Ese effect determina lo que sucede cuando se evalúa la coincidencia de la regla de directiva. Los efectos se comportan de manera diferente si son para un nuevo recurso, un recurso actualizado o un recurso existente.

A continuación se muestran los efectos de definición de Azure Policy admitidos:

Intercambio de efectos

A veces, varios efectos pueden ser válidos para una definición de directiva determinada. A menudo, los parámetros se usan para especificar valores de efecto permitidos (allowedValues) para que una única definición pueda ser más versátil durante la asignación. Sin embargo, es importante tener en cuenta que no todos los efectos son intercambiables. Las propiedades de recursos y la lógica de la regla de directiva pueden determinar si un determinado efecto se considera válido para la definición de directiva. Por ejemplo, las definiciones de directiva con efecto auditIfNotExists requieren otros detalles en la regla de directiva que no son necesarias para las directivas con efecto audit. Los efectos también se comportan de forma diferente. audit directivas evalúan el cumplimiento de un recurso en función de sus propias propiedades, mientras que auditIfNotExists directivas evalúan el cumplimiento de un recurso en función de las propiedades de un recurso secundario o de extensión.

La lista siguiente es una guía general sobre los efectos intercambiables:

  • audit, deny, y modify o append suelen ser intercambiables.
  • auditIfNotExists y deployIfNotExists suelen ser intercambiables.
  • manual no es intercambiable.
  • disabled es intercambiable con cualquier efecto.

Orden de evaluación

La primera evaluación de Azure Policy es para las solicitudes para crear o actualizar un recurso. Azure Policy crea una lista de todas las asignaciones que se aplican al recurso y, a continuación, evalúa el recurso de acuerdo con cada definición. Para un modo de Administrador de recursos Azure Policy procesa algunos de los efectos antes de entregar la solicitud al proveedor de recursos adecuado. Al seguirse este orden se evita que un proveedor de recursos realice un procesamiento innecesario cuando un recurso no cumple con los controles de gobernanza diseñados de Azure Policy. Con un modo de Proveedor de recursos, el proveedor de recursos administra la evaluación y el resultado, e informa a Azure Policy de los resultados.

  • disabled se comprueba primero para determinar si se debe evaluar la regla de directiva.
  • append y modify se evalúan. Dado que cualquiera de ellos podría alterar la solicitud, un cambio realizado podría impedir que se activara un efecto de auditoría o denegación. Estos efectos solo están disponibles con un modo de Administrador de recursos.
  • deny se evalúa a continuación. La evaluación de deny antes de audit impide el doble registro de un recurso no deseado.
  • audit se evalúa.
  • manual se evalúa.
  • auditIfNotExists se evalúa.
  • denyAction se evalúa en último lugar.

Una vez que el proveedor de recursos devuelve un código correcto en una solicitud de modo de Resource Manager, auditIfNotExists y deployIfNotExists evaluar para determinar si se requiere más registro de cumplimiento o acción.

Las solicitudes PATCH que solo modifican los campos relacionados con tags restringen la evaluación de directivas a aquellas que contienen condiciones que inspeccionan campos relacionados con tags.

Definiciones de directivas en capas

Varias asignaciones pueden afectar a un recurso. Estas asignaciones pueden ser del mismo ámbito o de ámbitos diferentes. Cada una de estas asignaciones también es probable que tenga un efecto diferente al definido. La condición y el efecto de cada directiva se evalúan por separado. Por ejemplo:

  • Directiva 1
    • Restringe la ubicación de recursos a westus
    • Se asigna a la suscripción A.
    • Efecto deny.
  • Directiva 2
    • Restringe la ubicación de recursos a eastus
    • Se asigna al grupo de recursos B de la suscripción A.
    • Efecto audit.

Esta configuración produciría el resultado siguiente:

  • Cualquier recurso que ya esté en el grupo de recursos B en eastus es compatible con la directiva 2 y no compatible con la directiva 1
  • Cualquier recurso que ya esté en el grupo de recursos B y que no esté en eastus no es compatible con la directiva 2 ni con la directiva 1 si no está en westus
  • La directiva 1 deniega cualquier nuevo recurso de la suscripción A que no esté en westus
  • Cualquier recurso nuevo en la suscripción A y en el grupo de recursos B en westus se crea y no es compatible con la directiva 2

Si tanto la directiva 1 como la directiva 2 tienen efecto deny, la situación cambia a:

  • Cualquier recurso que ya esté en el grupo de recursos B y no en eastus no es compatible con la directiva 2
  • Cualquier recurso que ya esté en el grupo de recursos B y no en westus no es compatible con la directiva 1
  • La directiva 1 deniega cualquier nuevo recurso de la suscripción A que no esté en westus
  • Cualquier recurso nuevo que esté en el grupo de recursos B de la suscripción A se deniega.

Cada asignación se evalúa individualmente. Por lo tanto, no hay ninguna oportunidad de que un recurso se escape por diferencias en el ámbito. El resultado neto de las definiciones de directivas en capas se considera acumulativo en su mayoría restrictivo. Por ejemplo, si ambas directivas 1 y 2 tuvieran un efecto de deny, un recurso se bloquearía mediante las definiciones de directiva superpuestas y en conflicto. Si aún necesita que el recurso se cree en el ámbito de destino, revise las exclusiones en cada asignación para validar si las asignaciones de directivas adecuadas están incidiendo en los ámbitos adecuados.

Pasos siguientes