Förstå tjänstens huvudidentiteter
Tjänstens huvudkonton utgör ett sätt att autentisera pipelines, applikationer och mjukvara. I den här enheten får du lära dig varför tjänsternas huvudanvändare är viktiga för distributionspipelines, hur de passar in i Azures säkerhetsmodell och hur de fungerar.
Varför behöver en pipeline autentiseras?
När du distribuerar en Bicep-mall ber du effektivt Azure Resource Manager att skapa eller ändra dina Azure-resurser. I det här exempelscenariot har du skapat en Bicep-mall för att distribuera ditt leksaksföretags webbplats. Bicep-mallen deklarerar resurser som innehåller en Azure App Service-plan, en app och en Application Insights-instans.
När du distribuerar mallen kontrollerar Resource Manager om resurserna finns. Om de inte gör det skapar Resource Manager dem. Om det redan finns någon ser Resource Manager till att konfigurationen matchar den konfiguration som du anger i mallen.
Alla dessa åtgärder kräver behörigheter eftersom de kommer åt och ändrar dina Azure-resurser. De specifika behörigheter som krävs för distributionen beror på vad mallen innehåller. Om du vill distribuera Bicep-exempelmallen för leksaksföretagets webbplats måste du ha följande behörigheter i resursgruppen som du distribuerar till:
- Möjligheten att skapa utplaceringar. Implementeringar anses vara resurser med en typ av
Microsoft.Resources/deployments. - Möjligheten att skapa och ändra App Service-planer och appar.
- Möjligheten att skapa och ändra Application Insights-instanser.
Hittills har du förmodligen distribuerat dina Bicep-mallar själv med hjälp av Azure CLI eller Azure PowerShell. När du använder dessa verktyg använder du normalt ditt eget användarkonto och autentiserar med hjälp av webbläsaren. Detta kallas att använda din egen identitet. När du skickar en distribution verifierar Azure att din identitet har de behörigheter som krävs för att göra vad din Bicep-mall anger.
När du har flyttat till en pipeline måste du använda en annan typ av identitet eftersom själva pipelinen kör distributioner, utan din direkta inblandning.
Typer av säkerhetsprincipaler
Microsoft Entra ID är den tjänst som hanterar identiteter för Azure. Microsoft Entra ID har flera typer av identiteter, som även kallas säkerhetsprincipaler:
- En användare representerar en människa som vanligtvis loggar in interaktivt med hjälp av en webbläsare. Användare har ofta ytterligare säkerhetskontroller att utföra när de loggar in, till exempel multifaktorautentisering (MFA) och villkorsstyrd åtkomst baserat på deras plats eller nätverk.
- En grupp representerar en samling användare. Grupper autentiseras inte direkt, men de är ett bekvämt sätt att tilldela behörigheter till en uppsättning användare tillsammans.
- Ett tjänstens huvudnamn representerar en automatiserad process eller ett system som vanligtvis inte har en människa som kör den direkt.
- En hanterad identitet är en särskild typ av tjänstehuvudnamn som är utformat för situationer där en människa inte är involverad i autentiseringsprocessen.
Tjänstens huvudnamn
Ett huvudnamn för tjänsten är en typ av konto. Det kan logga in på Microsoft Entra-ID, men det finns ingen människa som kan logga in och interagera med autentiseringsprocessen. Tjänstens huvudprinciper har inte MFA eller liknande skydd, eftersom dessa kräver att en person gör något för att bevisa sin identitet.
I Microsoft Entra-ID identifieras tjänstens huvudnamn av ett program-ID och en autentiseringsuppgift. Program-ID:t är ett globalt unikt ID (GUID). För pipelines är autentiseringsuppgifterna vanligtvis ett starkt lösenord som kallas nyckel. Du kan också använda ett certifikat som autentiseringsuppgifter.
Hanterade identiteter
Till skillnad från andra typer av tjänsthuvudnamn kräver en hanterad identitet inte att du känner till eller underhåller dess autentiseringsuppgifter. En hanterad identitet är associerad med en Azure-resurs. Azure hanterar autentiseringsuppgifterna automatiskt. När resursen behöver komma åt något loggar Azure automatiskt in med hjälp av autentiseringsuppgifterna.
Hanterade identiteter är tillgängliga för Azure-hostade resurser som virtuella datorer och App Service-program. De är ett bra sätt för Azure-resurser att autentisera sig själva för situationer som att automatisera din Azure-hantering, ansluta till databaser och läsa hemliga data från Azure Key Vault. Du kan också använda hanterade identiteter med Azure Arc för andra scenarier.
När du arbetar med pipelines kan du vanligtvis inte använda hanterade identiteter. Det beror på att hanterade identiteter kräver att du äger och hanterar de Azure-resurser som kör dina distributioner. När du arbetar med Azure Pipelines förlitar du dig vanligtvis på delad infrastruktur som tillhandahålls av Microsoft.
Obs
Det finns vissa situationer där pipeliner kan använda hanterade identiteter. I Azure Pipelines kan du skapa en lokalt installerad agent för att köra pipelinens skript och kod på din egen Azure-baserade virtuella dator. Eftersom du äger den virtuella datorn kan du tilldela den en hanterad identitet och använda den från din pipeline.
Men för det mesta körs dina pipelines med hjälp av en värdbaserad agent, som är en server som Microsoft hanterar. Hostingagenter är för närvarande inte kompatibla med hanterade identiteter.
Dricks
I andra delar av lösningen är det bäst att använda en hanterad identitet om du har ett val mellan att använda en hanterad identitet eller att använda ett normalt huvudnamn för tjänsten. De är lättare att arbeta med och är vanligtvis säkrare.
Varför kan du inte bara använda ditt användarkonto?
Du kanske undrar varför du behöver skapa den här helt nya typen av objekt bara för att autentisera en pipeline, när du har användarkonton som fungerar perfekt.
Användarkonton är inte utformade för obevakad användning. Autentiseringsprocessen för ett användarkonto kontrollerar ofta att en människa är den entitet som försöker logga in. Organisationer använder i allt högre grad ytterligare säkerhetskontroller under autentiseringen. Dessa kontroller omfattar MFA, CAPTCHA-kontroller och kontroll av enheten och nätverket som användaren använder så att de kan verifiera legitimiteten för en begäran om inloggning.
Pipelines är utformade för att köra dina distributioner även när ingen aktivt kör dem. Faktum är att de flesta av fördelarna med pipelines kommer från det faktum att de är helt automatiserade och inte kräver mänsklig interaktion. Om du lagrar ditt användarnamn och lösenord i en pipeline och försöker använda dem för att logga in fungerar de förmodligen inte. Även om de verkar fungera kan de enkelt brytas i framtiden om Microsoft Entra-ID eller organisationsadministratören lägger till fler säkerhetskontroller i din användarautentiseringsprocess.
Varning
Det är också en dålig idé att spara ditt användarnamn och lösenord var som helst, eftersom någon annan kan få åtkomst till dem och sedan använda dem för att personifiera dig.
Av dessa skäl tillåter inte de inbyggda pipelineuppgifter som interagerar med Azure att du anger ett användarkontos autentiseringsuppgifter. De kräver att du använder tjänstens huvudnamn.
Hur fungerar tjänstehuvudprinciper?
Du kan se några olika termer som används när du arbetar med tjänstens huvudnamn eller med verktyg som Azure-portalen eller Microsoft Graph-API:et. Även om det inte är viktigt att förstå dessa termer bara för att använda tjänstens huvudnamn i en pipeline, är det bra att veta lite om begreppen.
Tjänsteprincipaler är en funktion av Microsoft Entra ID. Microsoft Entra ID är en global identitetstjänst. Många företag använder Microsoft Entra-ID och varje företag kallas för en klientorganisation.
Microsoft Entra-ID har ett begrepp för ett -program, som representerar ett system, programvara, en process eller någon annan icke-mänsklig agent. Du kan se en distributionspipeline som ett program.
I Microsoft Entra-ID kan program göra många saker som ligger utanför omfånget för autentiserings- och pipelinedistributioner. När du skapar ett program och berättar för Microsoft Entra-ID om det skapar du ett objekt som kallas programregistrering. En programregistrering representerar programmet i Microsoft Entra-ID.
Tjänstens huvudnamn och program är nära länkade. När en programregistrering läggs till i en Microsoft Entra-klientorganisation skapas ett huvudnamn för tjänsten objekt i den Microsoft Entra-klientorganisationen. När du tittar på ett huvudnamn för tjänsten i Azure-portalen ser du många andra funktioner och konfigurationer som kanske inte verkar relevanta. Mycket av detta beror på att tjänstens huvudnamn är länkade till program.
När du skapar ett huvudnamn för tjänsten skapar de flesta av de verktyg som du använder även en programregistrering samtidigt. Du kanske inte märker att det finns två olika objekt.
En typ av tjänstehuvudnamn är inte kopplad till en programregistrering: en hanterad identitet. Som tidigare nämnts hanterar Azure konfigurationen och autentiseringsuppgifterna för en hanterad identitet.
Not
Ett huvudnamn för tjänsten kallas ibland för ett företagsprogram. Vissa verktyg använder det ena namnet och andra verktyg använder det andra. Du kan också se tjänsthuvudnamn som kallas hanterade program i din lokala katalog, men dessa är inte samma sak som hanterade identiteter.
När du skapar ett huvudnamn för tjänsten skapar du först en programregistrering och sedan skapar du ett huvudnamn för tjänsten som programregistreringen ska använda. De flesta av de verktyg som du arbetar med kommer att göra detta åt dig, så du är inte ens medveten om det. Du kanske inte använder alla funktioner i Microsoft Entra-program när du arbetar med distributionspipelines. Men eftersom tjänstens huvudnamn är relaterade till program gäller samma Microsoft Entra-objektstruktur.