Bevilja tjänstens huvudnamn åtkomst till Azure

Slutförd

Ett huvudnamn för tjänsten kan i sig inte göra något i din Azure-miljö. Det är precis som hur en användare inte kan arbeta med dina Azure-resurser om de inte har behörighet att göra det. I den här lektionen får du lära dig hur du auktoriserar tjänstens huvudnamn för att distribuera och konfigurera Azure-resurser, samtidigt som du undviker att bevilja onödiga behörigheter.

Kommentar

Kommandona i den här enheten visas för att illustrera begrepp. Kör inte kommandona än. Du kommer att öva på det du lär dig här snart.

Auktorisering av tjänstens huvudnamn

Hittills har du fokuserat på vad tjänstens huvudnamn är och hur de kan användas för att bevisa identiteten för en pipeline till Microsoft Entra-ID. Det handlar om autentisering.

När Microsoft Entra-ID:t har autentiserat ett huvudnamn för tjänsten blir nästa fråga: vad kan tjänstens huvudnamn göra? Detta är begreppet auktorisering. Det är ansvaret för det rollbaserade RBAC-systemet (Azure Rollbaserad åtkomstkontroll), som ibland kallas identitets- och åtkomsthantering (IAM). Genom att använda Azure RBAC kan du ge tjänstens huvudnamn åtkomst till en specifik resursgrupp, prenumeration eller hanteringsgrupp.

Kommentar

Allt du gör här är att använda Azure RBAC-systemet för att ge åtkomst till att skapa och hantera Azure-resurser, till exempel dina lagringskonton, App Service-plan och virtuella nätverk. Microsoft Entra ID har också ett eget rollsystem, som ibland kallas katalogroller. Du använder dessa roller för att bevilja behörigheter för tjänstens huvudnamn för att hantera Microsoft Entra-ID. Den här modulen diskuterar inte det här ämnet på djupet, men tänk på att termen roll kan användas för båda situationerna i viss dokumentation.

Välj rätt rolltilldelning för din pipeline

En rolltilldelning har tre viktiga delar: vem rollen har tilldelats (tilldelningsmottagaren), vad de kan göra (rollen) och vilken resurs eller vilka resurser rolltilldelningen gäller för (omfånget).

Tilldelad

När du arbetar med ett huvudnamn för tjänsten tilldelar du roller för tjänstens huvudnamn. Du använder tjänstens huvudnamns program-ID för att identifiera rätt tjänsthuvudnamn för den tilldelningsmottagaren.

Roll

Det kan vara lite mer arbete att ta reda på vilken roll som ska tilldelas. I Azure finns det några vanliga roller:

• Läsare, som gör det möjligt för tilldelningsmottagaren att läsa information om resurser men inte ändra eller ta bort dem.
• Deltagare, vilket gör att den tilldelade personen kan skapa resurser och läsa och ändra befintliga resurser. Deltagare kan dock inte ge andra huvudnamn åtkomst till resurser.
• Ägare, vilket ger fullständig kontroll över resurser, inklusive att ge andra huvudnamn åtkomst.

Varning

Du bör endast ge tjänstens huvudnamn de minsta behörigheter som de behöver för att utföra sina jobb. För det mesta är rollen Ägare för tillåtande för en distributionspipeline.

Det finns också många specifika roller som ger åtkomst bara till en delmängd av funktionerna. Du kan också skapa en egen anpassad rolldefinition för att ange den exakta listan över behörigheter som du vill tilldela.

Kommentar

Anpassade rolldefinitioner kan vara ett kraftfullt sätt att bevilja behörigheter för dina Azure-resurser, men de kan vara svåra att arbeta med. Det är inte alltid lätt att avgöra exakt vilka behörigheter du behöver lägga till i en anpassad rolldefinition, och du kan oavsiktligt göra rolldefinitionerna för restriktiva eller för tillåtande. Om du inte är säker på vad du ska göra är det bäst att använda en av de inbyggda rolldefinitionerna i stället. Anpassade rolldefinitioner ligger utanför omfånget för den här modulen.

Omfattning

Du måste bestämma hur brett du tilldelar rollen. Det här beslutet påverkar antalet resurser som tjänstens huvudnamn kan ändra. Vanliga omfång är:

• Enskild resurs: Du kan bevilja åtkomst bara till en specifik resurs. Distributionspipelines använder vanligtvis inte det här omfånget eftersom en pipeline skapar resurser som inte finns ännu eller konfigurerar om flera resurser.
• Resursgrupp: Du kan bevilja åtkomst till alla resurser i en resursgrupp. Deltagare och ägare kan också skapa resurser i gruppen. Det här är ett bra alternativ för många distributionspipelines.
• Prenumeration: Du kan bevilja åtkomst till alla resurser i en prenumeration. Om du har flera program, arbetsbelastningar eller miljöer i en enda prenumeration kan du bevilja behörigheter till prenumerationens omfång. Detta är dock vanligtvis för tillåtande för en distributionspipeline. Du bör i stället överväga att omfångssätta dina rolltilldelningar till resursgrupper, såvida inte själva distributionsarbetsflödet behöver skapa resursgrupper.

Kom ihåg att rolltilldelningar ärvs. Om du tilldelar en roll i en prenumeration har den tilldelade personen åtkomst till varje resursgrupp och resurs i prenumerationen.

Välja rätt rolltilldelning

Nu när du förstår komponenterna i en rolltilldelning kan du bestämma lämpliga värden för dina scenarier. Här följer några allmänna riktlinjer att tänka på:

• Använd den minsta tillåtande roll som du kan. Om pipelinen bara ska distribuera grundläggande Bicep-mallar och inte hanterar rolltilldelningar ska du inte använda rollen Ägare.
• Använd det smalaste omfång som du kan. De flesta pipelines behöver bara distribuera resurser till en resursgrupp, så de bör inte ges rolltilldelningar med prenumerationsomfång.
• För många pipelines är ett bra standardalternativ för en rolltilldelning rollen Deltagare i resursgruppens omfång.
• Tänk på allt din pipeline gör och allt den kan göra i framtiden. Du kan till exempel överväga att skapa en anpassad rolldefinition för din webbplats distributionspipeline och endast bevilja behörigheter för App Service och Application Insights. Nästa månad kan du behöva lägga till ett Azure Cosmos DB-konto i din Bicep-fil, men den anpassade rollen blockerar Azure Cosmos DB-resurser från att skapas. I stället är det ofta bättre att använda en inbyggd roll, eller en kombination av inbyggda roller, för att undvika att behöva ändra dina rolldefinitioner upprepade gånger. Överväg att använda Azure Policy för att framtvinga dina styrningskrav för tillåtna tjänster, SKU:er och platser.
• Testa pipelinen för att kontrollera att rolltilldelningen fungerar.

Blanda och matcha rolltilldelningar

Du kan skapa flera rolltilldelningar som ger olika behörigheter i olika omfång. Du kan till exempel tilldela tjänstens huvudnamn rollen Läsare med ett omfång för hela prenumerationen och sedan separat tilldela samma tjänsthuvudnamn rollen Deltagare för en specifik resursgrupp. När tjänstens huvudnamn försöker arbeta med resursgruppen tillämpas den mer tillåtande tilldelningen.

Arbeta med flera miljöer

Du arbetar förmodligen med flera miljöer, till exempel utvecklings-, test- och produktionsmiljöer för dina program. Resurserna för varje miljö ska distribueras till olika resursgrupper eller prenumerationer.

Du bör skapa separata tjänsthuvudnamn för varje miljö och ge varje huvudnamn för tjänsten den minsta uppsättning behörigheter som krävs för dess distributioner. Var särskilt noga med att undvika att blanda behörigheter för produktionsdistributioner med dem för distributioner till icke-produktionsmiljöer.

Skapa en rolltilldelning för tjänstens huvudnamn

Om du vill skapa en rolltilldelning för tjänstens huvudnamn använder du az role assignment create kommandot . Du måste ange tilldelning, roll och omfång:

az role assignment create \
  --assignee 00001111-aaaa-2222-bbbb-3333cccc4444 \
  --role Contributor \
  --scope "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite" \
  --description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Nu ska vi titta på varje argument:

• --assignee anger tjänstens huvudnamn. För att undvika tvetydighet är det en bra idé att använda program-ID:t.
• --role anger rollen. Om du använder en inbyggd roll kan du ange den med namn. Om du använder en anpassad rolldefinition anger du det fullständiga rolldefinitions-ID:t.
• --scope anger omfånget. Det här är vanligtvis ett resurs-ID för en enskild resurs, en resursgrupp eller en prenumeration.
• --description är en läsbar beskrivning av rolltilldelningen.

Om du vill skapa en rolltilldelning för ett huvudnamn för tjänsten använder du cmdleten New-AzRoleAssignment . Du måste ange tilldelning, roll och omfång:

New-AzRoleAssignment `
  -ApplicationId 00001111-aaaa-2222-bbbb-3333cccc4444 `
  -RoleDefinitionName Contributor `
  -Scope '/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyWebsite' `
  -Description "The deployment pipeline for the company's website needs to be able to create resources within the resource group."

Nu ska vi titta på varje argument:

• -ApplicationId anger tjänstens huvudnamns programregistrerings-ID.
• -RoleDefinitionName anger namnet på en inbyggd roll. Om du använder en anpassad rolldefinition anger du det fullständiga rolldefinitions-ID:t med argumentet -RoleDefinitionId i stället.
• -Scope anger omfånget. Det här är vanligtvis ett resurs-ID för en enskild resurs, en resursgrupp eller en prenumeration.
• -Description är en läsbar beskrivning av rolltilldelningen.

Dricks

Det är en bra idé att ange en motivering för dina rolltilldelningar genom att ange en beskrivning. En beskrivning hjälper alla som granskar rolltilldelningarna senare att förstå deras syfte och förstå hur du bestämde dig för tilldelningen, rollen och omfattningen.

Kommentar

Rolltilldelningar kan ta några minuter att bli aktiva.

Skapa en tjänsthuvudnamn och rolltilldelning i en åtgärd

Du kan också skapa en rolltilldelning samtidigt som du skapar ett huvudnamn för tjänsten. Koden liknar det kommando som du använde för att skapa ett huvudnamn för tjänsten i föregående enheter, men med några ytterligare argument:

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'

Bevilja åtkomst med Bicep

Rolltilldelningar är Azure-resurser. Det innebär att du kan skapa en rolltilldelning med hjälp av Bicep. Du kan göra detta om du initierar dina resursgrupper med Bicep och sedan distribuerar resurserna till resursgruppen med hjälp av ett huvudnamn för tjänsten. Här är ett exempel på en Bicep-definition för rolltilldelningen ovan:

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.'
  }
}

Nu ska vi titta på varje argument:

• name är en unik identifierare för rolltilldelningen. Detta måste vara i form av en globalt unik identifierare (GUID). Det är en bra idé att använda guid() funktionen i Bicep för att skapa ett GUID och använda huvud-ID, rolldefinitions-ID och omfång som startargument för funktionen för att säkerställa att du skapar ett namn som är unikt för varje rolltilldelning.
• principalType ska anges till ServicePrincipal.
• roleDefinitionId är det fullständigt kvalificerade resurs-ID:t för rolldefinitionen som du tilldelar. Oftast arbetar du med inbyggda roller och du hittar rolldefinitions-ID:t i dokumentationen för inbyggda Azure-roller. Rollen Deltagare har till exempel rolldefinitions-ID: t b24988ac-6180-42a0-ab88-20f7382dd24c. När du anger den i Bicep-filen uttrycker du detta med hjälp av ett fullständigt kvalificerat resurs-ID, till exempel /subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/b24988ac-6180-42a0-ab88-20f7382dd24c.
• principalId är tjänstens huvudnamns objekt-ID. Kontrollera att du inte använder program-ID:t eller programregistreringens objekt-ID.
• description är en läsbar beskrivning av rolltilldelningen.