Achtergrond

Een serviceaccount is een speciaal type Google-account dat is bedoeld om een niet-menselijke gebruiker te vertegenwoordigen die moet worden geverifieerd en geautoriseerd om toegang te krijgen tot gegevens in Google-API’s.

Typisch worden serviceaccounts gebruikt in scenario’s zoals:

• Het uitvoeren van werklasten op virtuele machines (VM’s).
• Het uitvoeren van werklasten op on-premises werkstations of datacenters die Google-API’s aanroepen.
• Werklasten draaien die niet gebonden zijn aan de levenscyclus van een menselijke gebruiker.

Uw applicatie neemt de identiteit van het service account aan om Google API’s aan te roepen, zodat de gebruikers er niet direct bij betrokken zijn.

Beheer service-accounts

Als u eenmaal hebt besloten dat u een service-account nodig hebt, kunt u zichzelf de volgende vragen stellen om te begrijpen hoe u het service-account gaat gebruiken:

• Welke bronnen heeft het service-account toegang?
• Welke machtigingen heeft de serviceaccount nodig?
• Waar zal de code die de identiteit van de serviceaccount aanneemt zich bevinden, op Google Cloud of on-premises?

Gebruik het volgende stroomdiagram om de antwoorden op bovenstaande vragen te achterhalen:

Merk op dat serviceaccounts kunnen worden gezien als zowel een bron als een identiteit.

Wanneer u de service-account als een identiteit beschouwt, kunt u een rol aan de service-account toekennen, waardoor deze toegang krijgt tot een bron (zoals een project).

Wanneer u de service-account als een bron beschouwt, kunt u rollen toekennen aan andere gebruikers om toegang te krijgen tot die service-account of om deze te beheren.

Toegang verlenen tot service-accounts

Toegang verlenen aan een service-account om toegang te krijgen tot een bron is vergelijkbaar met het verlenen van toegang aan elke andere identiteit. Als u bijvoorbeeld een applicatie hebt die op de Compute Engine draait en u wilt dat de applicatie alleen toegang heeft tot het maken van objecten in Cloud Storage. U kunt een serviceaccount maken voor de applicatie en deze de rol Storage Object Creator toekennen. Het volgende diagram illustreert dit voorbeeld:

Lees meerOver het toekennen van rollen aan alle typen leden, inclusief serviceaccounts.

Serviceaccounts bijhouden

Na verloop van tijd, wanneer u steeds meer serviceaccounts maakt, kunt u uit het oog verliezen welke serviceaccount voor welk doel wordt gebruikt.

De weergavenaam van een serviceaccount is een goede manier om extra informatie over de serviceaccount vast te leggen, zoals het doel van de serviceaccount of een contactpersoon voor de account. Voor nieuwe service-accounts kunt u de weergavenaam invullen wanneer u de service-account aanmaakt. Voor bestaande service-accounts gebruikt u de methode serviceAccounts.update() om de weergavenaam te wijzigen.

Niet-gebruikte service-accounts identificeren

Niet-gebruikte service-accounts vormen een onnodig veiligheidsrisico, dus wij raden u aan ongebruikte service-accounts uit te schakelen en de service-accounts te verwijderen als u zeker weet dat u ze niet meer nodig hebt. U kunt de volgende methoden gebruiken om ongebruikte serviceaccounts te identificeren:

• Inzicht in serviceaccounts vertelt u welke serviceaccounts in uw project de afgelopen 90 dagen niet zijn geverifieerd.
• Met de gebruiksmetriek van serviceaccounts kunt u nagaan wanneer een serviceaccount voor het laatst is gebruikt.

Service-accounts verwijderen en opnieuw aanmaken

Het is mogelijk om een service-account te verwijderen en vervolgens een nieuw service-account aan te maken met dezelfde naam.

Wanneer u een service-account verwijdert, worden de rolbindingen niet onmiddellijk verwijderd. In plaats daarvan wordt het serviceaccount in de rolbindingen vermeld met de prefixdeleted:. Zie voor een voorbeeld Beleid met verwijderde leden.

Als u een nieuw serviceaccount aanmaakt met dezelfde naam als een onlangs verwijderd serviceaccount, kunnen de oude bindingen nog steeds bestaan; ze zijn echter niet van toepassing op het nieuwe serviceaccount, ook al hebben beide accounts hetzelfde emailadres. Dit gedrag treedt op omdat service accounts een unieke ID krijgen binnen Identity and Access Management (IAM) bij het aanmaken. Intern worden alle rolbindingen toegekend op basis van deze ID’s, niet op basis van het e-mailadres van het serviceaccount. Daarom zijn rolbindingen die bestonden voor een verwijderd serviceaccount niet van toepassing op een nieuwserviceaccount dat hetzelfde e-mailadres gebruikt.

Ook als u een serviceaccount koppelt aan een resource, vervolgens het serviceaccount verwijdert en een nieuw serviceaccount maakt met dezelfde naam, wordt het nieuwe serviceaccount niet gekoppeld aan de resource.

Om dit onverwachte gedrag te voorkomen, kunt u overwegen een nieuwe, unieke naam te gebruiken voor elk serviceaccount. Als u per ongeluk een serviceaccount verwijdert, kunt u proberen het serviceaccount ongedaan te maken in plaats van een nieuw serviceaccount aan te maken.

Als u het originele serviceaccount niet ongedaan kunt maken en u een nieuw serviceaccount met dezelfde naam en dezelfde rollen moet maken, moet u de rollen aan het nieuwe serviceaccount toekennen. Zie Beleidsregels met verwijderde leden voor meer informatie.

Als u ook wilt dat de nieuwe serviceaccount aan dezelfde resources wordt gekoppeld als de oorspronkelijke serviceaccount, doet u een van de volgende dingen:

• Voor Compute Engine-instanties kunt u de serviceaccount wijzigen die aan de instantie is gekoppeld om de oorspronkelijke serviceaccount te vervangen door de nieuwe serviceaccount.
• Voor alle andere resources moet u de bestaande resource verwijderen, vervolgens een nieuwe resource van hetzelfde type maken en de nieuwe service-account koppelen.

Permissies voor serviceaccounts

Dit gedeelte beschrijft veel voorkomende scenario’s voor permissies die worden toegekend aan serviceaccounts, of gebruikersaccounts die de permissies hebben om zich voor te doen als serviceaccounts:

• Minimale machtigingen voor serviceaccounts
• Machtigingen voor serviceaccounts voor veelvoorkomende scenario’s

Minimale machtigingen voor serviceaccounts

Net als bij alle soorten leden, moet u de serviceaccount alleen de minimale set machtigingen geven die nodig is om zijn doel te bereiken. Meer informatie over het toekennen van rollen aan alle soorten leden, inclusief serviceaccounts.

Bij het toekennen van machtigingen aan gebruikers voor toegang tot een serviceaccount, moet u in gedachten houden dat de gebruiker toegang heeft tot alle bronnen waarvoor de serviceaccount machtigingen heeft. Daarom is het belangrijk om de permissies van uw serviceaccounts zorgvuldig te configureren; dat wil zeggen, wees strikt over wie in uw team kan optreden als (of zich kan voordoen als) een serviceaccount. Wees bijzonder voorzichtig wanneer u gebruikers toestaat zich voor te doen als zeer bevoorrechte serviceaccounts, zoals de standaard serviceaccounts van de Compute Engine en App Eng.

Gebruikers met IAM-rollen voor het bijwerken van de App Engine- en Compute Engine-instances (zoalsApp Engine Deployer of Compute Instance Admin) kunnen in feite code uitvoeren als de serviceaccounts die worden gebruikt om deze instanties te draaien, en indirect toegang krijgen tot alle resources waartoe de serviceaccounts toegang hebben. Op dezelfde manier kan SSH-toegang tot een Compute Engine instance ook de mogelijkheid bieden om code uit te voeren als die instance.

Service-accountmachtigingen voor veelvoorkomende scenario’s

Service-accounts kunnen in veel verschillende scenario’s worden gebruikt, en elk van hen vereist bepaalde machtigingen. In dit gedeelte worden veelvoorkomende scenario’s beschreven en wordt beschreven welke machtigingen vereist zijn.

Serviceaccounts aan bronnen koppelen

Als u een langlopende taak wilt starten die als serviceaccount wordt geverifieerd, moet u een serviceaccount koppelen aan de bron die de taak zal uitvoeren.

Permissies:

• Permissies om de resource te maken
• iam.serviceAccounts.actAs

Om rollen te vinden die deze permissies bevatten, zoekt u in de lijst met rollen naar de permissies.

Er zijn verschillende Google Cloud-bronnen die langlopende taken kunnen uitvoeren als serviceaccounts. Enkele voorbeelden van deze bronnen zijn:

• Compute Engine VM’s
• App Engine apps
• Cloud Functions

Wanneer u deze bronnen maakt, hebt u de optie om er een serviceaccount aan te koppelen. Deze serviceaccount fungeert als de identiteit van de resource.

Om een resource te maken en er een serviceaccount aan te koppelen, hebt u machtigingen nodig om die resource te maken en machtigingen om de serviceaccount die u aan de resource gaat koppelen, te impersoneren. Toestemming om het serviceaccount te impersoneren wordt verleend door elke rol die de iam.serviceAccounts.actAs-toestemming bevat.

Nadat u de resource hebt gemaakt en er een serviceaccount aan hebt gekoppeld, kunt u een langlopende taak op de resource starten. De taak wordt uitgevoerd als het serviceaccount dat aan de bron is gekoppeld, en gebruikt dat serviceaccount om aanvragen voor Google Cloud API’s te autoriseren.

Om meer te weten te komen over het koppelen van serviceaccounts aan bronnen, zieHet koppelen van een serviceaccount aan een bron.

Direct een serviceaccount impersoneren

Permissies:

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

Rollen:

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

Als de vereiste machtigingen zijn toegekend, kan een gebruiker (of dienst) de identiteit van een service-account in enkele veelvoorkomende scenario’s rechtstreeks imiteren (of doen gelden).

Ten eerste kan de gebruiker kortetermijnreferenties voor het serviceaccount krijgen door deiam.serviceAccounts.getAccessToken-toestemming te gebruiken en degenerateAccessToken()-methode aan te roepen. Door kortetermijnreferenties te gebruiken, kan een gebruiker opdrachten geven aan Google Cloud en heeft hij toegang tot alle bronnen waartoe het serviceaccount toegang heeft. Deze stroom stelt een gebruiker bijvoorbeeld in staat om degcloud --impersonate-service-account-vlag te gebruiken om zich voor te doen als het service-account zonder het gebruik van een gedownloade externe service-accountsleutel.

Ten tweede kan de gebruiker artefacten verkrijgen die zijn ondertekend door de door Google beheerde private sleutel van het service-account met behulp van de iam.serviceAccounts.signBlob-toestemming en door ofwel de methodesignBlob() ofsignJwt() aan te roepen. De door Google beheerde privésleutel wordt altijd in escrow gehouden en wordt nooit direct openbaar gemaakt. signBlob() maakt het mogelijk om willekeurige payloads te ondertekenen (zoals Cloud Storage-ondertekende URL’s), terwijl signJwt() alleen het ondertekenen van goedgevormde JWT’s toestaat.

Ten slotte kan de gebruiker zich voordoen als een service-account zonder ooit een inlogcode voor het service-account op te halen. Dit is een geavanceerd gebruik en wordt alleen ondersteund voor programmatische toegang met de methode generateAccessToken(). In scenario’s met minstens 3 serviceaccounts, namelijk A, B, en C: serviceaccount A kan een toegangstoken voor serviceaccount C krijgen als serviceaccount A deiam.serviceAccounts.implicitDelegation-toestemming op B krijgt, en B de iam.serviceAccounts.getAccessToken-toestemming op C krijgt.

Genereren van OpenID Connect (OIDC) ID-tokens

Toestemmingen:

• iam.serviceAccounts.getOpenIdToken

Rollen:

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

Een gebruiker (of service) kan een OpenID Connect (OIDC)-compatibel JWT-token genereren dat is ondertekend door de Google OIDC Provider (accounts.google.com) dat de identiteit van de service-account vertegenwoordigt met behulp van de iam.serviceAccounts.getOpenIdTokentoestemming.

Deze tokens worden niet direct geaccepteerd door de meeste Google-API’s zonder dat uw organisatie aanvullende identiteitsfederatie implementeert om toegang tot Google te verlenen. Er zijn een paar uitzonderingen-bijvoorbeeld, Identity-Aware Proxy, dieOIDC-gebaseerde toegang toestaat tot door de gebruiker geleide applicaties.

Genereren van externe private sleutels

Toegangsrechten:

• iam.serviceAccountKeys.create

Rollen:

• roles/editor (Redacteur)
• roles/iam.serviceAccountAdmin (Serviceaccountbeheerder)

Een gebruiker of service kan extern privésleutelmateriaal (RSA) genereren dat kan worden gebruikt om zich rechtstreeks bij Google te authenticeren als de serviceaccount. Dit sleutelmateriaal kan vervolgens worden gebruikt met ADC-bibliotheken (Application Default Credentials), of met hetgcloud auth activate-service-account-commando. Iedereen die toegang krijgt tot het sleutelmateriaal, heeft dan volledige toegang tot alle bronnen waartoe het serviceaccount toegang heeft. Dergelijk privésleutelmateriaal dient met de grootste zorg te worden behandeld, en dient als minder veilig te worden beschouwd naarmate het materiaal langer bestaat. Daarom is het voor een goede beveiliging van cruciaal belang dat privatesleutelmateriaal wordt gerouleerd.

Beheer van serviceaccountsleutels

Er zijn twee soorten serviceaccountsleutels:

• Google Cloud-beheerde sleutels. Deze sleutels worden gebruikt door Google Cloudservices zoals App Engine en Compute Engine. Ze kunnen niet worden gedownload en worden automatisch geroteerd en maximaal twee weken lang gebruikt voor ondertekening. Het rotatieproces is probabilistisch; het gebruik van de nieuwe sleutel zal geleidelijk toenemen en afnemen gedurende de levensduur van de sleutel. We raden aan om de openbare sleutels voor een serviceaccount maximaal 24 uur in het cachegeheugen op te slaan, zodat u altijd toegang hebt tot de huidige sleutelset.

• Gebruikersbeheerde sleutels. Deze sleutels worden gemaakt, kunnen worden gedownload en worden beheerd door gebruikers. Nadat u ze uit de serviceaccount hebt verwijderd, kunt u ze niet meer gebruiken om u te authenticeren.

Voor door de gebruiker beheerde sleutels moet u ervoor zorgen dat u beschikt over processen om de vereisten voor sleutelbeheer, zoals:

• Sleutelopslag
• Sleuteldistributie
• Sleutelintrekking
• Sleutelrotatie
• Sleutels beschermen tegen onbevoegde gebruikers
• Sleutelherstel

Iedereen die toegang heeft tot een geldige privésleutel voor een serviceaccount, zal via de serviceaccount toegang kunnen krijgen tot bronnen. Merk op dat de levenscyclus van de toegang van de sleutel tot de service-account (en dus de gegevens waartoe de service-account toegang heeft) onafhankelijk is van de levenscyclus van de gebruiker die de sleutel heeft gedownload.

Antmoedig ontwikkelaars altijd om sleutels in de broncode te controleren of ze in de map Downloads van hun werkstation te laten staan.

Om de beveiliging van sleutels te verbeteren, volgt u de onderstaande richtlijnen:

• Gebruik de IAM-serviceaccount-API om uw serviceaccountsleutels automatisch te roteren. U kunt een sleutel roteren door een nieuwe sleutel te maken, applicaties te schakelen om de nieuwe sleutel te gebruiken en vervolgens de oude sleutel te verwijderen. Gebruik de methoden serviceAccount.keys.create() en serviceAccount.keys.delete() samen om de rotatie te automatiseren. De door Google Cloud beheerde sleutels worden ongeveer een keer per week geroteerd.

  • Gebruik de methode serviceAccount.keys.list() om serviceaccounts en sleutels te controleren.

Serviceaccounts gebruiken met Compute Engine

Compute Engine-instanties moeten als serviceaccount worden uitgevoerd om toegang te krijgen tot andere Google Cloud-bronnen. Om ervoor te zorgen dat uw Compute Engine-instanties veiliger zijn, kunt u het volgende overwegen:

• U kunt VM’s in hetzelfde project maken met verschillende serviceaccounts. Als u de serviceaccount van een VM wilt wijzigen nadat deze is gemaakt, gebruikt u de methodeinstances.setServiceAccount.

• U kunt IAM-rollen toewijzen aan serviceaccounts om te definiëren waartoe ze toegang hebben. In veel gevallen zul je niet meer op scopes hoeven te vertrouwen. Dit biedt u het voordeel dat u de machtigingen van een serviceaccount van een VM kunt wijzigen zonder de instantie opnieuw te hoeven maken.

• Omdat instanties afhankelijk zijn van hun serviceaccounts om toegang te hebben tot Google Cloud-bronnen, moet u voorkomen dat u serviceaccounts verwijdert wanneer deze nog steeds worden gebruikt door draaiende instanties. Als u de serviceaccounts verwijdert, kunnen de instances hun activiteiten gaan onderbreken.

Best practices

• Specifieer wie als serviceaccount kan fungeren. Gebruikers die serviceaccountgebruiker zijn voor een serviceaccount, hebben indirect toegang tot alle bronnen waartoe de serviceaccount toegang heeft. Wees daarom voorzichtig wanneer u de rol ServiceAccountUser aan een gebruiker toekent.

• Kent u de serviceaccount alleen de minimale set machtigingen die nodig is om het doel te bereiken. Meer informatie over het toekennen van rollen aan alle typen leden, inclusief serviceaccounts.

• Maak voor elke service service serviceaccounts met alleen de machtigingen die voor die service zijn vereist.

• Gebruik de weergavenaam van een serviceaccount om de serviceaccounts bij te houden. Wanneer u een serviceaccount aanmaakt, vult u de weergavenaam in met het doel van de serviceaccount.

• Stel een naamgevingsconventie op voor uw serviceaccounts.

• Omzeep processen om de rotatie van door gebruikers beheerde serviceaccountsleutels te automatiseren.

• Profiteer van de IAM serviceaccount-API om sleutelrotatie te implementeren.

• Controleer serviceaccounts en sleutels met de methodeserviceAccount.keys.list() of de pagina Logs Viewer in de console.

• Verwijder geen serviceaccounts die in gebruik zijn door actieve instanties opApp Engine of Compute Engine, tenzij u wilt dat deze applicaties geen toegang meer hebben tot de serviceaccount.