Een service-principal toegang verlenen tot Azure

  • 6 minuten

Een service-principal kan zelf niets doen in uw Azure-omgeving. Het is net zoals hoe een gebruiker niet kan werken met uw Azure-resources, tenzij deze gemachtigd zijn om dit te doen. In deze les leert u hoe u service-principals autoriseert voor het implementeren en configureren van Azure-resources, terwijl u onnodige machtigingen vermijdt.

Notitie

De opdrachten in deze les worden weergegeven om concepten te illustreren. Voer de opdrachten nog niet uit. U oefent wat u hier binnenkort leert.

Autorisatie van service-principal

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

Nadat Microsoft Entra ID een service-principal heeft geverifieerd, wordt de volgende vraag: wat kan deze service-principal 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 service-principal 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, Het 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 service-principals om Microsoft Entra-id te beheren. In deze module wordt dit onderwerp niet uitvoerig besproken, maar houd er rekening mee dat de termrol voor beide situaties in sommige documentatie kan worden gebruikt.

Selecteer de juiste roltoewijzing voor uw pijplijn

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

Gevolmachtigde

Wanneer u met een service-principal werkt, wijst u rollen toe voor die service-principal. U gebruikt de toepassings-id van de service-principal om de juiste service-principal voor die toegewezen gebruiker te identificeren.

Rol

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

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

Let op

U moet alleen service-principals de minimale machtigingen verlenen die ze nodig hebben om hun taken uit te voeren. Meestal is de rol Eigenaar te machtig voor een implementatiepijplijn.

Er zijn ook veel specifieke rollen die alleen toegang bieden tot een subset van functionaliteit. U kunt ook 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 en u kunt per ongeluk de roldefinities te beperkend of te permachtig maken. Als u niet zeker weet wat u moet doen, kunt u beter 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 service-principal kan worden gewijzigd. Veelvoorkomende bereiken zijn:

  • Eén resource: u kunt alleen toegang verlenen tot een specifieke resource. Implementatiepijplijnen gebruiken dit bereik meestal niet omdat een pijplijn 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 implementatiepijplijnen.
  • 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 implementatiepijplijn. U moet in plaats daarvan overwegen om het bereik van uw roltoewijzingen te bepalen voor resourcegroepen, tenzij uw implementatiewerkstroom zelf 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 pijplijn alleen eenvoudige Bicep-sjablonen gaat implementeren en geen roltoewijzingen beheert, gebruikt u de rol Eigenaar niet.
  • Gebruik het smalste bereik dat u kunt gebruiken. De meeste pijplijnen hoeven alleen resources te implementeren in een resourcegroep, zodat ze geen roltoewijzingen binnen het abonnementsbereik mogen krijgen.
  • Voor veel pijplijnen is een goede standaardoptie voor een roltoewijzing de rol Inzender voor het bereik van de resourcegroep.
  • Houd rekening met alles wat uw pijplijn doet en alles wat deze in de toekomst kan doen. U kunt bijvoorbeeld een aangepaste roldefinitie maken voor de implementatiepijplijn van uw website en alleen machtigingen verlenen voor 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 pijplijn 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 service-principal toewijzen aan de rol lezer met een bereik van het hele abonnement en vervolgens afzonderlijk dezelfde service-principal toewijzen als inzender voor een specifieke resourcegroep. Wanneer de service-principal 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 service-principals maken voor elke omgeving en elke service-principal de minimale set machtigingen verlenen die nodig zijn voor de implementaties. Wees vooral voorzichtig met het combineren van machtigingen voor productie-implementaties met die voor implementaties naar niet-productieomgevingen.

Een roltoewijzing maken voor een service-principal

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

az role assignment create \
  --assignee b585b740-942d-44e9-9126-f1181c95d497 \
  --role Contributor \
  --scope "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Laten we elk argument eens bekijken:

  • --assignee geeft de service-principal op. Om dubbelzinnigheid te voorkomen, is het een goed idee om de toepassings-id te gebruiken.
  • --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 voor een service-principal te maken. U moet de toegewezen rol en het bereik opgeven:

New-AzRoleAssignment `
  -ApplicationId b585b740-942d-44e9-9126-f1181c95d497 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Laten we elk argument eens bekijken:

  • -ApplicationId geeft de toepassingsregistratie-id van de service-principal 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.

Een service-principal en roltoewijzing in één bewerking maken

U kunt ook een roltoewijzing maken op hetzelfde moment dat u een service-principal maakt. De code is vergelijkbaar met de opdracht die u hebt gebruikt om een service-principal te maken in de vorige eenheden, maar met een aantal extra argumenten:

az ad sp create-for-rbac \
  --name MyPipeline \
  --role Contributor \
  --scopes "/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite"

$servicePrincipal = New-AzADServicePrincipal `
  -DisplayName MyPipeline `
  -Role Contributor `
  -Scope '/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyWebsite'

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 service-principal. Hier volgt een voorbeeld van een Bicep-definitie voor de bovenstaande roltoewijzing:

resource roleAssignment 'Microsoft.Authorization/roleAssignments@2023-04-01-preview' = {
  name: guid(principalId, roleDefinitionId, resourceGroup().id)
  properties: {
    principalType: 'ServicePrincipal'
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', roleDefinitionId)
    principalId: principalId
    description: 'The deployment pipeline 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 unieke id voor de roltoewijzing. Dit moet de vorm hebben van een GUID (Globally Unique Identifier). Het is een goed idee om de guid() functie in Bicep te gebruiken om een GUID te maken en om de principal-id, roldefinitie-id en het bereik te gebruiken als de seed-argumenten voor de functie om ervoor te zorgen dat u een naam maakt die uniek is voor elke roltoewijzing.
  • principalType moet worden ingesteld op ServicePrincipal.
  • roleDefinitionId is de volledig gekwalificeerde resource-id voor de roldefinitie die u toewijst. Meestal werkt u met ingebouwde rollen en vindt u de roldefinitie-id in de documentatie voor ingebouwde Rollen van Azure. De rol Inzender heeft bijvoorbeeld de roldefinitie-idb24988ac-6180-42a0-ab88-20f7382dd24c. Wanneer u het opgeeft in uw Bicep-bestand, drukt u dit uit met behulp van een volledig gekwalificeerde resource-id, zoals /subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/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.