Distribuire un criterio che è possibile correggere all'interno di una sottoscrizione delegata

  • Articolo

Azure Lighthouse consente ai provider di servizi di creare e modificare le definizioni dei criteri in una sottoscrizione delegata. Per distribuire criteri che usano un'attività di correzione( ovvero i criteri con effetto deployIfNotExists o modifica), è necessario creare un'identità gestita nel tenant del cliente. Questa identità gestita può essere usata da Criteri di Azure per distribuire il modello all'interno del criterio. Questo articolo descrive i passaggi necessari per abilitare questo scenario, sia quando si esegue l'onboarding del cliente per Azure Lighthouse che quando si distribuisce il criterio stesso.

Suggerimento

Anche se in questo argomento si fa riferimento a provider di servizi e clienti, le aziende che gestiscono più tenant possono usare gli stessi processi.

Creare un utente che può assegnare ruoli a un'identità gestita nel tenant del cliente

Quando si esegue l'onboarding di un cliente in Azure Lighthouse, si definiscono le autorizzazioni che concedono l'accesso alle risorse delegate nel tenant del cliente. Ogni autorizzazione specifica un principalId che corrisponde a un utente, un gruppo o un'entità servizio di Microsoft Entra nel tenant di gestione e un roleDefinitionId che corrisponde al ruolo predefinito di Azure che verrà concesso.

Per consentire a un principalId di assegnare ruoli a un'identità gestita nel tenant del cliente, è necessario impostare il relativo roleDefinitionId su Accesso utenti Amministrazione istrator. Anche se questo ruolo non è in genere supportato per Azure Lighthouse, può essere usato in questo scenario specifico. La concessione di questo ruolo a questo principalId consente di assegnare ruoli predefiniti specifici alle identità gestite. Questi ruoli sono definiti nella proprietà delegatedRoleDefinitionIds e possono includere qualsiasi ruolo predefinito di Azure supportato, ad eccezione di User Access Amministrazione istrator o Owner.

Dopo aver eseguito l'onboarding del cliente, il principalId creato in questa autorizzazione potrà assegnare questi ruoli predefiniti alle identità gestite nel tenant del cliente. Non avrà altre autorizzazioni normalmente associate al ruolo accesso utente Amministrazione istrator.

Nota

Le assegnazioni di ruolo tra tenant devono essere attualmente eseguite tramite API, non nel portale di Azure.

L'esempio seguente illustra un principalId che avrà il ruolo di Amministratore accesso utenti. Questo utente sarà in grado di assegnare due ruoli predefiniti alle identità gestite nel tenant del cliente: Collaboratore e Collaboratore 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"
    ]
}

Distribuire criteri che è possibile correggere

Dopo aver creato l'utente con le autorizzazioni necessarie, come descritto in precedenza, l'utente può distribuire criteri che usano attività di correzione all'interno delle sottoscrizioni dei clienti delegate.

Si supponga, ad esempio, di voler abilitare la diagnostica nelle risorse di Azure Key Vault nel tenant del cliente, come illustrato in questo esempio. Un utente nel tenant di gestione con le autorizzazioni appropriate (come descritto in precedenza) distribuirà un modello di Azure Resource Manager per abilitare questo scenario.

La creazione dell'assegnazione di criteri da usare con una sottoscrizione delegata deve essere attualmente eseguita tramite API, non nel portale di Azure. In questo caso, apiVersion deve essere impostato su 2019-04-01-preview o versione successiva per includere la nuova proprietà delegatedManagedIdentityResourceId. Questa proprietà consente di includere un'identità gestita che risiede nel tenant del cliente (in una sottoscrizione o in un gruppo di risorse di cui è stato eseguito l'onboarding in Azure Lighthouse).

L'esempio seguente illustra un'assegnazione di ruolo con 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)]"
            }

Suggerimento

È disponibile un esempio simile che dimostra come distribuire un criterio che aggiunge o rimuove un tag (usando l'effetto modify) in una sottoscrizione delegata.

Passaggi successivi