Baggrund

En tjenestekonto er en særlig type Google-konto, der er beregnet til at repræsentere en ikke-menneskelig bruger, der skal autentificeres og have tilladelse til at få adgang til data i Google API’er.

Typisk bruges tjenestekonti i scenarier som:

• Kørsel af arbejdsbelastninger på virtuelle maskiner (VM’er)
• Kørsel af arbejdsbelastninger på arbejdsstationer eller datacentre på stedet, der kalderGoogle API’er.
• Kørsel af arbejdsbelastninger, der ikke er bundet til en menneskelig brugers livscyklus.

Din applikation antager tjenestekontoen identitet for at kalde Google API’er, så brugerne ikke er direkte involveret.

Håndtering af tjenestekonti

Når du har besluttet, at du har brug for en tjenestekonto, kan du stille dig selv følgende spørgsmål for at forstå, hvordan du vil bruge tjenestekontoen:

• Hvilke ressourcer kan tjenestekontoen få adgang til?
• Hvilke tilladelser har servicekontoen brug for?
• Hvor vil den kode, der antager servicekontoen identitet, blive brugt – i Google Cloud eller i lokalerne?

Brug følgende flowdiagram til at finde svarene på ovenstående spørgsmål:

Bemærk, at servicekonti kan opfattes både som en kilde og som en identitet.

Når du tænker på servicekontoen som en identitet, kan du tildele en rolle til en servicekonto, så den kan få adgang til en ressource (f.eks. et projekt).

Når du tænker på en servicekonto som en ressource, kan du tildele roller til andre brugere for at få adgang til eller administrere den pågældende servicekonto.

Givelse af adgang til servicekonti

Givelse af adgang til en servicekonto for at få adgang til en ressource svarer til at give adgang til en hvilken som helst anden identitet. Hvis du f.eks. har et program, der kører på Compute Engine, og du ønsker, at programmet kun skal have adgang til at oprette objekter i Cloud Storage. Du kan oprette en tjenestekonto til programmet og tildele den rollen Storage Object Creator.Følgende diagram illustrerer dette eksempel:

Læs mere omGivelse af roller til alle typer medlemmer, herunder tjenestekonti.

Hold styr på tjenestekonti

Med tiden, efterhånden som du opretter flere og flere tjenestekonti, kan du miste overblikket over, hvilken tjenestekonto der bruges til hvilket formål.

Det viste navn på en tjenestekonto er en god måde at registrere yderligere oplysninger om tjenestekontoen på, f.eks. formålet med tjenestekontoen eller en kontaktperson for kontoen. For nye tjenestekonti kan du udfylde visningsnavnet, når du opretter tjenestekontoen. For eksisterende servicekonti skal du bruge serviceAccounts.update()-metoden til at ændre visningsnavnet.

Identificering af ubrugte servicekonti

Ubrugte servicekonti skaber en unødvendig sikkerhedsrisiko, så vi anbefaler, at du deaktiverer ubrugte servicekonti og derefter sletter servicekontiene, når du er sikker på, at du ikke længere har brug for dem. Du kan bruge følgende metoder til at identificere ubrugte tjenestekonti:

• Indsigt i tjenestekonti fortæller dig, hvilke tjenestekonti i dit projekt der ikke er blevet autentificeret inden for de seneste 90 dage.
• Med målinger for brug af tjenestekonti kan du kontrollere, hvornår en tjenestekonto sidst er blevet brugt.

Sletning og genskabelse af tjenestekonti

Det er muligt at slette en tjenestekonto og derefter oprette en ny tjenestekonto med samme navn.

Når du sletter en tjenestekonto, slettes dens rollebindinger ikke med det samme. I stedet vises tjenestekontoen i rollebindingerne med præfiksetdeleted:. Et eksempel findes under Politikker med slettede medlemmer.

Hvis du opretter en ny tjenestekonto med samme navn som en tjenestekonto, der for nylig er blevet slettet, kan de gamle bindinger stadig eksistere; de gælder dog ikke for den nye tjenestekonto, selv om begge konti har den samme e-mail-adresse. Denne adfærd opstår, fordi tjenestekonti får et unikt ID i Identitets- og adgangsstyring (IAM) ved oprettelsen. Internt tildeles alle rollebindinger ved hjælp af disse ID’er og ikke ved hjælp af tjenestekontoens e-mail-adresse. Derfor gælder eventuelle rollebindinger, der eksisterede for en slettet tjenestekonto, ikke for en ny tjenestekonto, der bruger den samme e-mailadresse.

Sådan er det også, hvis du tilknytter en tjenestekonto til en ressource, derefter sletter tjenestekontoen og opretter en ny tjenestekonto med samme navn, vil den nye tjenestekonto ikke blive knyttet til ressourcen.

For at forhindre denne uventede adfærd skal du overveje at bruge et nyt, unikt navn til alle tjenestekonti. Hvis du ved et uheld sletter en tjenestekonto, kan du også forsøge at slette tjenestekontoen igen i stedet for at oprette en ny tjenestekonto.

Hvis du ikke kan slette den oprindelige tjenestekonto igen, og du skal oprette en ny tjenestekonto med det samme navn og de samme roller, skal du tildele den nye tjenestekonto disse roller. Du kan finde flere oplysninger under Politikker med slettede medlemmer.

Hvis du også skal have den nye tjenestekonto knyttet til de samme ressourcer som den oprindelige tjenestekonto, skal du gøre en af følgende ting:

• For Compute Engine-instanser kan du ændre den tjenestekonto, der er knyttet til instansen, for at erstatte den oprindelige tjenestekonto med den nye tjenestekonto.

For alle andre ressourcer skal du slette den eksisterende ressource og derefter oprette en ny ressource af samme type og tilknytte den nye tjenestekonto.

Godkendelser til tjenestekonti

Dette afsnit beskriver almindelige scenarier for tilladelser, der gives til tjenestekonti eller brugerkonti, der har tilladelse til at udgive sig for tjenestekonti:

• Giv minimumstilladelser til tjenestekonti
• Tjenestekonto-tilladelser for almindelige scenarier

Giv minimumstilladelser til tjenestekonti

Som med alle typer medlemmer bør du kun give tjenestekontoen detminimum af tilladelser, der er nødvendige for at nå dens mål. Få mere at vide om tildeling af roller til alle typer medlemmer, herunder tjenestekonti.

Når du tildeler brugere tilladelser til at få adgang til en tjenestekonto, skal du huske på, at brugeren kan få adgang til alle de ressourcer, som tjenestekontoen har tilladelser til. Derfor er det vigtigt at konfigurere tilladelser til dine tjenestekonti omhyggeligt; det vil sige, at du skal være streng med hensyn til, hvem på dit team der kan fungere som (eller udgive sig for) en tjenestekonto. Vær særlig forsigtig, når du tillader brugere at udgive sig for højt privilegerede tjenestekonti, f.eks. Compute Engine- og App Enginedefault-tjenestekonti.

Brugere med IAM-roller til at opdatere App Engine- og Compute Engine-instanserne (f.eks. App Engine Deployer eller Compute Instance Admin) kan effektivt køre kode som de tjenestekonti, der bruges til at køre disse instanser, og indirekte få adgang til alle de ressourcer, som tjenestekontiene har adgang til. På samme måde kan SSH-adgang til en Compute Engine-instans også give mulighed for at udføre kode som den pågældende instans.

Tjenestekonto-tilladelser til almindelige scenarier

Tjenestekonti kan bruges i mange forskellige scenarier, og hver af dem kræver visse tilladelser. I dette afsnit beskrives almindelige scenarier, og hvilke tilladelser der kræves.

Tilknytning af tjenestekonti til ressourcer

Hvis du vil starte et langvarigt job, der autentificeres som en tjenestekonto, skal du tilknytte en tjenestekonto til den ressource, der skal køre jobbet.

Begrænsninger:

• Begrænsninger til at oprette ressourcen
• iam.serviceAccounts.actAs

For at finde roller, der indeholder disse tilladelser, skal du søge på listen over roller efter tilladelserne.

Der er flere forskellige Google Cloud-ressourcer, der kan køre langkørende job som tjenestekonti. Nogle eksempler på disse ressourcer omfatter:

• Compute Engine VM’er
• App Engine-apps
• Cloud-funktioner

Når du opretter disse ressourcer, har du mulighed for at knytte en servicekonto til dem. Denne tjenestekonto fungerer som ressourcens identitet.

For at oprette en ressource og knytte en tjenestekonto til den skal du have tilladelse til at oprette den pågældende ressource og tilladelse til at udgive dig for den tjenestekonto, som du vil knytte til ressourcen. Tilladelse til at repræsentere tjenestekontoen gives af enhver rolle, der indeholder tilladelsen iam.serviceAccounts.actAs.

Når du har oprettet ressourcen og knyttet en tjenestekonto til den, kan du starte et job, der kører længe, på ressourcen. Jobbet kører som den servicekonto, der er knyttet til ressourcen, og bruger denne servicekonto til at godkende anmodninger tilGoogle Cloud API’er.

For at få mere at vide om at knytte servicekonti til ressourcer skal du seTilknytning af en servicekonto til en ressource.

Direkte udgiver sig for en tjenestekonto

Permissioner:

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

Roller:

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

Når den har fået de nødvendige tilladelser, kan en bruger (eller en tjeneste) direkte udpege (eller hævde) identiteten af en tjenestekonto i nogle få almindelige scenarier.

Først kan brugeren få kortvarige legitimationsoplysninger for tjenestekontoen ved hjælp afiam.serviceAccounts.getAccessToken-tilladelsen og ved at kaldegenerateAccessToken()metoden. Ved at bruge kortvarige legitimationsoplysninger kan en bruger sende kommandoer tilGoogle Cloud og få adgang til alle de ressourcer, som servicekontoen haradgang til. Denne strøm giver f.eks. en bruger mulighed for at bruge gcloud --impersonate-service-accountflaget til at udgive sig for tjenestekontoen uden at kræve brug af en ekstern tjenestekontonøgle, der er downloadet.

For det andet kan brugeren få artefakter signeret af tjenestekontos Google-administrerede private nøgle ved hjælp af iam.serviceAccounts.signBlob-tilladelsen og ved at kalde enten signBlob()eller signJwt()metoden. Den private nøgle, der forvaltes af Google, er altid deponeret og bliver aldrig eksponeret direkte. signBlob() giver mulighed for signering af vilkårlige payloads (f.eks.Cloud Storage-signerede URL’er), mens signJwt() kun giver mulighed for signering af velformede JWT’er.

Finally, the user may impersonate (or assert) the service account without everretrieving a credential for the service account. Dette er et avanceret anvendelsestilfælde og understøttes kun for programadgang ved hjælp afgenerateAccessToken()-metoden. I scenarier med mindst tre servicekonti, nemlig A, B og C: Servicekonto A kan få et adgangstoken til servicekonto C, hvis servicekonto A har fået iam.serviceAccounts.implicitDelegation-tilladelse til B, og B har fået iam.serviceAccounts.getAccessToken-tilladelse til C.

Generering af OpenID Connect (OIDC)-ID-tokens

Permissioner:

• iam.serviceAccounts.getOpenIdToken

Roller:

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

En bruger (eller tjeneste) kan generere et OpenID Connect (OIDC)-kompatibelt JWT-tokens, der er signeret af Google OIDC Provider (konti.google.com), der repræsenterer identiteten af tjenestekontoen ved hjælp af iam.serviceAccounts.getOpenIdTokentilladelsen.

Disse tokens accepteres ikke direkte af de fleste Google API’er, uden at din organisation implementerer yderligere identitetsføderation for at give adgang tilGoogle. Der er nogle få undtagelser – f.eks. Identity-Aware Proxy, som tilladerOIDC-baseret adgang til brugerdrevne programmer.

Generering af eksterne private nøgler

Permissioner:

• iam.serviceAccountKeys.create

Roller:

• roles/editor (Redaktør)
• roles/iam.serviceAccountAdmin (Tjenestekonto-administrator)

En bruger eller tjeneste kan generere eksternt privat nøglemateriale (RSA), der kan bruges til at autentificere direkte til Google som tjenestekonto. Dette nøglemateriale kan derefter bruges med Application Default Credentials (ADC) biblioteker eller med kommandoengcloud auth activate-service-account. Enhver person, der får adgang til nøglematerialet, vil derefter have fuld adgang til alle de ressourcer, som tjenestekontoen har adgang til. Sådant privatnøglemateriale bør behandles med den største forsigtighed og bør betragtes som mindre sikkert, jo længere materialet eksisterer. Derfor er det afgørende at rotere privat nøglemateriale for at opretholde en stærk sikkerhed.

Håndtering af servicekontonøgler

Der findes to typer servicekontonøgler:

• Google Cloud-administrerede nøgler. Disse nøgler bruges af Google Cloudservices, f.eks. App Engine og Compute Engine. De kan ikke downloades, og de roteres automatisk og bruges til signering i højst to uger. Rotationsprocessen er probabilistisk; brugen af den nye nøgle vil gradvist stige og falde i løbet af nøglens levetid. Vi anbefaler, at du gemmer det offentlige nøglesæt for en tjenestekonto i højst 24 timer for at sikre, at du altid har adgang til det aktuelle nøglesæt.

• Brugeradministrerede nøgler. Disse nøgler oprettes, kan downloades og administreres af brugere. Når du sletter dem fra servicekontoen, kan du ikke bruge dem til at godkende dig.

For brugeradministrerede nøgler skal du sikre dig, at du har processer på plads til at opfylde kravene til nøgleadministration, f.eks:

• Nøgleopbevaring
• Nøglefordeling
• Nøgletilbagekaldelse
• Nøgle-rotation
• Beskyttelse af nøglerne mod uautoriserede brugere
• Nøglegendannelse

Alle, der har adgang til en gyldig privat nøgle til en tjenestekonto, vil kunne få adgang til ressourcer via tjenestekontoen. Bemærk, at livscyklussen for nøglens adgang til servicekontoen (og dermed de data, som servicekontoen har adgang til) er uafhængig af livscyklussen for den bruger, der har hentet nøglen.

Afråd altid udviklere fra at checke nøgler ind i kildekoden eller efterlade dem i mappen Downloads på deres arbejdsstation.

For at øge nøglernes sikkerhed skal du følge nedenstående vejledning:

• Brug IAM-tjenestekonto-API’en til automatisk at rotere dine tjenestekontonøgler. Du kan rotere en nøgle ved at oprette en ny nøgle, skifte programmer til at bruge den nye nøgle og derefter slette den gamle nøgle. Brug serviceAccount.keys.create()og serviceAccount.keys.delete()-metoderne sammen for at automatisere rotationen. De Google Cloud-administrerede nøgler roteres ca. én gang om ugen.

  • Brug metoden serviceAccount.keys.list() til at kontrollere servicekonti og nøgler.

Brug af servicekonti med Compute Engine

Compute Engine-instanser skal køre som servicekonti for at have adgang til andre Google Cloud-ressourcer. Hvis du vil sikre, at dine Compute Engine-instanser er mere sikre, skal du overveje følgende:

• Du kan oprette VM’er i det samme projekt med forskellige tjenestekonti. Du kan ændre servicekontoen for en VM, efter at den er oprettet, ved at brugeinstances.setServiceAccountmetoden.

• Du kan tildele IAM-roller til servicekonti for at definere, hvad de kan få adgang til. I mange tilfælde er du ikke længere afhængig af scopes. Dette giver dig den fordel, at du kan ændre tilladelser for enVM’s servicekonto uden at genskabe instansen.

• Da instanser er afhængige af deres servicekonti for at få adgang tilGoogle Cloud-ressourcer, skal du undgå at slette servicekonti, når de stadig bruges af kørende instanser. Hvis du sletter tjenestekontiene, kan instanserne begynde at mislykkes i deres operationer.

Bedste praksis

• Specificer, hvem der kan fungere som tjenestekonti. Brugere, der erService Account Usersfor en servicekonto, kan indirekte få adgang til alle de ressourcer, som servicekontoen har adgang til. Vær derfor forsigtig, når du tildeler en bruger rollenServiceAccountUser.

• Giv kun servicekontoen det minimale sæt tilladelser, der er nødvendige for at nå deres mål. Få mere at vide om tildeling af roller til alle typer medlemmer, herunder tjenestekonti.

• Opret tjenestekonti for hver tjeneste med kun de tilladelser, der er nødvendige for den pågældende tjeneste.

• Brug visningsnavnet på en tjenestekonto til at holde styr på tjenestekontiene. Når du opretter en tjenestekonto, skal du udfylde dens visningsnavn med formålet med tjenestekontoen.

• Detektiver en navnekonvention for dine tjenestekonti.

• Implementer processer til at automatisere rotationen af brugeradministrerede tjenestekontonøgler.

• Tag fordel afIAM-tjenestekonto-API’en til at implementere nøglerotation.

• Gennemgå tjenestekonti og nøgler ved hjælp af entenserviceAccount.keys.list()-metoden eller sidenLogs Viewer i konsollen.

• Slet ikke tjenestekonti, der er i brug af kørende instanser påApp Engine eller Compute Engine, medmindre du ønsker, at disse programmer skal miste adgang til tjenestekontoen.