Bakgrund

Ett tjänstekonto är en särskild typ av Google-konto som är avsett att representera en icke-mänsklig användare som måste autentisera sig och få tillgång till data i Googles API:er.

Typiskt sett används tjänstekonton i scenarier som:

• Körning av arbetsbelastningar på virtuella maskiner.
• Körning av arbetsbelastningar på lokala arbetsstationer eller datacenter som anropar Google API:er.
• Driva arbetsbelastningar som inte är knutna till en mänsklig användares livscykel.

Din applikation antar tjänstekontots identitet för att anropa Googles API:er, så att användarna inte är direkt inblandade.

Hantering av tjänstekonton

När du bestämt dig för att du behöver ett tjänstekonto kan du ställa följande frågor för att förstå hur du ska använda tjänstekontot:

• Vilka resurser kan tjänstekontot komma åt?
• Vilka behörigheter behöver tjänstekontot?
• Var kommer koden som antar tjänstekontots identitet att köra – i Google Cloud eller på plats?

Använd följande flödesschema för att ta reda på svaren på ovanstående frågor:

Observera att tjänstekonton kan betraktas både som en källa och som en identitet.

När du tänker på tjänstekontot som en identitet kan du bevilja en roll till ett tjänstekonto så att det får tillgång till en resurs (t.ex. ett projekt).

När du tänker på ett tjänstekonto som en resurs kan du bevilja roller till andra användare för att få tillgång till eller hantera tjänstekontot.

Givande av åtkomst till tjänstekonton

Givande av åtkomst till ett tjänstekonto för att få åtkomst till en resurs liknar det som att geåtkomst till en annan identitet. Om du till exempel har ett program som körs på Compute Engine och du vill att programmet endast ska ha tillgång till att skapa objekt i Cloud Storage. Du kan skapa ett tjänstekonto för programmet och ge det rollen Storage Object Creator.Följande diagram illustrerar det här exemplet:

Lär dig mer omGivande av roller till alla typer av medlemmar, inklusive tjänstekonton.

Hålla reda på tjänstekonton

När du skapar fler och fler tjänstekonton kan du med tiden förlora kontakten med vilket tjänstekonto som används för vilket ändamål.

Tillhandahållandet av ett tjänstekontos visningsnamn är ett bra sätt att fånga upp ytterligare information om tjänstekontot, till exempel tjänstekontots syfte eller en kontaktperson för kontot. För nya servicekonton kan du fylla i visningsnamnet när du skapar servicekontot. För befintliga tjänstekonton använder du metoden serviceAccounts.update() för att ändra visningsnamnet.

Identifiera oanvända tjänstekonton

Oanvända tjänstekonton skapar en onödig säkerhetsrisk, så vi rekommenderar att du inaktiverar oanvända tjänstekonton och att du raderar tjänstekontona när du är säker på att du inte längre behöver dem. Du kan använda följande metoder för att identifiera oanvända tjänstekonton:

• Tjänstekontoinsikt visar vilka tjänstekonton i ditt projekt som inte har autentiserats under de senaste 90 dagarna.
• Med hjälp av användningsmätningar för tjänstekonton kan du kontrollera när ett tjänstekonto senast användes.

Radera och återskapa tjänstekonton

Det är möjligt att radera ett tjänstekonto och sedan skapa ett nytt tjänstekonto med samma namn.

När du raderar ett tjänstekonto raderas inte dess rollbindningar omedelbart. Istället listar rollbindningarna tjänstekontot med prefixetdeleted:. Ett exempel finns i Principer med raderade medlemmar.

Om du skapar ett nytt tjänstekonto med samma namn som ett nyligen raderat tjänstekonto kan de gamla bindningarna fortfarande finnas kvar, men de kommer inte att gälla för det nya tjänstekontot även om båda kontona har samma e-postadress. Det här beteendet beror på att tjänstekonton får ett unikt ID i Identitets- och åtkomsthantering (IAM) när de skapas. Internt tilldelas alla rollbindningar med hjälp av dessa ID:n, inte med hjälp av tjänstekontots e-postadress. Därför gäller alla rollbindningar som fanns för ett raderat tjänstekonto inte för ett nytt tjänstekonto som använder samma e-postadress.

Och om du ansluter ett tjänstekonto till en resurs, sedan raderar tjänstekontot och skapar ett nytt tjänstekonto med samma namn, kommer det nya tjänstekontot inte att anslutas till resursen.

För att förhindra det här oväntade beteendet bör du överväga att använda ett nytt, unikt namn för varje tjänstekonto. Om du av misstag raderar ett tjänstekonto kan du försöka återställa raderingen av tjänstekontot i stället för att skapa ett nytt tjänstekonto.

Om du inte kan återställa raderingen av det ursprungliga tjänstekontot och du måste skapa ett nytt tjänstekonto med samma namn och samma roller måste du tilldela det nya tjänstekontot dessa roller. Mer information finns iPolicies with deleted members.

Om du också vill att det nya tjänstekontot ska vara kopplat till samma resurser som det ursprungliga tjänstekontot gör du något av följande:

• För Compute Engine-instanser kan du ändra tjänstekontot som är kopplat till instansen så att du ersätter det ursprungliga tjänstekontot med det nya tjänstekontot.
• För alla andra resurser måste du ta bort den befintliga resursen och sedan skapa en ny resurs av samma typ och bifoga det nya tjänstekontot.

Handlingar för tjänstekonton

Det här avsnittet beskriver vanliga scenarier för behörigheter som ges till tjänstekonton, eller användarkonton som har behörighet att utge sig för tjänstekonton:

• Givande av minimala behörigheter till tjänstekonton
• Tjänstekontobehörigheter för vanliga scenarier

Givande av minimala behörigheter till tjänstekonton

Som för alla typer av medlemmar bör du bara ge tjänstekontot denminimala uppsättning behörigheter som krävs för att uppnå dess mål. Läs mer om att tilldela roller till alla typer av medlemmar, inklusive tjänstekonton.

När du beviljar användare behörigheter för åtkomst till ett tjänstekonto ska du tänka på att användaren kan komma åt alla resurser som tjänstekontot har behörigheter för. Därför är det viktigt att konfigurera behörigheter för dina tjänstekonton noggrant, det vill säga att vara strikt när det gäller vem i teamet som kan agera som (eller utge sig för att vara) ett tjänstekonto. Var särskilt försiktig när du tillåter användare att utge sig för att vara mycket privilegierade tjänstekonton, t.ex. Compute Engine- och App Enginedefault-tjänstekonton.

Användare med IAM-roller för att uppdatera App Engine- och Compute Engine-instanserna (t.ex. App Engine Deployer eller Compute Instance Admin) kan i själva verket köra kod i samma form som de tjänstekonton som används för att köra instanserna, och indirekt få åtkomst till alla resurser som tjänstekontona har åtkomst till. På samma sätt kan SSH-åtkomst till en Compute Engine-instans också ge möjlighet att köra kod som den instansen.

Tjänstekonto-behörigheter för vanliga scenarier

Tjänstekonton kan användas i många olika scenarier, och för vart och ett av dem krävs vissa behörigheter. I det här avsnittet beskrivs vanliga scenarier och vilka behörigheter som krävs.

Anslutning av tjänstekonton till resurser

Om du vill starta ett långvarigt jobb som autentiseras som ett tjänstekonto måste du ansluta ett tjänstekonto till den resurs som ska köra jobbet.

Handlingar:

• Handlingar för att skapa resursen
• iam.serviceAccounts.actAs

Om du vill hitta roller som innehåller de här handlingsrättigheterna söker du i listan över roller efter handlingsrättigheterna.

Det finns flera olika Google Cloud-resurser som kan köra långkörande jobb som tjänstekonton. Några exempel på dessa resurser är:

• Compute Engine VMs
• App Engine apps
• Cloud Functions

När du skapar dessa resurser har du möjlighet att bifoga ett tjänstekonto. Det här tjänstekontot fungerar som resursens identitet.

För att skapa en resurs och bifoga ett tjänstekonto måste du ha behörighet att skapa resursen och behörighet att personifiera det tjänstekonto som du kommer att bifoga till resursen. Behörighet att personifiera tjänstekontot ges av alla roller som innehåller behörigheten iam.serviceAccounts.actAs.

När du har skapat resursen och kopplat ett tjänstekonto till den kan du starta ett långvarigt jobb på resursen. Jobbet körs som det tjänstekonto som är kopplat till resursen och använder det tjänstekontot för att auktorisera begäranden till Google Cloud API:er.

Om du vill veta mer om att koppla tjänstekonton till resurser, seKoppla ett tjänstekonto till en resurs.

Direkt utkrävande av ett tjänstekonto

Myndigheter:

• iam.serviceAccounts.getAccessToken
• iam.serviceAccounts.signBlob
• iam.serviceAccounts.signJwt
• iam.serviceAccounts.implicitDelegation

Roller:

• roles/iam.serviceAccountTokenCreator (Service Account Token Creator)

När användaren (eller tjänsten) har fått de nödvändiga behörigheterna kan han eller hon direkt personifiera (eller hävda) identiteten för ett tjänstekonto i några vanliga scenarier.

För det första kan användaren få kortsiktiga autentiseringsuppgifter för tjänstekontot med hjälp av behörigheteniam.serviceAccounts.getAccessToken och genom att anropa metodengenerateAccessToken(). Genom att använda kortsiktiga autentiseringsuppgifter kan en användare utfärda kommandon tillGoogle Cloud och få tillgång till alla resurser som tjänstekontot haråtkomst till. Det här flödet gör det till exempel möjligt för en användare att använda flaggangcloud --impersonate-service-account för att uppträda som tjänstekonto utan att behöva använda en nedladdad extern tjänstekontonyckel.

För det andra kan användaren hämta artefakter som är signerade med tjänstekontots privatnyckel som förvaltas av Google med hjälp av behörigheten iam.serviceAccounts.signBlob och genom att anropa antingen metodensignBlob() ellersignJwt(). Den privata nyckeln som förvaltas av Google hålls alltid i förvar och exponeras aldrig direkt. signBlob() tillåter signering av godtyckliga nyttolaster (t.ex. molnlagersignerade URL:er), medan signJwt() endast tillåter signering av välformade JWT:er.

För det sista kan användaren personifiera (eller hävda) tjänstekontot utan att någonsin hämta en autentiseringsuppgift för tjänstekontot. Detta är ett avancerat användningsfall och stöds endast för programmerad åtkomst med hjälp avgenerateAccessToken()-metoden. I scenarier med minst tre tjänstekonton, nämligen A, B och C, kan tjänstekonto A hämta en åtkomsttoken för tjänstekonto C om tjänstekonto A beviljas behörigheteniam.serviceAccounts.implicitDelegation för B och B beviljas behörigheten iam.serviceAccounts.getAccessToken för C.

Generering av ID-token för OpenID Connect (OIDC)

Handlingar:

• iam.serviceAccounts.getOpenIdToken

Roller:

• roles/iam.serviceAccountTokenCreator (Tjänstekonto Token Creator)

En användare (eller tjänst) kan generera en OpenID Connect (OIDC)-kompatibel JWT-token som är signerad av Google OIDC Provider (konton.google.com) som representerar identiteten hos det tjänstekonto som använder iam.serviceAccounts.getOpenIdTokentillståndet.

Dessa tokens accepteras inte direkt av de flesta av Googles API:er utan att din organisation använder sig av ytterligare identitetsfederation för att ge tillgång till Google. Det finns några få undantag – till exempel Identity-Aware Proxy, som tillåterOIDC-baserad åtkomst till användardrivna program.

Generering av externa privata nycklar

Handlingar:

• iam.serviceAccountKeys.create

Roller:

• roles/editor (Redaktör)
• roles/iam.serviceAccountAdmin (Tjänstekontoadministratör)

En användare eller tjänst kan generera externa privata nycklar (RSA) som kan användas för att autentisera sig direkt till Google som tjänstekonto. Detta nyckelmaterial kan sedan användas med ADC-bibliotek (Application Default Credentials) eller med kommandotgcloud auth activate-service-account. Den som får tillgång till nyckelmaterialet får sedan full tillgång till alla resurser som tjänstekontot har tillgång till. Sådant privat nyckelmaterial bör behandlas med största försiktighet och bör betraktas som mindre säkert ju längre materialet finns kvar. Därför är det viktigt att rotera privat nyckelmaterial för att upprätthålla en stark säkerhet.

Hantering av nycklar för tjänstekonton

Det finns två typer av nycklar för tjänstekonton:

• Google Cloud-hanterade nycklar. Dessa nycklar används av Google Cloudservices som App Engine och Compute Engine. De kan inte laddas ner och roteras automatiskt och används för signering i högst två veckor. Rotationsprocessen är probabilistisk; användningen av den nya nyckeln kommer gradvis att öka och minska under nyckelns livstid. Vi rekommenderar att du lagrar den offentliga nyckeluppsättningen för ett tjänstekonto i högst 24 timmar för att se till att du alltid har tillgång till den aktuella nyckeluppsättningen.

• Användarstyrda nycklar. Dessa nycklar skapas, hämtas och hanteras av användarna. När du har tagit bort dem från tjänstekontot kan du inte använda dem för autentisering.

För användarhanterade nycklar måste du se till att du har processer för att hantera krav på nyckelhantering, till exempel:

• Nyckelförvaring
• Nyckeldistribution
• Nyckelåterkallelse
• Nyckelrotation
• Skydda nycklarna från obehöriga användare
• Nyckelåterställning

Den som har tillgång till en giltig privat nyckel för ett tjänstekonto kommer att kunna få tillgång till resurser via tjänstekontot. Observera att livscykeln för nyckelns tillgång till tjänstekontot (och därmed de data som tjänstekontot har tillgång till) är oberoende av livscykeln för den användare som har laddat ner nyckeln.

Avråda alltid utvecklare från att checka in nycklar i källkoden eller lämna dem i katalogen Downloads på sin arbetsstation.

Följ nedanstående anvisningar för att öka nycklarnas säkerhet:

• Använd IAM:s API för tjänstekonton för att automatiskt rotera nycklarna till dina tjänstekonton. Du kan rotera en nyckel genom att skapa en ny nyckel, byta program för att använda den nya nyckeln och sedan avsluta den gamla nyckeln. Använd metoderna serviceAccount.keys.create()och serviceAccount.keys.delete() tillsammans för att automatisera rotationen. De nycklar som hanteras av Google Cloud roteras ungefär en gång i veckan.

  • Använd metoden serviceAccount.keys.list() för att granska servicekonton och nycklar.

Användning av servicekonton med Compute Engine

Compute Engine-instanser måste köras som servicekonton för att ha åtkomst till andra Google Cloud-resurser. Om du vill se till att dina Compute Engine-instanser är säkrare kan du tänka på följande:

• Du kan skapa virtuella maskiner i samma projekt med olika tjänstekonton. Om du vill ändra servicekontot för en virtuell maskin efter att den har skapats använder du metodeninstances.setServiceAccount.

• Du kan tilldela servicekonton IAM-roller för att definiera vad de har åtkomst till. I många fall behöver du inte längre förlita dig på scopes. Detta ger dig fördelen att kunna ändra behörigheter för en VM:s servicekonto utan att återskapa instansen.

• Då instanser är beroende av sina servicekonton för att få tillgång till Google Cloud-resurser bör du undvika att radera servicekonton när de fortfarande används av pågående instanser. Om du tar bort tjänstekontona kan instanserna börja misslyckas med sin verksamhet.

Bästa praxis

• Specificera vem som kan agera som tjänstekonto. Användare som ärService Account Usersför ett servicekonto kan indirekt få tillgång till alla resurser som servicekontot har tillgång till. Var därför försiktig när du ger en användare rollen ServiceAccountUser.

• Giv servicekontot endast den minsta mängd behörigheter som krävs för att uppnå sitt mål. Lär dig hur man beviljar roller till alla typer av medlemmar, inklusive servicekonton.

• Skapa servicekonton för varje tjänst med endast de behörigheter som krävs för den tjänsten.

• Använd visningsnamnet för ett servicekonto för att hålla reda på servicekontona. När du skapar ett tjänstekonto fyller du dess visningsnamn med syftet med tjänstekontot.

• Definiera en namnkonvention för dina tjänstekonton.

• Inför processer för att automatisera rotationen av användarhanterade tjänstekontonycklar.

• Du kan dra nytta av API:et för tjänstekonton i IAM för att genomföra nyckelrotation.

• Auditera tjänstekonton och nycklar med hjälp av antingen metodenserviceAccount.keys.list() eller sidanLogs Viewer i konsolen.

• Släpp inte tjänstekonton som används av instanser som körs påApp Engine eller Compute Engine om du inte vill att dessa program ska ha tillgång till tjänstekontot.