Comprendre le verrouillage de ressources dans les blueprints Azure

La création d’environnements cohérents à l’échelle n’est vraiment utile que s’il existe un mécanisme pour gérer cette cohérence. Cet article explique le fonctionnement du verrouillage de ressources dans les blueprints Azure. Pour voir un exemple de verrouillage des ressources et d’application d’affectations de refus, consultez le didacticiel relatif à la protection des nouvelles ressources.

Modes et états de verrouillage

Le mode de verrouillage s’applique à l’attribution de blueprint et offre trois options : Ne pas verrouiller, Lecture seule ou Ne pas supprimer. Le mode de verrouillage est configuré durant le déploiement d’artefact au cours d’une attribution de blueprint. Un autre mode de verrouillage peut être défini en mettant à jour l’attribution de blueprint. Les modes de verrouillage ne peuvent cependant pas être modifiés en dehors d’Azure Blueprints.

Les ressources créées par des artefacts dans une attribution de blueprint ont quatre états possibles : Non verrouillé, Lecture seule, Modification/suppression impossible ou Suppression impossible. Chaque type d’artefact peut être en état Non verrouillé. Le tableau suivant permet de déterminer l’état d’une ressource :

Neutralisation des états de verrouillage

Il est généralement possible pour une personne disposant d’un contrôle d’accès en fonction du rôle Azure (Azure RBAC) approprié sur l’abonnement, tel que le rôle « Propriétaire », d’être autorisée à modifier ou supprimer n’importe quelle ressource. Cet accès n’est pas possible quand Azure Blueprints applique un verrouillage dans le cadre d’une affectation déployée. Si l’attribution a été définie avec l’option Lecture seule ou Ne pas supprimer, même le propriétaire de l’abonnement ne peut pas effectuer l’action bloquée sur la ressource protégée.

Cette mesure de sécurité assure la cohérence du blueprint défini et protège l’environnement pour la création duquel il a été conçu contre toute modification ou suppression accidentelle ou programmatique.

Attribuer au niveau du groupe d’administration

La seule option pour empêcher les propriétaires d’abonnements de supprimer une attribution de blueprint consiste à attribuer le blueprint à un groupe d’administration. Dans ce scénario, seuls les propriétaires du groupe d’administration disposent des autorisations nécessaires pour supprimer l’attribution de blueprint.

Pour attribuer le blueprint à un groupe d’administration plutôt qu’à un abonnement, l’appel d’API REST change pour se présenter comme suit :

PUT https://management.azure.com/providers/Microsoft.Management/managementGroups/{assignmentMG}/providers/Microsoft.Blueprint/blueprintAssignments/{assignmentName}?api-version=2018-11-01-preview

Le groupe d’administration défini par {assignmentMG} doit soit se trouver dans la hiérarchie des groupes d’administration, soit être le même groupe d’administration où la définition du blueprint est enregistrée.

Le corps de la demande de l’attribution de blueprint ressemble à ceci :

{
    "identity": {
        "type": "SystemAssigned"
    },
    "location": "eastus",
    "properties": {
        "description": "enforce pre-defined simpleBlueprint to this XXXXXXXX subscription.",
        "blueprintId": "/providers/Microsoft.Management/managementGroups/{blueprintMG}/providers/Microsoft.Blueprint/blueprints/simpleBlueprint",
        "scope": "/subscriptions/{targetSubscriptionId}",
        "parameters": {
            "storageAccountType": {
                "value": "Standard_LRS"
            },
            "costCenter": {
                "value": "Contoso/Online/Shopping/Production"
            },
            "owners": {
                "value": [
                    "johnDoe@contoso.com",
                    "johnsteam@contoso.com"
                ]
            }
        },
        "resourceGroups": {
            "storageRG": {
                "name": "defaultRG",
                "location": "eastus"
            }
        }
    }
}

La principale différence entre ce corps de demande et celui pour l’assignation à un abonnement est la propriété properties.scope. Cette propriété obligatoire doit être définie sur l’abonnement auquel s’applique l’attribution de blueprint. L’abonnement doit être un enfant direct de la hiérarchie de groupes d’administration dans laquelle l’attribution de blueprint est stockée.

Suppression des états de verrouillage

S’il devient nécessaire de modifier ou supprimer une ressource protégée par une attribution, il existe deux manières de procéder.

• En mettant à jour de l’attribution de blueprint en la définissant sur un mode de verrouillage Ne pas verrouiller
• Supprimer l’attribution de blueprint

Une fois l’affectation supprimée, les verrous créés par Azure Blueprints sont supprimés. Cependant, la ressource est conservée et doit être supprimée selon des procédés normaux.

Fonctionnement des verrous de blueprint

Une action de refus de type Refuser les attributions de contrôle d’accès en fonction du rôle Azure est appliquée aux ressources d’artefact lors de l’attribution d’un blueprint si cette attribution a sélectionné l’option Lecture seule ou Ne pas supprimer. L’action de refus est ajoutée par l’identité managée de l’attribution de blueprint, et ne peut être supprimée des ressources d’artefacts que par cette même identité managée. Cette mesure de sécurité a pour effet d’appliquer le mécanisme de verrouillage et d’empêcher la suppression du verrou du blueprint en dehors d’Azure Blueprints.

Propriétés d’affectation de refus de chaque mode :

Exclure un principal d’une affectation de refus

Dans certains scénarios de conception ou de sécurité, il peut être nécessaire d’exclure un principal de l’affectation de refus créée par l’affectation blueprint. Cette étape est effectuée dans l’API REST en ajoutant jusqu’à cinq valeurs au tableau excludedPrincipals de la propriété locks lors de la création de l’attribution. La définition d’attribution suivante est un exemple de corps de demande qui inclut excludedPrincipals :

{
  "identity": {
    "type": "SystemAssigned"
  },
  "location": "eastus",
  "properties": {
    "description": "enforce pre-defined simpleBlueprint to this XXXXXXXX subscription.",
    "blueprintId": "/providers/Microsoft.Management/managementGroups/{mgId}/providers/Microsoft.Blueprint/blueprints/simpleBlueprint",
    "locks": {
        "mode": "AllResourcesDoNotDelete",
        "excludedPrincipals": [
            "7be2f100-3af5-4c15-bcb7-27ee43784a1f",
            "38833b56-194d-420b-90ce-cff578296714"
        ]
    },
    "parameters": {
      "storageAccountType": {
        "value": "Standard_LRS"
      },
      "costCenter": {
        "value": "Contoso/Online/Shopping/Production"
      },
      "owners": {
        "value": [
          "johnDoe@contoso.com",
          "johnsteam@contoso.com"
        ]
      }
    },
    "resourceGroups": {
      "storageRG": {
        "name": "defaultRG",
        "location": "eastus"
      }
    }
  }
}

Exclure une action d’une affectation de refus

À l’instar de l’exclusion d’un principal sur une affectation de refus dans une affectation de blueprint, vous pouvez exclure des Opérations de fournisseur de ressources Azure spécifiques. Dans le bloc properties.locks, au même emplacement que excludedPrincipals, vous pouvez ajouter un excludedActions :

"locks": {
    "mode": "AllResourcesDoNotDelete",
    "excludedPrincipals": [
        "7be2f100-3af5-4c15-bcb7-27ee43784a1f",
        "38833b56-194d-420b-90ce-cff578296714"
    ],
    "excludedActions": [
        "Microsoft.ContainerRegistry/registries/push/write",
        "Microsoft.Authorization/*/read"
    ]
},

Bien que excludedPrincipals doive être explicite, les entrées excludedActions peuvent tirer parti de * pour la correspondance de caractères génériques des opérations de fournisseur de ressources.

Étapes suivantes

• Suivre le didacticiel relatif à la protection des nouvelles ressources.
• En savoir plus sur le cycle de vie des blueprints
• Comprendre comment utiliser les paramètres statiques et dynamiques.
• Apprendre à personnaliser l’ordre de séquencement des blueprints.
• Découvrir comment mettre à jour des affectations existantes.
• Résoudre les problèmes durant l’affectation d’un blueprint en suivant les étapes de dépannage général.