Condividi tramite

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 i criteri che usano una attività di correzione (ovvero criteri con effetto deployIfNotExists o modify), è necessario creare una 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 articolo 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 Amministratore accessi utente. Anche se questo ruolo non è in genere supportato per Azure Lighthouse, può essere usato in questo scenario specifico. La concessione del 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 Amministratore accesso utenti o Proprietario.

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. Nessun'altra autorizzazione normalmente associata al ruolo Amministratore Accesso utenti verrà assegnata a questo cliente.

Nota

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

Questo esempio mostra un principalId con il ruolo 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, l'utente può distribuire criteri che usano attività di correzione all'interno delle sottoscrizioni dei clienti delegate.

Si immagini, ad esempio, di voler abilitare la diagnostica sulle 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 eseguita tramite le API, non nel portale di Azure. Quando si esegue questa operazione, è necessario impostare apiVersion 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