Effet modify sur les définitions Azure Policy

L’effet modify permet d’ajouter, de mettre à jour ou de supprimer des propriétés ou des étiquettes sur un abonnement ou une ressource en phase de création ou de mise à jour. Les ressources non conformes existantes peuvent aussi être corrigées avec une tâche de correction. Les affectations de stratégie dont l’effet est défini sur Modify nécessitent une identité managée pour effectuer une correction. Un exemple courant utilisant l’effet modify est la mise à jour d’étiquettes sur des ressources, comme « costCenter ».

Il existe des nuances dans le comportement de modification pour les propriétés de ressource. Découvrez plus d’informations sur les scénarios quand la modification est ignorée.

Une même règle modify peut avoir un nombre quelconque d’opérations. Opérations prises en charge :

• Ajouter, remplacer ou supprimer des balises de ressources. Seules les balises peuvent être supprimées. Pour les étiquettes, mode doit être défini sur indexed dans la stratégie Modify, sauf si la ressource cible est un groupe de ressources.
• Ajouter ou remplacer la valeur du type d’identité managée (identity.type) des machines virtuelles et des groupes de machines virtuelles identiques. Vous ne pouvez modifier identity.type que pour les machines virtuelles ou les groupes de machines virtuelles identiques.
• Ajouter ou remplacer les valeurs de certains alias.
  • Utilisez Get-AzPolicyAlias | Select-Object -ExpandProperty 'Aliases' | Where-Object { $_.DefaultMetadata.Attributes -eq 'Modifiable' } dans Azure PowerShell version 4.6.0 ou ultérieure pour obtenir la liste des alias qui peuvent être utilisés avec modify.

Évaluation Modify

L’évaluation Modify a lieu avant que la requête ne soit traitée par un fournisseur de ressources lors de la création ou de la mise à jour d’une ressource. Les opérations modify sont appliquées au contenu de la requête lorsque la condition if de la règle de stratégie est remplie. Chaque opération modify peut spécifier une condition qui détermine le moment où elle est appliquée.

Lorsqu’un alias est spécifié, des vérifications supplémentaires sont effectuées pour s’assurer que l’opération modify ne modifie pas le contenu de la requête d’une manière qui conduirait le fournisseur de ressources à le rejeter :

• La propriété à laquelle l’alias est mappé est marquée Modifiable dans la version d’API de la requête.
• Le type de jeton dans l’opération modify correspond au type de jeton attendu pour la propriété dans la version d’API de la requête.

Si l’une de ces vérifications échoue, l’évaluation de la stratégie revient au conflictEffect spécifié.

Modification ignorée

Dans certains cas, les opérations de modification sont ignorées lors de l’évaluation :

• Ressources existantes : quand une définition de stratégie utilisant l’effet modify est exécutée dans le cadre d’un cycle d’évaluation, elle n’apporte pas de modifications aux ressources qui existent déjà. Au lieu de cela, elle marque les ressources qui correspondent à la condition if comme non conformes : elles peuvent donc être corrigées via une tâche de correction.
• Non applicable : quand la condition d’une opération dans le tableau operations est évaluée à false, cette opération particulière est ignorée.
• Propriété non modifiable : si un alias spécifié pour une opération n’est pas modifiable dans la version de l’API de la requête, l’évaluation utilise l’effet de conflit. Si l’effet de conflit est défini sur deny, la requête est bloquée. Si l’effet de conflit est défini sur audit, la requête est autorisée, mais l’opération modify est ignorée.
• Propriété non présente : si une propriété n’est pas présente dans la charge utile de la ressource de la requête, la modification peut être ignorée. Dans certains cas, les propriétés modifiables sont imbriquées dans d’autres propriétés et ont un alias comme Microsoft.Storage/storageAccounts/blobServices/deleteRetentionPolicy.enabled. Si la propriété « parent », dans ce cas deleteRetentionPolicy, n’est pas présente dans la requête, la modification est ignorée, car cette propriété est supposée être omise intentionnellement. Pour obtenir un exemple pratique, accédez à la section Exemple de propriété non présente.
• Opération d’identité sur une ressource autre qu’une machine virtuelle ou qu’un groupe de machines virtuelles identiques : quand une opération de modification tente d’ajouter ou de remplacer le champ identity.type sur une ressource autre qu’une machine virtuelle ou qu’un groupe de machines virtuelles identiques, l’évaluation de la stratégie est ignorée de façon à ce que la modification ne soit pas effectuée. Dans ce cas, la ressource est considérée comme non applicable à la stratégie.

Exemple de propriété non présente

La modification des propriétés d’une ressource dépend de la requête d’API et de la charge utile de la ressource mise à jour. La charge utile peut dépendre du client utilisé, comme le portail Azure, et d’autres facteurs tels que le fournisseur de ressources.

Imaginez que vous appliquez une stratégie qui modifie des étiquettes sur une machine virtuelle. Chaque fois que la machine virtuelle est mise à jour, par exemple lors d’un redimensionnement ou des modifications du disque, les étiquettes sont mises à jour en conséquence, quel que soit le contenu de la charge utile de la machine virtuelle. La raison en est que les étiquettes sont indépendantes des propriétés de la machine virtuelle.

Cependant, si vous appliquez une stratégie qui modifie les propriétés d’une machine virtuelle, la modification dépend de la charge utile de la ressource. Si vous tentez de modifier des propriétés qui ne sont pas incluses dans la charge utile de la mise à jour, la modification n’aura pas lieu. Par exemple, cela peut se produire lors de la mise à jour corrective de la propriété assessmentMode d’une machine virtuelle (alias Microsoft.Compute/virtualMachines/osProfile.windowsConfiguration.patchSettings.assessmentMode). La propriété est « imbriquée » : si ses propriétés parentes ne sont pas incluses dans la requête, cette omission est donc supposée intentionnelle et la modification est ignorée. Pour que la modification se produise, la charge utile de la ressource doit contenir ce contexte.

Propriétés de Modify

La propriété details de l’effet modify comporte toutes les sous-propriétés qui définissent les autorisations nécessaires à la correction, ainsi que les operations utilisées pour ajouter, mettre à jour ou supprimer des valeurs d’étiquette.

• roleDefinitionIds (requis)
  • Cette propriété doit inclure un tableau de chaînes qui correspondent aux ID de rôle de contrôle de l’accès en fonction du rôle accessibles par l’abonnement. Pour plus d’informations, consultez Correction - Configurer une définition de stratégie.
  • Le rôle défini doit inclure toutes les opérations accordées au rôle Contributeur.
• conflictEffect (facultatif)
  • Détermine la définition de stratégie « wins » si plusieurs définitions de stratégie modifient la même propriété ou lorsque l’opération modify ne fonctionne pas sur l’alias spécifié.
    • Pour les ressources nouvelles ou mises à jour, la définition de stratégie avec deny est prioritaire. Les définitions de stratégie avec audit ignorent toutes les operations. Si plusieurs définitions de stratégie ont l’effet deny, la demande est refusée pour raison de conflit. Si toutes les définitions de stratégie ont audit, aucune des operations des définitions de stratégie en conflit n’est traitée.
    • Pour les ressources existantes, si plusieurs définitions de stratégie ont l’effet deny, l’état de conformité est Conflit. Si au plus une définition de stratégie a l’effet deny, chaque attribution retourne l’état de conformité Non conforme.
  • Valeurs disponibles : audit, deny, disabled.
  • La valeur par défaut est deny.
• operations (requis)
  • Tableau de toutes les opérations d’étiquette à effectuer sur les ressources correspondantes.
  • Propriétés :
    • operation (requis)
      • Définit l’action à effectuer sur une ressource correspondante. Les options sont : addOrReplace, Add et Remove.
      • Add a le même comportement que l’effet append.
      • Remove n’est pris en charge que pour les balises de ressource.
    • field (requis)
      • Étiquette à ajouter, remplacer ou supprimer. Les noms d’étiquette doivent respecter la même convention de nommage que les autres champs.
    • value (facultatif)
      • Valeur à affecter à l’étiquette.
      • Cette propriété est obligatoire si operation correspond à addOrReplace ou à Add.
    • condition (facultatif)
      • Chaîne contenant une expression de langage Azure Policy avec fonctions de stratégie qui prend la valeur true ou false.
      • Ne prend pas en charge les fonctions de stratégie suivantes : field(), resourceGroup() et subscription().

Opérations Modify

Le tableau de propriétés operations permet de modifier plusieurs étiquettes de différentes façons à partir d’une même définition de stratégie. Chaque opération est constituée des propriétés operation, field et value. La propriété operation détermine ce que fait la tâche de correction aux étiquettes, field détermine l’étiquette qui est modifiée, et value définit le nouveau paramétrage de l’étiquette. L’exemple suivant effectue les modifications de balises suivantes :

• Définit la balise environment sur « Test », même si elle existe déjà avec une autre valeur.
• Supprime l’étiquette TempResource.
• Définit l’étiquette Dept sur le paramètre de stratégie DeptName configuré pour l’attribution de stratégie.

"details": {
  ...
  "operations": [
    {
      "operation": "addOrReplace",
      "field": "tags['environment']",
      "value": "Test"
    },
    {
      "operation": "Remove",
      "field": "tags['TempResource']",
    },
    {
      "operation": "addOrReplace",
      "field": "tags['Dept']",
      "value": "[parameters('DeptName')]"
    }
  ]
}

La propriété operation propose les options suivantes :

Exemples Modify

Exemple 1 : Ajoutez l’étiquette environment et remplacez les étiquettes environment existantes par « Test » :

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "operations": [
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "Test"
      }
    ]
  }
}

Exemple 2 : Supprimez l’étiquette env et ajoutez l’étiquette environment, ou remplacez les étiquettes environment existantes par une valeur paramétrable :

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c"
    ],
    "conflictEffect": "deny",
    "operations": [
      {
        "operation": "Remove",
        "field": "tags['env']"
      },
      {
        "operation": "addOrReplace",
        "field": "tags['environment']",
        "value": "[parameters('tagValue')]"
      }
    ]
  }
}

Exemple 3 : vérifiez qu’aucun compte de stockage n’empêche l’accès public aux blobs. L’opération modify est appliquée uniquement lors de l’évaluation des requêtes avec une version d’API supérieure ou égale à 2019-04-01 :

"then": {
  "effect": "modify",
  "details": {
    "roleDefinitionIds": [
      "/providers/microsoft.authorization/roleDefinitions/17d1049b-9a84-46fb-8f53-869881c3d3ab"
    ],
    "conflictEffect": "audit",
    "operations": [
      {
        "condition": "[greaterOrEquals(requestContext().apiVersion, '2019-04-01')]",
        "operation": "addOrReplace",
        "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess",
        "value": false
      }
    ]
  }
}

Étapes suivantes

• Consultez des exemples à la page Exemples Azure Policy.
• Consultez la Structure de définition Azure Policy.
• Découvrez comment créer des stratégies par programmation.
• Découvrez comment obtenir des données de conformité.
• Découvrez comment corriger des ressources non conformes.
• Passez en revue les groupes d’administration Azure.