Déployer une stratégie pouvant être corrigée dans un abonnement délégué

  • Article

Azure Lighthouse permet aux fournisseurs de services de créer et de modifier des définitions de stratégies au sein d’un abonnement délégué. Pour déployer des stratégies qui utilisent une tâche de correction (autrement dit, des stratégies avec l'effet deployIfNotExists ou modify), vous devez créer une identité managée dans le locataire du client. Cette identité managée peut être utilisée par Azure Policy pour déployer le modèle dans la stratégie. Cet article décrit les étapes à suivre pour activer ce scénario, à la fois quand vous intégrez le client à Azure Lighthouse et quand vous déployez la stratégie elle-même.

Conseil

Même si nous faisons référence aux fournisseurs de services et aux clients dans cette rubrique, les entreprises gérant plusieurs locataires peuvent utiliser les mêmes processus.

Créer un utilisateur qui peut attribuer des rôles à une identité managée dans le locataire du client

Quand vous intégrez un client à Azure Lighthouse, vous définissez les autorisations d'accès aux ressources déléguées dans le locataire du client. Chaque autorisation spécifie un paramètre principalId qui correspond à un utilisateur Microsoft Entra, un groupe ou un principal du service dans le locataire gestionnaire, ainsi qu’un paramètre roleDefinitionId qui correspond au rôle intégré Azure qui sera accordé.

Pour permettre à un principalId d’attribuer des rôles à une identité managée dans le locataire du client, vous devez définir son roleDefinitionId sur Administrateur de l’accès utilisateur. Bien que ce rôle ne soit généralement pas pris en charge pour Azure Lighthouse, il peut être utilisé dans ce scénario spécifique. L’octroi de ce rôle à ce principalId lui permet d’attribuer des rôles intégrés spécifiques à des identités managées. Ces rôles sont définis dans la propriété delegatedRoleDefinitionIds et peuvent inclure n’importe quel rôle intégré, sauf Administrateur de l’accès utilisateur ou Propriétaire.

Une fois le client intégré, le principalId créé dans cette autorisation pourra affecter ces rôles intégrés à des identités managées dans le locataire du client. Il n’aura aucune autre autorisation normalement associée au rôle Administrateur de l’accès utilisateur.

Notes

Les attributions de rôles entre les locataires doivent être effectuées actuellement par le biais d’API, et non dans le portail Azure.

L’exemple ci-dessous montre un principalId qui aura le rôle Administrateur de l’accès utilisateur. Cet utilisateur pourra attribuer deux rôles intégrés à des identités managées dans le locataire du client : Contributeur et Contributeur Log Analytics.

{
    "principalId": "3kl47fff-5655-4779-b726-2cf02b05c7c4",
    "principalIdDisplayName": "Policy Automation Account",
    "roleDefinitionId": "18d7d88d-d35e-4fb5-a5c3-7773c20a72d9",
    "delegatedRoleDefinitionIds": [
         "b24988ac-6180-42a0-ab88-20f7382dd24c",
         "92aaf0da-9dab-42b6-94a3-d43ce8d16293"
    ]
}

Déployer des stratégies pouvant être corrigées

Une fois que vous avez créé l’utilisateur avec les autorisations nécessaires comme indiqué ci-dessus, cet utilisateur peut déployer des stratégies dans les abonnements du client délégué.

Par exemple, supposons que vous vouliez activer les diagnostics sur des ressources Azure Key Vault dans le locataire du client, comme illustré dans cet exemple. Un utilisateur du client gestionnaire disposant des autorisations appropriées (comme décrit ci-dessus) déploierait un modèle Azure Resource Manager pour activer ce scénario.

La création de l’attribution de stratégie à utiliser avec un abonnement délégué doit être effectuée par le biais d’API, et non dans le portail Azure. Dans ce cas, l’apiVersion doit être définie sur 2019-04-01-preview ou ultérieur pour inclure la nouvelle propriété delegatedManagedIdentityResourceId. Cette propriété vous permet d’inclure une identité managée qui réside dans le locataire du client (dans un abonnement ou un groupe de ressources qui a été intégré à Azure Lighthouse).

L’exemple suivant montre une attribution de rôle avec un delegatedManagedIdentityResourceId.

"type": "Microsoft.Authorization/roleAssignments",
            "apiVersion": "2019-04-01-preview",
            "name": "[parameters('rbacGuid')]",
            "dependsOn": [
                "[variables('policyAssignment')]"
            ],
            "properties": {
                "roleDefinitionId": "[concat(subscription().id, '/providers/Microsoft.Authorization/roleDefinitions/', variables('rbacContributor'))]",
                "principalType": "ServicePrincipal",
                "delegatedManagedIdentityResourceId": "[concat(subscription().id, '/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment'))]",
                "principalId": "[toLower(reference(concat('/providers/Microsoft.Authorization/policyAssignments/', variables('policyAssignment')), '2018-05-01', 'Full' ).identity.principalId)]"
            }

Conseil

Un exemple similaire est disponible pour illustrer comment déployer une stratégie qui ajoute ou supprime une balise (à l’aide de l’effet modify) à un abonnement délégué.

Étapes suivantes