Een workload-identiteit toegang verlenen tot Azure

  • 6 minuten

Een workloadidentiteit kan op zichzelf niets doen in uw Azure-omgeving, net zoals hoe een gebruiker niet met uw Azure-resources kan werken, tenzij deze gemachtigd zijn om dit te doen. In deze les leert u hoe u workloadidentiteiten kunt autoriseren om Azure-resources te implementeren en te configureren, terwijl u onnodige machtigingen vermijdt.

Autorisatie van workloadidentiteit

Tot nu toe hebt u zich gericht op wat workloadidentiteiten zijn en hoe deze kunnen worden gebruikt om de identiteit van een implementatiewerkstroom aan Microsoft Entra-id te bewijzen. Dit gaat allemaal om verificatie.

Nadat Microsoft Entra ID een workloadidentiteit heeft geverifieerd, wordt de volgende vraag: wat kan deze workloadidentiteit doen? Dit is het concept van autorisatie. Het is de verantwoordelijkheid van het RBAC-systeem (op rollen gebaseerd toegangsbeheer) van Azure, ook wel identiteits- en toegangsbeheer (IAM) genoemd. Met behulp van Azure RBAC kunt u een workloadidentiteit toegang verlenen tot een specifieke resourcegroep, abonnement of beheergroep.

Notitie

Alles wat u hier doet, is het Azure RBAC-systeem gebruiken om toegang te verlenen tot het maken en beheren van Azure-resources, zoals uw opslagaccounts, Azure-app Service-plan en virtuele netwerken. Microsoft Entra ID heeft ook een eigen rolsysteem, dat ook wel directoryrollen wordt genoemd. U gebruikt deze rollen om machtigingen te verlenen voor workloadidentiteiten voor het beheren van De Microsoft Entra-id. In deze module wordt dit onderwerp niet uitvoerig besproken, maar houd er rekening mee dat de termrol wordt gebruikt voor beide situaties in sommige documentatie.

Selecteer de juiste roltoewijzing voor uw werkstroom

Een roltoewijzing heeft drie belangrijke onderdelen: aan wie de rol is toegewezen (de toegewezen gebruiker), wat ze kunnen doen (de rol) en aan welke resource of resources de roltoewijzing van toepassing is (het bereik).

Gevolmachtigde

Wanneer u met een workloadidentiteit werkt, wijst u er rollen voor toe. Als u een rol wilt toewijzen, moet u eerst een service-principal maken, waarmee u uw toepassingsrollen in Azure kunt verlenen. Nadat u de service-principal hebt gemaakt, kunt u doorgaan met de toepassings-id van de toepassingsregistratie van de toepassing.

Als u een service-principal wilt maken, gebruikt u de az ad sp create opdracht en geeft u de app-id van de toepassingsregistratie op:

az ad sp create --id A123b4567c-1234-1a2b-2b1a-1234abc12345

Als u een service-principal wilt maken, gebruikt u de New-AzADServicePrincipal cmdlet en geeft u de app-id van de toepassingsregistratie op:

New-AzADServicePrincipal -AppId A123b4567c-1234-1a2b-2b1a-1234abc12345

Role

Het kan wat meer werk zijn om erachter te komen welke rol moet worden toegewezen. In Azure zijn er enkele algemene rollen:

  • Lezer: hiermee kan de toegewezen persoon informatie over resources lezen, maar deze niet wijzigen of verwijderen.
  • Inzender: Hiermee kan de toegewezen gebruiker resources maken en bestaande resources lezen en wijzigen. Inzenders kunnen echter geen andere principals toegang verlenen tot resources.
  • Eigenaar: hiermee staat u volledige controle over resources toe, waaronder het verlenen van toegang tot andere principals.

Let op

Verdeel workloadidentiteiten alleen de minimale machtigingen die ze nodig hebben om hun taken uit te voeren. In de meeste tijd is de rol Eigenaar te ruim voor een implementatiewerkstroom.

Er zijn ook veel specifieke rollen die toegang bieden tot een subset van functionaliteit. U kunt zelfs uw eigen aangepaste roldefinitie maken om de exacte lijst met machtigingen op te geven die u wilt toewijzen.

Notitie

Aangepaste roldefinities kunnen een krachtige manier zijn om machtigingen te verlenen voor uw Azure-resources, maar ze kunnen lastig zijn om mee te werken. Het is niet altijd eenvoudig om precies te bepalen welke machtigingen u moet toevoegen aan een aangepaste roldefinitie. U kunt per ongeluk de roldefinities te beperkend of te permissief maken.

Als u niet zeker weet wat u moet doen, kunt u het beste een van de ingebouwde roldefinities gebruiken. Aangepaste roldefinities vallen buiten het bereik van deze module.

Bereik

U moet bepalen hoe breed u de rol toewijst. Deze beslissing is van invloed op het aantal resources dat door de workloadidentiteit kan worden gewijzigd. Veelvoorkomende bereiken zijn:

  • Eén resource: u kunt toegang verlenen tot een specifieke resource. Implementatiewerkstromen gebruiken dit bereik meestal niet omdat een werkstroom resources maakt die nog niet bestaan of meerdere resources opnieuw configureert.
  • Resourcegroep: U kunt toegang verlenen tot alle resources binnen een resourcegroep. Inzenders en eigenaren kunnen ook resources binnen de groep maken. Dit is een goede optie voor veel implementatiewerkstromen.
  • Abonnement: U kunt toegang verlenen tot alle resources binnen een abonnement. Als u meerdere toepassingen, workloads of omgevingen in één abonnement hebt, kunt u machtigingen verlenen aan het bereik van het abonnement. Dit is meestal te permissief voor een implementatiewerkstroom. U moet in plaats daarvan overwegen om het bereik van uw roltoewijzingen te bepalen voor resourcegroepen, tenzij uw implementatiewerkstroom resourcegroepen moet maken.

Houd er rekening mee dat roltoewijzingen worden overgenomen. Als u een rol aan een abonnement toewijst, heeft de toegewezen gebruiker toegang tot elke resourcegroep en resource in dat abonnement.

De juiste roltoewijzing selecteren

Nu u de onderdelen van een roltoewijzing begrijpt, kunt u de juiste waarden voor uw scenario's bepalen. Hier volgen enkele algemene richtlijnen om rekening mee te houden:

  • Gebruik de minst permissieve rol die u kunt gebruiken. Als uw werkstroom alleen eenvoudige Bicep-bestanden gaat implementeren en geen roltoewijzingen beheert, gebruikt u de rol Eigenaar niet.

  • Gebruik het smalste bereik dat u kunt gebruiken. De meeste werkstromen hoeven alleen resources te implementeren in een resourcegroep, zodat ze geen roltoewijzingen binnen het abonnementsbereik mogen krijgen.

  • Voor veel werkstromen is een goede standaardoptie voor een roltoewijzing de rol Inzender voor het bereik van de resourcegroep.

  • Houd rekening met alles wat uw werkstroom doet en alles wat deze in de toekomst kan doen. U kunt bijvoorbeeld een aangepaste roldefinitie maken voor de implementatiewerkstroom van uw website en machtigingen verlenen voor alleen App Service en Application Insights. Volgende maand moet u mogelijk een Azure Cosmos DB-account toevoegen aan uw Bicep-bestand, maar de aangepaste rol blokkeert dat Azure Cosmos DB-resources worden gemaakt.

    In plaats daarvan is het vaak beter om een ingebouwde rol of een combinatie van ingebouwde rollen te gebruiken om te voorkomen dat u herhaaldelijk uw roldefinities hoeft te wijzigen. Overweeg het gebruik van Azure Policy om uw governancevereisten af te dwingen voor toegestane services, SKU's en locaties.

  • Test de werkstroom om te controleren of de roltoewijzing werkt.

Roltoewijzingen combineren en vergelijken

U kunt meerdere roltoewijzingen maken die verschillende machtigingen bieden voor verschillende bereiken. U kunt bijvoorbeeld een workloadidentiteit toewijzen aan de rol van Lezer met een bereik van het hele abonnement. U kunt dezelfde workloadidentiteit afzonderlijk toewijzen aan de rol van Inzender voor een specifieke resourcegroep. Wanneer de workloadidentiteit probeert te werken met de resourcegroep, wordt des te meer machtigingen toegewezen.

Werken met meerdere omgevingen

U werkt waarschijnlijk met meerdere omgevingen, zoals ontwikkel-, test- en productieomgevingen voor uw toepassingen. De resources voor elke omgeving moeten worden geïmplementeerd in verschillende resourcegroepen of abonnementen.

U moet afzonderlijke workloadidentiteiten maken voor elke omgeving. Verdeel elke workloadidentiteit de minimale set machtigingen die nodig zijn voor de implementaties. Wees vooral voorzichtig met het combineren van machtigingen voor productie-implementaties met machtigingen voor implementaties in niet-productieomgevingen.

Een roltoewijzing maken voor een workloadidentiteit

Gebruik de az role assignment create opdracht om een roltoewijzing te maken voor een workloadidentiteit. U moet de toegewezen rol en het bereik opgeven:

az role assignment create \
  --assignee A123b4567c-1234-1a2b-2b1a-1234abc12345 \
  --role Contributor \
  --scope "/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite" \
  --description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Laten we elk argument eens bekijken:

  • --assignee hiermee geeft u de workloadidentiteit op. U kunt dit op verschillende manieren opgeven, maar het gebruik van de toepassings-id is een goede gewoonte omdat dubbelzinnigheid wordt voorkomen.
  • --role hiermee geeft u de rol. Als u een ingebouwde rol gebruikt, kunt u deze op naam opgeven. Als u een aangepaste roldefinitie gebruikt, geeft u de volledige roldefinitie-id op.
  • --scope geeft het bereik. Dit is meestal een resource-id voor één resource, een resourcegroep of een abonnement.
  • --description is een door mensen leesbare beschrijving van de roltoewijzing.

Gebruik de New-AzRoleAssignment cmdlet om een roltoewijzing te maken voor een workloadidentiteit. Geef de toegewezen gebruiker, de rol en het bereik op:

New-AzRoleAssignment `
  -ApplicationId A123b4567c-1234-1a2b-2b1a-1234abc12345 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/resourceGroups/ToyWebsite' `
  -Description "The deployment workflow for the company's website needs to be able to create resources within the resource group."

Laten we elk argument eens bekijken:

  • -ApplicationId hiermee geeft u de toepassingsregistratie-id van de workloadidentiteit op.
  • -RoleDefinitionName hiermee geeft u de naam van een ingebouwde rol. Als u een aangepaste roldefinitie gebruikt, geeft u in plaats daarvan de volledige roldefinitie-id op met behulp van het -RoleDefinitionId argument.
  • -Scope geeft het bereik. Dit is meestal een resource-id voor één resource, een resourcegroep of een abonnement.
  • -Description is een door mensen leesbare beschrijving van de roltoewijzing.

Tip

Het is een goede gewoonte om een reden voor uw roltoewijzingen op te geven door een beschrijving op te geven. Een beschrijving helpt iedereen die de roltoewijzingen later bekijkt om het doel ervan te begrijpen en om te begrijpen hoe u hebt besloten over de toegewezen persoon, de rol en het bereik.

Notitie

Het kan enkele minuten duren voordat roltoewijzingen actief zijn.

Toegang verlenen met Bicep

Roltoewijzingen zijn Azure-resources. Dit betekent dat u een roltoewijzing kunt maken met bicep. U kunt dit doen als u uw resourcegroepen initialiseert met Bicep en vervolgens de resources in de resourcegroep implementeert met behulp van een workloadidentiteit. Hier volgt een voorbeeld van een Bicep-definitie voor de voorgaande roltoewijzing:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment workflow for the company\'s website needs to be able to create resources within the resource group.'
  }
}

Laten we elk argument eens bekijken:

  • name is een GUID (Globally Unique Identifier) voor de roltoewijzing. Het is een goede gewoonte om de guid() functie in Bicep te gebruiken om een GUID te maken. Als u ervoor wilt zorgen dat u een naam maakt die uniek is voor elke roltoewijzing, gebruikt u de principal-id, de roldefinitie-id en het bereik als de seed-argumenten voor de functie.

  • principalType moet worden ingesteld op ServicePrincipal.

  • roleDefinitionId is de volledig gekwalificeerde resource-id voor de roldefinitie die u toewijst. U werkt meestal met ingebouwde rollen, zodat u de id van de roldefinitie vindt in de documentatie over ingebouwde Azure-rollen.

    De rol Inzender heeft bijvoorbeeld de roldefinitie-idb24988ac-6180-42a0-ab88-20f7382dd24c. Wanneer u het opgeeft in uw Bicep-bestand, gebruikt u een volledig gekwalificeerde resource-id, zoals /subscriptions/B123a4567c-1234-2b1a-1b2b-11a2b01b2b3c0/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.

  • principalId is de object-id van de service-principal. Zorg ervoor dat u de toepassings-id of de object-id van de toepassingsregistratie niet gebruikt.

  • description is een door mensen leesbare beschrijving van de roltoewijzing.