Paramètres de structure de définition Azure Policy

  • Article

Les paramètres permettent de simplifier la gestion des stratégies en réduisant le nombre de définitions de stratégies. Considérez les paramètres comme les champs d’un formulaire : name, address, city, state. Ces paramètres restent toujours les mêmes ; toutefois, leurs valeurs changent en fonction de la personne qui remplit le formulaire. Les paramètres fonctionnent de manière identique durant la création de stratégies. En incluant des paramètres dans une définition de stratégie, vous pouvez réutiliser cette stratégie pour différents scénarios avec des valeurs différentes.

Ajout ou suppression de paramètres

Des paramètres peuvent être ajoutés à une définition existante et attribuée. Le nouveau paramètre doit inclure la propriété defaultValue. Cette propriété empêche les affectations de stratégie ou d’initiative déjà existantes d’être indirectement invalidées.

Les paramètres ne peuvent pas être supprimés d’une définition de stratégie, car il peut y avoir une affectation qui définit la valeur du paramètre, et cette référence serait rompue. Certaines définitions de stratégie intégrées désapprouvent les paramètres à l’aide de métadonnées "deprecated": true, qui masque le paramètre lors de l’affectation de la définition dans le Portail Azure. Bien que cette méthode ne soit pas prise en charge pour les définitions de stratégie personnalisées, une autre option consiste à dupliquer et à créer une définition de stratégie personnalisée sans le paramètre.

Propriétés du paramètre

Un paramètre utilise les propriétés suivantes dans une définition de stratégie :

  • name: Nom de votre paramètre. Utilisé par la fonction de déploiement parameters dans le cadre de la règle de stratégie. Pour plus d’informations, consultez Utilisation d’une valeur de paramètre.
  • type : détermine si le paramètre est un/une string, array, object, boolean, integer, float, ou dateTime.
  • metadata : définit les sous-propriétés utilisées principalement par le portail Azure pour afficher des informations conviviales :
    • description: Explication du rôle du paramètre. Utilisable pour fournir des exemples de valeurs acceptables.
    • displayName: Nom convivial du paramètre visible dans le portail.
    • strongType: (Facultatif) Utilisé lors de l’affectation de la définition de stratégie via le portail. Fournit une liste prenant en compte le contexte. Pour plus d’informations, voir strongType.
    • assignPermissions: (Facultatif) Définissez l’option sur True pour que le portail Azure crée des attributions de rôles lors de l’attribution de stratégie. Cette propriété est utile si vous souhaitez attribuer des autorisations en dehors de l’étendue d’attribution. Il existe une attribution de rôle par définition de rôle dans la stratégie (ou par définition de rôle dans toutes les stratégies de l’initiative). La valeur du paramètre doit être une ressource ou une étendue valide.
    • deprecated: indicateur booléen pour indiquer si un paramètre est déconseillé dans une définition intégrée.
  • defaultValue: (Facultatif) Définit la valeur du paramètre dans une affectation si aucune valeur n’est fournie. Obligatoire lors de la mise à jour d’une définition de stratégie existante qui est affectée. Pour les paramètres de type objet, la valeur doit correspondre au schéma approprié.
  • allowedValues: (Facultatif) Fournit le tableau des valeurs que le paramètre accepte pendant l’attribution.
    • Sensibilité à la casse : les comparaisons de valeurs autorisées respectent la casse lors de l’affectation d’une stratégie, ce qui signifie que les valeurs de paramètre sélectionnées dans l’affectation doivent correspondre à la casse des valeurs dans le tableau allowedValues dans la définition. Toutefois, une fois que les valeurs sont sélectionnées pour l’affectation, l’évaluation des comparaisons de chaînes peut ne pas respecter la casse en fonction de la condition utilisée. Par exemple, si le paramètre spécifie Dev comme valeur d’étiquette autorisée dans une affectation et que cette valeur est comparée à une chaîne d’entrée à l’aide de la condition equals, Azure Policy évalue ultérieurement une valeur d’étiquette de dev comme correspondance, même si elle est en minuscules, car notEquals ne respecte pas la casse.
    • Pour les paramètres de type objet, les valeurs doivent correspondre au schéma approprié.
  • schema : (facultatif) fournit la validation des entrées de paramètres durant l’attribution à l’aide d’un schéma JSON défini automatiquement. Cette propriété est prise en charge uniquement pour les paramètres de type objet. Elle suit l’implémentation de la version du schéma Json.NET de septembre 2019. Vous pouvez en savoir plus sur l’utilisation des schémas en accédant à https://json-schema.org/ et vous pouvez tester les brouillons de schémas en accédant à https://www.jsonschemavalidator.net/.

Exemples de paramètres

Exemple 1

Par exemple, vous pouvez définir une définition de stratégie qui limite les emplacements sur lesquels les ressources peuvent être déployées. Un paramètre pour cette définition de stratégie peut être allowedLocations et utilisé par chaque affectation de la définition de stratégie pour limiter les valeurs acceptées. L’utilisation de strongType permet d’améliorer l’expérience lors de l’affectation via le portail :

"parameters": {
  "allowedLocations": {
    "type": "array",
    "metadata": {
      "description": "The list of allowed locations for resources.",
      "displayName": "Allowed locations",
      "strongType": "location"
    },
    "defaultValue": [
      "westus2"
    ],
    "allowedValues": [
      "eastus2",
      "westus2",
      "westus"
    ]
  }
}

Un exemple d’entrée pour ce paramètre de type tableau (sans strongType) au moment de l’affectation peut être ["westus", "eastus2"].

Exemple 2

Dans un scénario plus avancé, vous pouvez définir une stratégie qui oblige les pods de cluster Kubernetes à utiliser des étiquettes spécifiques. labelSelector est un paramètre qui peut correspondre à cette définition de stratégie. Il est utilisé par chaque affectation de la définition de stratégie pour spécifier les ressources Kubernetes en question en fonction des clés et des valeurs d’étiquette :

"parameters": {
  "labelSelector": {
    "type": "Object",
    "metadata": {
      "displayName": "Kubernetes label selector",
      "description": "Label query to select Kubernetes resources for policy evaluation. An empty label selector matches all Kubernetes resources."
    },
    "defaultValue": {},
    "schema": {
      "description": "A label selector is a label query over a set of resources. The result of matchLabels and matchExpressions are ANDed. An empty label selector matches all resources.",
      "type": "object",
      "properties": {
        "matchLabels": {
          "description": "matchLabels is a map of {key,value} pairs.",
          "type": "object",
          "additionalProperties": {
            "type": "string"
          },
          "minProperties": 1
        },
        "matchExpressions": {
          "description": "matchExpressions is a list of values, a key, and an operator.",
          "type": "array",
          "items": {
            "type": "object",
            "properties": {
              "key": {
                "description": "key is the label key that the selector applies to.",
                "type": "string"
              },
              "operator": {
                "description": "operator represents a key's relationship to a set of values.",
                "type": "string",
                "enum": [
                  "In",
                  "NotIn",
                  "Exists",
                  "DoesNotExist"
                ]
              },
              "values": {
                "description": "values is an array of string values. If the operator is In or NotIn, the values array must be non-empty. If the operator is Exists or DoesNotExist, the values array must be empty.",
                "type": "array",
                "items": {
                  "type": "string"
                }
              }
            },
            "required": [
              "key",
              "operator"
            ],
            "additionalProperties": false
          },
          "minItems": 1
        }
      },
      "additionalProperties": false
    }
  },
}

Voici un exemple d’entrée pour ce paramètre de type objet au moment de l’affectation, au format JSON, validé par le schéma spécifié :

{
  "matchLabels": {
    "poolID": "abc123",
    "nodeGroup": "Group1",
    "region": "southcentralus"
  },
  "matchExpressions": [
    {
      "key": "name",
      "operator": "In",
      "values": [
        "payroll",
        "web"
      ]
    },
    {
      "key": "environment",
      "operator": "NotIn",
      "values": [
        "dev"
      ]
    }
  ]
}

Utiliser une valeur de paramètre

Dans la règle de stratégie, vous référencez des paramètres avec la syntaxe de fonction parameters suivante :

{
  "field": "location",
  "in": "[parameters('allowedLocations')]"
}

Cet exemple fait référence au paramètre allowedLocations qui a été démontré dans les propriétés du paramètre.

strongType

Dans la propriété metadata, vous pouvez utiliser strongType pour fournir une liste d’options à choix multiple dans le Portail Azure. strongType peut être un type de ressource pris en charge ou une valeur autorisée. Pour déterminer si un type de ressource est valide pour strongType, utilisez la commande Get-AzResourceProvider. Le format d’un type de ressourcestrongType est <Resource Provider>/<Resource Type>. Par exemple : Microsoft.Network/virtualNetworks/subnets.

Certains types de ressources non retournés par Get-AzResourceProvider sont pris en charge. Ces types sont les suivants :

  • Microsoft.RecoveryServices/vaults/backupPolicies

En dehors du type de ressource, les valeurs autorisées pour strongType sont les suivantes :

  • location
  • resourceTypes
  • storageSkus
  • vmSKUs
  • existingResourceGroups

Étapes suivantes