Háttér

A szolgáltatásfiók a Google-fiókok egy speciális típusa, amely nem emberi felhasználót képvisel, akinek hitelesítenie kell magát és hozzáférési jogosultságot kell kapnia a Google API-k adataihoz.

A szolgáltatási fiókokat tipikusan a következő esetekben használják:

• Virtuális gépeken (VM) futtatott munkaterhelések.
• A Google API-kat hívó, helyhez kötött munkaállomásokon vagy adatközpontokban futtatott munkaterhelések.
• Munkaterhelések futtatása, amelyek nem kötődnek egy emberi felhasználó életciklusához.

Az alkalmazás a Google API-k hívásához felveszi a szolgáltatási fiók identitását,így a felhasználók közvetlenül nem érintettek.

Szolgáltatási fiókok kezelése

Ha eldöntötte, hogy szüksége van egy szolgáltatási fiókra, felteheti magának a következő kérdéseket, hogy megértse, hogyan fogja használni a szolgáltatási fiókot:

• Milyen erőforrásokhoz férhet hozzá a szolgáltatási fiók?
• Milyen jogosultságokra van szüksége a szolgáltatásfióknak?
• Hol fog futni a kód, amely a szolgáltatásfiók identitását veszi fel – a Google Cloudon vagy helyben?

A fenti kérdésekre adandó válaszok kitalálásához használja az alábbi folyamatábrát:

Megjegyezzük, hogy a szolgáltatásfiókok mind forrásként, mind identitásként elképzelhetők.

Ha a szolgáltatásfiókra identitásként gondolunk, akkor szerepkört adhatunk a szolgáltatásfióknak, lehetővé téve számára, hogy hozzáférjen egy erőforráshoz (például egy projekthez).

Ha a szolgáltatásfiókra erőforrásként gondolunk, akkor szerepköröket adhatunk más felhasználóknak, hogy hozzáférjenek a szolgáltatásfiókhoz vagy kezeljék azt.

A szolgáltatásfiókokhoz való hozzáférés biztosítása

A szolgáltatásfiókhoz való hozzáférés biztosítása egy erőforráshoz való hozzáféréshez hasonló, mint bármely más identitáshoz való hozzáférés biztosítása. Például, ha van egy alkalmazás, amely aCompute Engine-en fut, és azt szeretné, hogy az alkalmazás csak a Cloud Storage-ban lévő objektumok létrehozásához férjen hozzá. Létrehozhat egy szolgáltatásfiókot az alkalmazás számára, és megadhatja neki a Storage Object Creator szerepkört.A következő ábra szemlélteti ezt a példát:

Tudjon meg többetA szerepkörök megadása minden típusú tagnak,beleértve a szolgáltatásfiókokat is.

A szolgáltatási fiókok nyomon követése

Az idő múlásával, ahogy egyre több és több szolgáltatási fiókot hoz létre, elveszítheti az áttekintést, hogy melyik szolgáltatási fiókot milyen célra használják.

A szolgáltatási fiók megjelenített neve jó lehetőség arra, hogy további információkat rögzítsen a szolgáltatási fiókról, például a szolgáltatási fiók célját vagy a fiók kapcsolattartóját. Új szolgáltatásfiókok esetén a megjelenített nevet a szolgáltatásfiók létrehozásakor töltheti ki. A meglévő szolgáltatásfiókok esetében a serviceAccounts.update() módszerrel módosíthatja a megjelenített nevet.

A nem használt szolgáltatásfiókok azonosítása

A nem használt szolgáltatásfiókok felesleges biztonsági kockázatot jelentenek, ezért javasoljuk a nem használt szolgáltatásfiókok letiltását, majd a szolgáltatásfiókok törlését, ha biztos benne, hogy már nincs rájuk szüksége. A következő módszerekkel azonosíthatja a nem használt szolgáltatásfiókokat:

• A szolgáltatásfiókok betekintése megmutatja, hogy a projektjében mely szolgáltatásfiókok nem hitelesítették magukat az elmúlt 90 napban.
• A szolgáltatásfiókok használati mérőszámai lehetővé teszik, hogy ellenőrizze, mikor használták utoljára a szolgáltatásfiókot.

Szolgáltatási fiókok törlése és újbóli létrehozása

Lehetőség van egy szolgáltatási fiók törlésére, majd egy új szolgáltatási fiók létrehozására ugyanazzal a névvel.

A szolgáltatási fiók törlésekor a szerepköri kötöttségek nem törlődnek azonnal. Ehelyett a szerepkötözések a szolgáltatásfiókot adeleted: előtaggal listázzák. Példát lásd: Házirendek törölt tagokkal.

Ha egy nemrég törölt szolgáltatásfiókkal azonos nevű új szolgáltatásfiókot hoz létre, a régi kötöttségek továbbra is létezhetnek, azonban nem vonatkoznak az új szolgáltatásfiókra, még akkor sem, ha mindkét fióknak ugyanaz az e-mail címe. Ez a viselkedés azért következik be, mert a szolgáltatásfiókok létrehozásakor egyedi azonosítót kapnak az azonosság- és hozzáférés-kezelésben (IAM). Belsőleg minden szerepkötözés ezen azonosítók, nem pedig a szolgáltatásfiók e-mail címe alapján történik. Ezért egy törölt szolgáltatásfiókhoz létező szerepkötözések nem vonatkoznak egy új szolgáltatásfiókra, amely ugyanazt az e-mail címet használja.

Hasonlóképpen, ha egy szolgáltatásfiókot egy erőforráshoz csatol, majd törli a szolgáltatásfiókot és létrehoz egy új szolgáltatásfiókot ugyanazzal a névvel, az új szolgáltatásfiók nem kapcsolódik az erőforráshoz.

Az ilyen váratlan viselkedés megelőzése érdekében fontolja meg egy új, egyedi név használatát minden szolgáltatásfiókhoz. Továbbá, ha véletlenül töröl egy szolgáltatásfiókot, megpróbálhatja visszaállítani a szolgáltatásfiók törlését egy új szolgáltatásfiók létrehozása helyett.

Ha nem tudja visszaállítani az eredeti szolgáltatásfiók törlését, és egy új szolgáltatásfiókot kell létrehoznia ugyanazzal a névvel és ugyanazokkal a szerepekkel, akkor ezeket a szerepeket az új szolgáltatásfióknak kell megadnia. A részletekért lásd: Törölt tagokkal rendelkező házirendek.

Ha az új szolgáltatásfióknak ugyanazokhoz az erőforrásokhoz kell kapcsolódnia, mint az eredeti szolgáltatásfióknak, tegye a következők egyikét:

• Compute Engine-példányok esetében megváltoztathatja a példányhoz csatolt szolgáltatásfiókot, hogy az eredeti szolgáltatásfiókot az új szolgáltatásfiókkal helyettesítse.
• Minden más erőforrás esetében törölni kell a meglévő erőforrást, majd létrehozni egy új, azonos típusú erőforrást, és hozzácsatolni az új szolgáltatásfiókot.

A szolgáltatásfiókok jogosultságai

Ez a szakasz a szolgáltatásfiókok, illetve a szolgáltatásfiókok megszemélyesítéséhez szükséges jogosultságokkal rendelkező felhasználói fiókok számára megadott engedélyek általános forgatókönyveit ismerteti:

• Szolgáltatási fiókok minimális jogosultságainak megadása
• Szolgáltatási fiókok jogosultságai a leggyakoribb forgatókönyvekhez

Szolgáltatási fiókok minimális jogosultságainak megadása

Mint minden tagtípus esetében, a szolgáltatásfióknak is csak a cél eléréséhez szükséges minimális jogosultságokat szabad megadni. Ismerje meg a szerepkörök megadásának módját minden tagtípus számára, beleértve a szolgáltatásfiókokat is.

A szolgáltatásfiókhoz való hozzáférési jogosultságok megadásakor tartsa szem előtt, hogy a felhasználó minden olyan erőforráshoz hozzáférhessen, amelyhez a szolgáltatásfióknak jogosultságai vannak. Ezért fontos, hogy gondosan konfigurálja a szolgáltatásfiókok jogosultságait; azaz szigorúan határozza meg, hogy a csapatában ki léphet fel (vagy személyesíthet meg) egy szolgáltatásfiókot. Különösen óvatosan járjon el, ha engedélyezi a felhasználóknak, hogy megszemélyesítsék a nagy jogosultságú szolgáltatásfiókokat, például aCompute Engine és az App Engine alapértelmezett szolgáltatásfiókjait.

Az App Engine és Compute Engine példányok frissítésére szolgáló IAM-szerepkörrel rendelkező felhasználók (például App Engine Deployer vagy Compute Instance Admin) ténylegesen futtathatnak kódot a példányok futtatására használt szolgáltatásfiókokként, és közvetve hozzáférhetnek minden olyan erőforráshoz, amelyhez a szolgáltatásfiókok hozzáféréssel rendelkeznek. Hasonlóképpen, a Compute Engine-példányhoz való SSH-hozzáférés szintén lehetővé teheti a kód futtatását az adott példányként.

Szolgáltatási fiókok engedélyei a leggyakoribb forgatókönyvekhez

A szolgáltatási fiókok számos különböző forgatókönyvben használhatók, és mindegyikhez szükség van bizonyos engedélyekre. Ez a szakasz ismerteti a gyakori forgatókönyveket és a szükséges engedélyeket.

Szolgálati fiókok hozzárendelése erőforrásokhoz

Ha olyan hosszú futású feladatot szeretne indítani, amely szolgálati fiókként hitelesíti magát,akkor egy szolgálati fiókot kell hozzárendelnie a feladatot futtató erőforráshoz.

Jogosultságok:

• Az erőforrás létrehozásához szükséges jogosultságok
• iam.serviceAccounts.actAs

Az ezeket a jogosultságokat tartalmazó szerepkörök megtalálásához keressen rá a szerepkörök listájában a jogosultságokra.

A Google Cloud számos különböző erőforrása létezik, amelyeken a hosszú futású feladatok szolgáltatásfiókként futtathatók. Néhány példa ezekre az erőforrásokra:

• Compute Engine VM-ek
• App Engine alkalmazások
• Cloud Functions

Az erőforrások létrehozásakor lehetőség van szolgáltatásfiók csatolására. Ez a szolgáltatásfiók az erőforrás azonosítójaként működik.

Egy erőforrás létrehozásához és egy szolgáltatásfiók csatolásához engedélyekre van szüksége az erőforrás létrehozásához és az erőforráshoz csatolandó szolgáltatásfiók megszemélyesítéséhez. A szolgáltatásfiók megszemélyesítésének engedélyét bármely olyan szerepkör biztosítja, amely tartalmazza a iam.serviceAccounts.actAs engedélyt.

Az erőforrás létrehozása és a szolgáltatásfiók hozzácsatolása után elindíthat egy hosszú távú feladatot az erőforráson. A feladat az erőforráshoz csatolt szolgáltatásfiókként fut, és ezt a szolgáltatásfiókot használja a Google Cloud API-khoz intézett kérelmek engedélyezésére.

A szolgáltatásfiókok erőforráshoz csatolásáról bővebben a Szolgáltatásfiók erőforráshoz csatolása című témakörben olvashat.

Szolgálati fiók közvetlen megszemélyesítése

Jogosultságok:

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

Rol:

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

A szükséges jogosultságok megadása után egy felhasználó (vagy szolgáltatás) néhány gyakori esetben közvetlenül megszemélyesítheti (vagy megerősítheti) egy szolgáltatási fiók identitását.

Először is, a felhasználó aiam.serviceAccounts.getAccessToken jogosultság használatával és agenerateAccessToken()módszer meghívásával megkaphatja a szolgáltatásfiók rövid távú hitelesítő adatait. A rövid távú hitelesítő adatok használatával a felhasználó parancsokat adhat ki aGoogle Cloudnak, és hozzáférhet minden olyan erőforráshoz, amelyhez a szolgáltatásfiók hozzáféréssel rendelkezik. Ez az adatfolyam például lehetővé teszi a felhasználó számára, hogy agcloud --impersonate-service-accountjelző használatával megszemélyesítse a szolgáltatási fiókot anélkül, hogy szükség lenne egy letöltött külső szolgáltatási fiókkulcs használatára.

Második lehetőség, hogy a felhasználó a iam.serviceAccounts.signBlob jogosultság használatával és asignBlob()vagysignJwt()módszer meghívásával a Google által kezelt szolgáltatási fiók privát kulcsával aláírt artefaktumokat kapjon. A Google által kezelt magánkulcsot mindig letétbe helyezik, és soha nem kerül közvetlenül nyilvánosságra. A signBlob() lehetővé teszi tetszőleges hasznos terhelések aláírását (példáulCloud Storage által aláírt URL-ek), míg a signJwt() csak jól formázott JWT-k aláírását teszi lehetővé.

Végül a felhasználó megszemélyesítheti (vagy megerősítheti) a szolgáltatásfiókot anélkül, hogy valaha is lekérné a szolgáltatásfiók hitelesítő adatait. Ez egy speciális felhasználási eset,és csak agenerateAccessToken()módszerrel történő programozott hozzáférés esetén támogatott. Legalább 3 szolgáltatásfiókot tartalmazó forgatókönyvekben, nevezetesen A, B és C: az A szolgáltatásfiók hozzáférési tokent kaphat a C szolgáltatásfiókhoz, ha az A szolgáltatásfiók megkapja aiam.serviceAccounts.implicitDelegation engedélyt B-re, és B megkapja a iam.serviceAccounts.getAccessToken engedélyt C-re.

OpenID Connect (OIDC) azonosító tokenek generálása

Jogosultságok:

• iam.serviceAccounts.getOpenIdToken

Rólusok:

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

A felhasználó (vagy szolgáltatás) OpenID Connect (OIDC)-kompatibilis JWT tokeneket hozhat létre, amelyeket a Google OIDC Provider (fiókok.google.com), amely a iam.serviceAccounts.getOpenIdTokenengedélyt használó szolgáltatási fiók identitását képviseli.

Ezeket a tokeneket a legtöbb Google API közvetlenül nem fogadja el anélkül, hogy az Ön szervezete további identitás-összevonást telepítene a Google-hoz való hozzáférés biztosításához. Van néhány kivétel – például az Identity-Aware Proxy, amely lehetővé tesziOIDC-alapú hozzáférést a felhasználó által futtatott alkalmazásokhoz.

Külső privát kulcsok generálása

Jogosultságok:

• iam.serviceAccountKeys.create

Rólusok:

• roles/editor (Szerkesztő)
• roles/iam.serviceAccountAdmin (Szolgáltatási fiók adminisztrátora)

A felhasználó vagy szolgáltatás létrehozhat külső privát kulcsanyagot (RSA), amely felhasználható a Google-nál történő közvetlen hitelesítésre, mint szolgáltatási fiók. Ez a kulcsanyag ezután az ADC (Application Default Credentials) könyvtárakkal vagy agcloud auth activate-service-accountparanccsal használható. Bárki, aki hozzáfér a kulcsanyaghoz, teljes hozzáférést kap minden olyan erőforráshoz, amelyhez a szolgáltatásfiók hozzáfér. Az ilyen magánkulcsos anyagot a legnagyobb aggodalommal kell kezelni, és annál kevésbé biztonságosnak kell tekinteni, minél tovább létezik az anyag. Ezért a magánkulcs-anyag rotálása kritikus fontosságú az erős biztonság fenntartásához.

A szolgáltatási fiókkulcsok kezelése

A szolgáltatási fiókkulcsoknak két típusa van:

• Google Cloud által kezelt kulcsok. Ezeket a kulcsokat a Google Cloudszolgáltatások, például az App Engine és a Compute Engine használják. Nem tölthetők le, és automatikusan cserélődnek, és legfeljebb két hétig használhatók aláírásra. A rotációs folyamat valószínűségi alapú; az új kulcs használata a kulcs élettartama alatt fokozatosan emelkedik és csökken. Javasoljuk, hogy egy szolgáltatási fiók nyilvános kulcskészletét legfeljebb 24 órán keresztül tárolja, hogy mindig hozzáférjen az aktuális kulcskészlethez.

• A felhasználó által kezelt kulcsok. Ezeket a kulcsokat a felhasználók hozzák létre, tölthetik le és kezelik. Miután törölte őket a szolgáltatásfiókból, nem használhatja őket hitelesítésre.

A felhasználó által kezelt kulcsok esetében meg kell győződnie arról, hogy a kulcskezelési követelményekre vonatkozó eljárásokkal rendelkezik, mint például:

• Kulcsok tárolása
• Kulcsok elosztása
• Kulcsok visszavonása
• Kulcsok rotációja
• Kulcsok védelme a jogosulatlan felhasználóktól
• Kulcsok helyreállítása

Aki hozzáfér egy szolgáltatásfiók érvényes magánkulcsához, az a szolgáltatásfiókon keresztül hozzáférhet az erőforrásokhoz. Vegye figyelembe, hogy a kulcs szolgáltatásfiókhoz való hozzáférésének (és így a szolgáltatásfiók által elérhető adatoknak) az életciklusa független a kulcsot letöltő felhasználó életciklusától.

A fejlesztőket mindig lebeszéljük arról, hogy a kulcsokat a forráskódba ellenőrizzék, vagy a munkaállomásuk Letöltések könyvtárában hagyják.

A kulcsok biztonságának növelése érdekében kövesse az alábbi útmutatást:

• Az IAM szolgáltatásfiók API-t használja a szolgáltatásfiókkulcsok automatikus forgatására. A kulcsot úgy forgathatja le, hogy új kulcsot hoz létre, az alkalmazásokat átállítja az új kulcs használatára, majd törli a régi kulcsot. A serviceAccount.keys.create() és serviceAccount.keys.delete() módszereket együttesen használhatja a rotáció automatizálásához. A Google Cloud által kezelt kulcsok körülbelül hetente egyszer kerülnek rotálásra.

  • A serviceAccount.keys.list() módszerrel ellenőrizheti a szolgáltatásfiókokat és kulcsokat.

Szolgáltatási fiókok használata a Compute Engine-nel

A Compute Engine példányoknak szolgáltatásfiókként kell futniuk, hogy hozzáférjenek más Google Cloud erőforrásokhoz. Annak érdekében, hogy aCompute Engine-példányai biztonságosabbak legyenek, vegye figyelembe a következőket:

• Egyazon projektben VM-eket hozhat létre különböző szolgáltatásfiókokkal. Egy VM szolgáltatásfiókjának létrehozás utáni megváltoztatásához használja ainstances.setServiceAccountmódszert.

• A szolgáltatásfiókoknak IAM-szerepköröket adhat, hogy meghatározza, mihez férhetnek hozzá. Sok esetben már nem lesz szükség a távcsövekre. Ez azt az előnyt nyújtja, hogy aVM szolgáltatási fiókjának jogosultságait a példány újbóli létrehozása nélkül módosíthatja.

• Mivel a példányok a szolgáltatási fiókjaiktól függnek, hogy hozzáférjenek aGoogle Cloud erőforrásaihoz, kerülje a szolgáltatási fiókok törlését, ha azokat a futó példányok még használják. Ha törli a szolgáltatásfiókokat, az instanciák működése meghiúsulhat.

A legjobb gyakorlatok

• Meghatározhatja, hogy kik léphetnek fel szolgáltatásfiókként. Azok a felhasználók, akik egy szolgáltatásfiók felhasználójaként szolgálnak, közvetve hozzáférhetnek minden olyan erőforráshoz, amelyhez a szolgáltatásfiók hozzáféréssel rendelkezik. Ezért legyen óvatos, amikor egy felhasználónak megadja aSzolgáltatásfiókBelhasználó szerepkört.

• A szolgáltatásfióknak csak a cél eléréséhez szükséges minimális jogosultságokat adja meg. Ismerje meg a szerepkörök megadásának módját minden típusú tag számára, beleértve a szolgáltatásfiókokat is.

• Létrehozzon szolgáltatásfiókokat minden egyes szolgáltatáshoz, csak az adott szolgáltatáshoz szükséges jogosultságokkal.

• A szolgáltatásfiókok nyomon követéséhez használja a szolgáltatásfiók megjelenített nevét. Amikor létrehoz egy szolgáltatásfiókot, töltse ki a megjelenítési nevet a szolgáltatásfiók céljával.

• Feladjon egy elnevezési konvenciót a szolgáltatásfiókok számára.

• Vezessen be folyamatokat a felhasználó által kezelt szolgáltatásfiókkulcsok rotációjának automatizálására.

A kulcsok rotációjának megvalósításához használja ki azIAM szolgáltatásfiók API-t.

• A szolgáltatásfiókok és kulcsok ellenőrzése aserviceAccount.keys.list() módszerrel vagy a konzolNaplók megtekintése lap segítségével.

• Ne törölje azokat a szolgáltatásfiókokat, amelyeket azApp Engine vagy Compute Engine futtatott példányai használnak, kivéve, ha azt szeretné, hogy ezek az alkalmazások ne férjenek hozzá a szolgáltatásfiókhoz.