Tausta

Palvelutili on erityyppinen Google-tili, joka on tarkoitettu edustamaan muuta kuin ihmistä, jonka on todennettava itsensä ja jolla on oltava valtuudet käyttää tietoja Googlen sovellusliittymissä.

Tyypillisesti palvelutilejä käytetään esimerkiksi seuraavissa skenaarioissa:

• Työkuormien suorittaminen virtuaalikoneissa (VM).
• Työkuormien suorittaminen toimitiloissa olevissa työasemissa tai datakeskuksissa, jotka kutsuvatGooglen APIja.
• Työkuormien suorittaminen, jotka eivät ole sidoksissa ihmiskäyttäjän elinkaareen.

Sovelluksesi omaksuu palvelutilin identiteetin kutsuakseen Google API:ita,joten käyttäjät eivät ole suoraan mukana.

Palvelutilien hallinta

Kun päätät, että tarvitset palvelutilin, voit kysyä itseltäsi seuraavat kysymykset, jotta ymmärrät, miten aiot käyttää palvelutiliä:

• Mitä resursseja palvelutili voi käyttää?
• Mitä oikeuksia palvelutili tarvitsee?
• Missä palvelutilin identiteettiä käyttävä koodi käynnistyy- Google Cloudissa vai toimitiloissa?

Käytä seuraavaa vuokaaviota selvittääksesi vastaukset yllä oleviin kysymyksiin:

Huomaa, että palvelutilejä voidaan ajatella sekä lähteenä että identiteettinä.

Kun ajattelet palvelutiliä identiteettinä, voit antaa palvelutilille roolin, jonka avulla se voi käyttää resurssia (kuten projektia).

Kun ajattelet palvelutiliä resurssina, voit antaa muillekäyttäjille rooleja, joiden avulla he voivat käyttää tai hallinnoida kyseistä palvelutiliä.

Käyttövaltuuksien myöntäminen palvelutileille

Käyttövaltuuksien myöntäminen palvelutilille resurssin käyttämiseksi on samanlaista kuin käyttövaltuuksien myöntäminen mille tahansa muulle identiteetille. Jos sinulla on esimerkiksi sovellus, joka on käynnissäCompute Engine -palvelimella, ja haluat, että sovelluksella on pääsy vain Cloud Storage -palvelun objektien luomiseen. Voit luoda sovellukselle palvelutilin ja antaa sille Storage Object Creator -roolin.Seuraava kaavio havainnollistaa tätä esimerkkiä:

Learn aboutRoolien antaminen kaikentyyppisille jäsenille,myös palvelutileille.

Palvelutilien seuraaminen

Ajan myötä, kun luot yhä useampia palvelutilejä, saatat menettää tietosi siitä, mitä palvelutiliä käytetään mihinkin tarkoitukseen.

Palvelutilin näyttönimi on hyvä tapa tallentaa lisätietoja palvelutilistä, kuten palvelutilin tarkoitus tai tilin yhteyshenkilö. Uusia palvelutilejä varten voittäyttää näyttönimen palvelutilin luomisen yhteydessä. Olemassa olevien palvelutilien osalta voit muokata näyttönimeä serviceAccounts.update()-menetelmällä.

Käyttämättömien palvelutilien tunnistaminen

Käyttämättömät palvelutilit aiheuttavat tarpeettoman turvallisuusriskin, joten suosittelemme käyttämättömien palvelutilien poistamista käytöstä ja palvelutilien poistamista, kun olet varma, ettet enää tarvitse niitä. Voit käyttää seuraavia menetelmiä käyttämättömien palvelutilien tunnistamiseen:

• Palvelutilien havainnot kertovat, mitä projektisi palvelutilejä ei ole todennettu viimeisten 90 päivän aikana.
• Palvelutilien käyttömittausten avulla voit tarkistaa, milloin palvelutiliä on viimeksi käytetty.

Palvelutilien poistaminen ja luominen uudelleen

Palvelutili on mahdollista poistaa ja luoda sen jälkeen uusi palvelutili samalla nimellä.

Kun poistat palvelutilin, sen roolisidonnaisuuksia ei poisteta välittömästi. Sen sijaan roolisidonnaisuuksissa luetellaan palvelutili etuliitteellädeleted:. Esimerkki on kohdassa Käytännöt, joissa on poistettuja jäseniä.

Jos luot uuden palvelutilin, jolla on sama nimi kuin äskettäin poistetulla palvelutilillä, vanhat sidonnaisuudet voivat olla edelleen olemassa; ne eivät kuitenkaan koske uutta palvelutiliä, vaikka molemmilla tileillä on sama sähköpostiosoite. Tämä johtuu siitä, että palvelutileille annetaan luotaessa yksilöllinen tunniste Identity and Access Management (IAM) -järjestelmässä. Sisäisesti kaikki roolisidonnaisuudet myönnetään käyttämällä näitä tunnuksia, ei palvelutilin sähköpostiosoitetta. Näin ollen poistettua palvelutiliä koskevat roolin sidonnat eivät koske uutta palvelutiliä, joka käyttää samaa sähköpostiosoitetta.

Jos palvelutili liitetään resurssiin, palvelutili poistetaan ja luodaan uusi palvelutili samalla nimellä, uutta palvelutiliä ei liitetä resurssiin.

Tämän odottamattoman käyttäytymisen estämiseksi kannattaa harkita uuden, yksilöllisen nimen käyttämistä jokaiselle palvelutilille. Jos poistat palvelutilin vahingossa, voit myös yrittää perua palvelutilin poiston uuden palvelutilin luomisen sijaan.

Jos et voi perua alkuperäisen palvelutilin poistoa ja sinun on luotava uusi palvelutili samalla nimellä ja samoilla rooleilla, sinun on annettava roolit uudelle palvelutilille. Lisätietoja on kohdassaPolicies with deleted members.

Jos haluat myös, että uusi palvelutili liitetään samoihin resursseihin kuin alkuperäinen palvelutili, tee jompikumpi seuraavista:

• Compute Engine -instansseissa voit vaihtaa instanssiin liitetyn palvelutilin korvaamalla alkuperäisen palvelutilin uudella palvelutilillä.
• Kaikkien muiden resurssien osalta sinun on poistettava olemassa oleva resurssi ja luot sitten uuden samantyyppisen resurssin ja liitettävä siihen uusi palvelutili.

Palvelutilien käyttöoikeudet

Tässä osassa kuvataan yleisiä skenaarioita käyttöoikeuksista, jotka myönnetään palvelutileille tai käyttäjätileille, joilla on oikeudet esiintyä palvelutileinä:

• Palvelutilien vähimmäisoikeuksien myöntäminen palvelutileille
• Palvelutilien oikeudet yleisimmissä skenaarioissa

Palvelutilien vähimmäisoikeuksien myöntäminen palvelutileille

Kuten kaikentyyppisten jäsenten kohdalla, palvelutilillekin tulisi myöntää vain sen tavoitteen saavuttamiseen tarvittavat vähimmäisoikeudet. Lisätietoja roolien myöntämisestä kaikentyyppisille jäsenille,myös palvelutileille.

Kun myönnät käyttäjille oikeuksia käyttää palvelutiliä, pidä mielessä, että käyttäjä voi käyttää kaikkia resursseja, joihin palvelutilillä on oikeuksia. Siksi on tärkeää määrittää palvelutilien käyttöoikeudet huolellisesti; eli ole tiukka sen suhteen, kuka tiimissäsi voi toimia (tai esiintyä) palvelutilinä. Ole erityisen varovainen, kun sallit käyttäjien esiintyä erittäin etuoikeutettuina palvelutileinä, kutenCompute Engine- ja App Enginedefault-palvelutileinä.

Käyttäjät, joilla on IAM-roolit App Engine- ja Compute Engine -instanssien päivittämiseen (kutenApp Engine Deployer tai Compute Instance Admin), voivat tehokkaasti suorittaa koodia näiden instanssien käyttämiseen käytetyillä palvelutileillä ja saada epäsuorasti pääsyn kaikkiin niihin resursseihin, joihin palvelutilien käyttöoikeudet ovat. Vastaavasti SSH-käyttöoikeus Compute Engine -instanssiin voi myös antaa mahdollisuuden suorittaa koodia kyseisenä instanssina.

Palvelutilien käyttöoikeudet yleisimmissä skenaarioissa

Palvelutilejä voidaan käyttää monissa eri skenaarioissa, ja jokainen niistä vaatii tietyt käyttöoikeudet. Tässä osassa kuvataan yleisiä skenaarioita ja vaadittavia käyttöoikeuksia.

Palvelutilien liittäminen resursseihin

Jos haluat käynnistää pitkäkestoisen työn, joka todennetaan palvelutilinä,sinun on liitettävä palvelutili resurssiin, joka suorittaa työn.

Oikeudet:

• Oikeudet resurssin luomiseen
• iam.serviceAccounts.actAs

Etsiäksesi rooleja, jotka sisältävät nämä oikeudet, etsi oikeudet theroles-luettelosta.

On olemassa useita erilaisia Google Cloud -resursseja, joilla voi suorittaapitkäkestoisia töitä palvelutileinä. Esimerkkejä näistä resursseista ovat:

• Compute Engine VM:t
• App Engine -sovellukset
• Cloud-toiminnot

Luodessasi näitä resursseja sinulla on mahdollisuus liittää palvelutili. Tämä palvelutili toimii resurssin identiteettinä.

Luoaksesi resurssin ja liittääksesi siihen palvelutilin, tarvitset oikeudet resurssin luomiseen ja oikeuden henkilöityä palvelutiliin, jonka aiot liittää resurssiin. Palvelutilin henkilöitymisoikeuden antaa mikä tahansa rooli, joka sisältää iam.serviceAccounts.actAs-oikeuden.

Kun olet luonut resurssin ja liittänyt siihen palvelutilin, voit käynnistää resurssin pitkäkestoisen työn. Työ suoritetaan resurssiin liitetyllä palvelutilillä, ja se käyttää kyseistä palvelutiliä pyyntöjen valtuuttamiseenGoogle Cloud API:ille.

Katso lisätietoja palvelutilien liittämisestä resursseihin kohdasta Palvelutilin liittäminen resurssiin.

Palvelutilin suoranainen henkilöityminen

Oikeudet:

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

Roolit:

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

Kun käyttäjälle (tai palvelulle) on myönnetty vaaditut oikeudet, hän voi muutamissa tavallisissa skenaarioissa suoraan henkilöityä (tai vakuuttaa) palvelutilin identiteetin.

Käyttäjä voi ensinnäkin saada lyhytaikaiset tunnistetiedot palvelutilille käyttämälläiam.serviceAccounts.getAccessToken-oikeutta ja kutsumallagenerateAccessToken()metodia. Käyttämällä lyhytaikaisia valtakirjoja käyttäjä voi antaa komentojaGoogle Cloudille ja käyttää kaikkia resursseja, joihin palvelutilillä on pääsy. Tämä virtaus mahdollistaa esimerkiksi sen, että käyttäjä voi käyttäägcloud --impersonate-service-accountlippua esiintyäkseen palvelutilinä ilman, että hän tarvitsee ladattua ulkoisen palvelutilin avainta.

Toiseksi, käyttäjä voi saada artefakteja, jotka on allekirjoitettu Googlen hallinnoimalla palvelutilin yksityisellä avaimella käyttämällä iam.serviceAccounts.signBlob-oikeutta ja kutsumalla jokosignBlob()taisignJwt()metodia. Googlen hallinnoimaa yksityistä avainta pidetään aina tallessa eikä sitä koskaan paljasteta suoraan. signBlob() sallii mielivaltaisten hyötykuormien allekirjoittamisen (kutenCloud Storagen allekirjoittamat URL-osoitteet), kun taas signJwt() sallii vain hyvin muotoiltujen JWT:iden allekirjoittamisen.

Loppujen lopuksi käyttäjä voi esiintyä (tai väittää) palvelutilinä ilman, että hän koskaan hakee palvelutilin valtakirjaa. Tämä on edistynyt käyttötapaus,ja sitä tuetaan vain ohjelmallisessa käytössägenerateAccessToken()menetelmällä. Skenaarioissa, joissa on vähintään kolme palvelutiliä, nimittäin A, B ja C: palvelutili A voi saada käyttöoikeustunnisteen palvelutiliä C varten, jos palvelutilille A on myönnettyiam.serviceAccounts.implicitDelegation-oikeus B:hen ja B:lle on myönnetty iam.serviceAccounts.getAccessToken-oikeus C:hen.

Generating OpenID Connect (OIDC) ID tokenes

Permissions:

• iam.serviceAccounts.getOpenIdToken

Roles:

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

Käyttäjä (tai palvelu) voi luoda OpenID Connect (OIDC)-yhteensopivan JWT-tunnisteen, jonka on allekirjoittanut Googlen OIDC-palveluntarjoaja (accounts.google.com), joka edustaa palvelutilin identiteettiä käyttäen iam.serviceAccounts.getOpenIdTokenlupaa.

Useimmat Googlen API:t eivät suoraan hyväksy näitä tunnuksia ilman, että organisaatiosi ottaa käyttöön ylimääräisen identiteettiliittymän myöntääkseen pääsyn Googleen. On olemassa muutamia poikkeuksia – esimerkiksi Identity-Aware Proxy, joka salliiOIDC-pohjaisen pääsyn käyttäjän suorittamiin sovelluksiin.

Ulkoisten yksityisten avainten luominen

Oikeudet:

• iam.serviceAccountKeys.create

Roolit:

• roles/editor (Editor)
• roles/iam.serviceAccountAdmin (Service Account Admin)

Käyttäjä tai palvelu voi luoda ulkoista yksityistä avainmateriaalia (RSA), jota voidaan käyttää tunnistautumiseen suoraan Googleen palvelutilinä. Tätä avainmateriaalia voidaan sitten käyttää ADC-kirjastojen (Application Default Credentials) taigcloud auth activate-service-accountkomennon avulla. Avainmateriaalin haltuunsa saaneella henkilöllä on täysi pääsy kaikkiin resursseihin, joihin palvelutilillä on pääsy. Tällaiseen yksityiseen avainmateriaaliin on suhtauduttava erittäin huolestuneesti, ja sitä on pidettävä sitä turvattomampana, mitä kauemmin materiaali on olemassa. Siksi yksityisen avainmateriaalin kiertäminen on kriittisen tärkeää vahvan tietoturvan ylläpitämiseksi.

Palvelutilin avainten hallinta

Palvelutilin avaimia on kahdenlaisia:

• Google Cloudin hallinnoimat avaimet. Näitä avaimia käyttävät Google Cloud -palvelut, kuten App Engine ja Compute Engine. Niitä ei voi ladata, ja ne pyörivät automaattisesti ja niitä käytetään allekirjoittamiseen enintään kahden viikon ajan. Kiertoprosessi on probabilistinen; uuden avaimen käyttö lisääntyy ja vähenee asteittain avaimen käyttöiän aikana. Suosittelemme tallentamaan palvelutilin julkisen avainsarjan välimuistiin enintään 24 tunniksi, jotta voit varmistaa, että sinulla on aina pääsy nykyiseen avainsarjaan.

• Käyttäjän hallinnoimat avaimet. Nämä avaimet ovat käyttäjien luomia, ladattavia ja hallinnoimia. Kun poistat ne palvelutililtä, et voi käyttää niitä tunnistautumiseen.

Käyttäjien hallitsemien avainten osalta on varmistettava, että käytössäsi on prosesseja, jotka vastaavat avainten hallinnan vaatimuksiin, kuten:

• avainten varastointi
• avainten jakelu
• avainten peruuttaminen
• avainten kierto
• avainten suojaaminen luvattomilta käyttäjiltä
• avainten palautus

Kuka tahansa, jolla on pääsy palvelutilin voimassa olevaan yksityiseen avaimeen, pääsee käyttämään resursseja palvelutilin kautta. Huomaa, että avaimen käyttöoikeuden elinkaari palvelutiliin (ja siten tiedot, joihin palvelutilillä on käyttöoikeus) on riippumaton avaimen ladanneen käyttäjän elinkaaresta.

Kehittäjiä ei aina kehoteta tarkistamaan avaimia lähdekoodiin tai jättämään niitä työaseman Lataukset-hakemistoon.

Voidaksesi parantaa avainten turvallisuutta noudata alla olevia ohjeita:

• Käytä IAM-palvelutilien API:ta palvelutilien avainten automaattiseen kiertämiseen. Voit kiertää avaimen luomalla uuden avaimen, vaihtamalla sovellukset käyttämään uutta avainta ja poistamalla sitten vanhan avaimen. Käytä serviceAccount.keys.create()– ja serviceAccount.keys.delete()-metodeja yhdessä kiertämisen automatisoimiseksi. Google Cloudin hallinnoimat avaimet kierrätetään noin kerran viikossa.

  • Käytä serviceAccount.keys.list()-metodia palvelutilien ja avainten tarkastamiseen.

Palvelutilien käyttäminen Compute Enginen kanssa

Compute Engine -instanssien on toimittava palvelutileinä, jotta ne voivat käyttää muita Google Cloud -resursseja. Jos haluat varmistaa, että Compute Engine -instanssit ovat turvallisempia, ota huomioon seuraavat seikat:

• Voit luoda VM:t samaan projektiin eri palvelutileillä. Jos haluat vaihtaa VM:n palvelutilin sen luomisen jälkeen, käytäinstances.setServiceAccountmenetelmää.

• Voit antaa palvelutileille IAM-rooleja määritelläksesi, mitä ne voivat käyttää. Monissa tapauksissa sinun ei tarvitse enää luottaa mittakaavoihin. Tämä antaa sinulle sen edun, että voit muuttaaVM:n palvelutilin käyttöoikeuksia luomatta instanssia uudelleen.

• Koska instanssit ovat riippuvaisia palvelutileistään saadakseen pääsynGoogle Cloudin resursseihin, vältä poistamasta palvelutilejä, kun ne ovat edelleen käynnissä olevien instanssien käytössä. Jos poistat palvelutilit, instanssit saattavat alkaa epäonnistua toiminnoissaan.

Hyvät käytännöt

• Määritä, ketkä voivat toimia palvelutileinä. Käyttäjät, jotka ovatPalvelutilin käyttäjiäPalvelutilin käyttäjät voivat epäsuorasti käyttää kaikkia resursseja, joihin palvelutilillä on käyttöoikeus. Ole siksi varovainen, kun annat käyttäjälle palvelutiliKäyttäjä-roolin.

• Tarjoa palvelutilille vain vähimmäismäärä oikeuksia, jotka ovat välttämättömiä sen tavoitteen saavuttamiseksi. Tutustu roolien myöntämiseen kaikentyyppisille jäsenille, myös palvelutileille.

• Luo palvelutilit kullekin palvelulle, joilla on vain kyseistä palvelua varten tarvittavat käyttöoikeudet.

• Käytä palvelutilin näyttönimeä, jotta voit seurata palvelutilejä. Kun luot palvelutilin, täytä sen näyttönimeen palvelutilin käyttötarkoitus.

• Määrittele palvelutilien nimeämiskäytäntö.

• Valmistele prosessit, joilla automatisoidaan käyttäjähallinnoitujen palvelutilien avainten kierto.

• HyötyileIAM:n palvelutili-API:n avulla, jotta voit toteuttaa avainten kierron.

• Tarkista palvelutilit ja avaimet jokoserviceAccount.keys.list()-menetelmällä tai konsolinLogs Viewer -sivulla.

• Älä poista palvelutilejä, jotka ovat käynnissä olevien instanssien käytössäApp Enginessä tai Compute Enginessä, ellet halua, että näillä sovelluksilla ei ole pääsyä palvelutiliin.