Pozadí

Služební účet je speciální typ účtu Google, který má zastupovat uživatele, který není člověkem a který potřebuje ověření a oprávnění k přístupu k datům v rozhraní Google API.

Typicky se servisní účty používají ve scénářích, jako jsou:

• Provozování pracovních úloh na virtuálních počítačích (VM).
• Provozování pracovních úloh na lokálních pracovních stanicích nebo datových centrech, které volají rozhraní Google API.
• Spouštění pracovních zátěží, které nejsou vázány na životní cyklus lidského uživatele.

Vaše aplikacepřevezme identitu účtu služby pro volání rozhraní Google API,takže uživatelé nejsou přímo zapojeni.

Správa účtů služeb

Jakmile se rozhodnete, že potřebujete účet služeb, můžete si položit následující otázky, abyste pochopili, jak budete účet služeb používat:

• K jakým prostředkům může účet služeb přistupovat?
• Jaká oprávnění účet služby potřebuje?
• Kde bude kód, který přebírá identitu účtu služby, spuštěn – ve službě Google Cloud nebo v lokálním prostředí?

Pomocí následujícího vývojového diagramu zjistíte odpovědi na výše uvedené otázky:

Všimněte si, že účty služby lze považovat za zdroj i za identitu.

Pokud o účtu služby uvažujete jako o identitě, můžete účtu služby přidělit roli, která mu umožní přístup ke zdroji (například k projektu).

Pokud o účtu služby uvažujete jako o zdroji, můžete ostatním uživatelům přidělit role pro přístup k účtu služby nebo pro jeho správu.

Přidělení přístupu k účtům služby

Přidělení přístupu k účtu služby pro přístup ke zdroji je podobné jako přidělení přístupu k jakékoli jiné identitě. Například pokud máte aplikaci spuštěnou naCompute Engine a chcete, aby aplikace měla přístup pouze kvytváření objektů v úložišti Cloud Storage. Můžete pro aplikaci vytvořit účet služby a přidělit mu roli Tvůrce objektů úložiště. tento příklad ilustruje následující schéma:

Přečtěte si oPřidělování rolí všem typům členů,včetně účtů služby.

Sledování servisních účtů

S časem, jak vytváříte další a další servisní účty, můžete ztratit přehled o tom, který servisní účet se používá k jakému účelu.

Zobrazený název servisního účtu je dobrý způsob, jak zachytit další informace o servisním účtu, například účel servisního účtu nebo kontaktní osobu pro účet. U nových servisních účtů můžete zobrazovaný název vyplnit při vytváření servisního účtu. Pro existujícíslužební účty použijte metodu serviceAccounts.update() k úpravě zobrazovaného názvu.

Identifikace nepoužívaných servisních účtů

Nepoužívané servisní účty vytvářejí zbytečné bezpečnostní riziko, proto doporučujeme nepoužívané servisní účty zakázat a poté je odstranit, až si budete jisti, že je již nepotřebujete. K identifikaci nepoužívaných servisních účtů můžete použít následující metody:

• Přehledy servisních účtů vám řeknou, které servisní účty ve vašem projektu nebyly v posledních 90 dnech ověřeny.
• Metriky používání servisních účtů vám umožní zjistit, kdy byl servisní účet naposledy použit.

Mazání a znovuvytváření servisních účtů

Je možné smazat servisní účet a poté vytvořit nový servisní účet se stejným názvem.

Pokud smažete servisní účet, jeho vazby na role nebudou okamžitě smazány. Místo toho je ve vazbách rolí uveden účet služby s předponoudeleted:. Příklad naleznete v části Zásady se smazanými členy.

Pokud vytvoříte nový účet služby se stejným názvem jako nedávno smazaný účet služby, staré vazby mohou stále existovat; nebudou se však vztahovat na nový účet služby, přestože oba účty mají stejnou e-mailovou adresu. K tomuto chování dochází proto, že účtům služeb je při vytváření přiděleno jedinečné IDv rámci správy identit a přístupu (IAM). Interně jsou všechny vazby rolípřidělovány pomocí těchto ID, nikoliv pomocí e-mailové adresy účtu služby. Proto se žádné vazby rolí, které existovaly pro smazaný účet služby, nevztahují na nový účet služby, který používá stejnou e-mailovou adresu.

Podobně, pokud připojíte účet služby k prostředku, poté účet služby smažete a vytvoříte nový účet služby se stejným názvem, nový účet služby nebude k prostředku připojen.

Chcete-li tomuto neočekávanému chování zabránit, zvažte použití nového, jedinečného názvu pro každý účet služby. Také pokud omylem smažete účet služby, můžete se místo vytváření nového účtu služby pokusit účet služby smazat.

Pokud nemůžete původní účet služby smazat a potřebujete vytvořit nový účet služby se stejným názvem a stejnými rolemi, musíte tyto role novému účtu služby přidělit. Podrobnosti naleznete v části Zásady se smazanými členy.

Pokud potřebujete, aby byl nový účet služby připojen také ke stejným prostředkůmjako původní účet služby, proveďte jednu z následujících akcí:

• U instancí Compute Engine můžete změnit účet služby, který je připojen k instanci, a nahradit původní účet služby novým účtem služby.
• U všech ostatních prostředků musíte odstranit stávající prostředek, poté vytvořit nový prostředek stejného typu a připojit nový účet služby.

Oprávnění pro účty služeb

Tato část popisuje běžné scénáře pro oprávnění udělená účtům služeb nebo uživatelským účtům, které mají oprávnění vydávat se za účty služeb:

• Přiznání minimálních oprávnění servisním účtům
• Oprávnění servisních účtů pro běžné scénáře

Přiznání minimálních oprávnění servisním účtům

Stejně jako u všech typů členů byste měli servisnímu účtu přiznat pouze minimální sadu oprávnění potřebnou k dosažení jeho cíle. Přečtěte si o udělování rolí všem typům členů,včetně servisních účtů.

Při udělování oprávnění uživatelům pro přístup k servisnímu účtu mějte na paměti, že uživatel může přistupovat ke všem prostředkům, ke kterým má servisní účet oprávnění. Proto je důležité pečlivě konfigurovat oprávnění servisních účtů; to znamená, že je třeba přísně stanovit, kdo z vašeho týmu může vystupovat jako(nebo se vydávat za) servisní účet. Zvláště opatrní buďte při povolování uživatelům, aby se vydávali za vysoce privilegované účty služeb, jako jsou například výchozí účty služebCompute Engine a App Engine.

Uživatelé s rolemi IAM pro aktualizaci instancí App Engine a Compute Engine (napříkladApp Engine Deployernebo Compute Instance Admin) mohou efektivně spouštět kód jako účty služeb používané ke spuštění těchto instancí a nepřímo tak získat přístup ke všem prostředkům, ke kterým mají účty služeb přístup. Podobně může přístup SSH k instanci Compute Engine rovněž poskytovat možnost spouštět kód jako tato instance.

Oprávnění účtů služeb pro běžné scénáře

Účty služeb lze použít v mnoha různých scénářích a každý z nich vyžaduje určitá oprávnění. Tato část popisuje běžné scénáře a to, jaká oprávnění jsou vyžadována.

Připojení servisních účtů ke zdrojům

Pokud chcete spustit dlouhodobou úlohu, která se ověřuje jako servisní účet,musíte připojit servisní účet ke zdroji, který bude úlohu spouštět.

Oprávnění:

• Oprávnění k vytvoření prostředku
• iam.serviceAccounts.actAs

Chcete-li najít role, které obsahují tato oprávnění, vyhledejte je v seznamu rolí.

Existuje několik různých prostředků Google Cloud, které mohou spouštět dlouhodobé úlohy jako účty služeb. Mezi tyto prostředky patří například:

• Vizulární počítače Compute Engine
• Aplikace App Engine
• Cloudové funkce

Při vytváření těchto prostředků máte možnost připojit účet služby. Tento účet služby funguje jako identita prostředku.

Chcete-li vytvořit prostředek a připojit účet služby, potřebujete oprávnění k vytvoření tohoto prostředku a oprávnění k zosobnění účtu služby, který k prostředku připojíte. Oprávnění k zosobnění účtu služby poskytuje jakákoli role, která obsahuje oprávnění iam.serviceAccounts.actAs.

Po vytvoření prostředku a připojení účtu služby k němu můžete na prostředku spustit dlouhodobou úlohu. Úloha je spuštěna jako účet služby, který je k prostředku připojen, a používá tento účet služby k autorizaci požadavků na rozhraní API služby Google Cloud.

Další informace o připojování účtů služeb k prostředkům naleznete v částiPřipojení účtu služby k prostředku.

Přímé přiřazení účtu služby

Oprávnění:

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

Role:

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

Po udělení požadovaných oprávnění může uživatel (nebo služba) v několika běžných scénářích přímo zosobnit (nebo potvrdit) identitu účtu služby.

Nejprve může uživatel získat krátkodobé pověření k účtu služby pomocí oprávněníiam.serviceAccounts.getAccessToken a voláním metodygenerateAccessToken(). Pomocí krátkodobých pověření může uživatel vydávat příkazy do službyGoogle Cloud a může přistupovat ke všem prostředkům, ke kterým má účet službypřístup. Tento tok například umožňuje uživateli použít příznakgcloud --impersonate-service-account k zosobnění účtu služby, aniž by vyžadoval použití staženého externího klíče účtu služby.

Druhé, uživatel může získat artefakty podepsané soukromým klíčem účtu služby spravovaným společností Google pomocí oprávnění iam.serviceAccounts.signBlob a voláním metodysignBlob()nebosignJwt(). Soukromý klíč spravovaný společností Google je vždy uložen v úschově a nikdy není přímo vystaven. signBlob() umožňuje podepisování libovolných užitečných zátěží (například URL podepsaných cloudovým úložištěm), zatímco signJwt() umožňuje pouze podepisování dobře formulovaných JWT.

Nakonec se uživatel může vydávat za účet služby (nebo se k němu přihlásit), aniž by kdy získal pověření k účtu služby. Jedná se o pokročilý případ použití,který je podporován pouze pro programový přístup pomocígenerateAccessToken()metody. Ve scénářích s alespoň třemi účty služeb, a to A, B a C: účet služby A může získat přístupový token pro účet služby C, pokud je účtu služby A uděleno oprávněníiam.serviceAccounts.implicitDelegation na B a B je uděleno oprávnění iam.serviceAccounts.getAccessToken na C.

Generování ID tokenů OpenID Connect (OIDC)

Oprávnění:

• iam.serviceAccounts.getOpenIdToken

Role:

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

Uživatel (nebo služba) může generovat tokeny JWT kompatibilní s OpenID Connect (OIDC) podepsané poskytovatelem Google OIDC (účty.google.com), který reprezentuje identitu účtu služby pomocí iam.serviceAccounts.getOpenIdTokenoprávnění.

Tyto tokeny nejsou přímo akceptovány většinou rozhraní Google API, aniž by vaše organizace nasadila další federaci identit pro udělení přístupu ke služběGoogle. Existuje několik výjimek – například Identity-Aware Proxy, která umožňuje přístup k aplikacím spuštěným uživatelem na základěOIDC.

Generování externích soukromých klíčů

Oprávnění:

• iam.serviceAccountKeys.create

Role:

• roles/editor (Editor)
• roles/iam.serviceAccountAdmin (Správce účtu služby)

Uživatel nebo služba může generovat materiál externího soukromého klíče (RSA), který lze použít k ověření přímo ve společnosti Google jako účet služby. Tento klíčový materiál pak lze použít s knihovnami ADC (Application Default Credentials) nebo s příkazemgcloud auth activate-service-account. Každá osoba, která získá přístup k tomuto klíčovému materiálu, pak bude mít plnýpřístup ke všem prostředkům, ke kterým má účet služby přístup. S takovýmto materiálem privátních klíčů by se mělo zacházet s nejvyšší obavou a měl by být považován za méně bezpečný, čím déle tento materiál existuje. Proto je rotace materiálu soukromých klíčů rozhodující pro zachování silného zabezpečení.

Správa klíčů účtů služeb

Existují dva typy klíčů účtů služeb:

• Klíče spravované službou Google Cloud. Tyto klíče používají služby Google Cloudservices, například App Engine a Compute Engine. Nelze je stáhnout a jsou automaticky rotovány a používány k podepisování maximálně po dobu dvou týdnů. Proces rotace je pravděpodobnostní; používání nového klíče bude v průběhu jeho životnosti postupně narůstat a klesat. Doporučujeme ukládat sadu veřejných klíčů pro účet služby do mezipaměti maximálně na 24 hodin, abyste měli vždy přístup k aktuální sadě klíčů.

• Klíče spravované uživatelem. Tyto klíče vytvářejí, stahují a spravujíuživatelé. Po jejich odstranění ze servisního účtu je nelze použít k ověřování.

U klíčů spravovaných uživateli se musíte ujistit, že máte zavedeny procesy, které řeší požadavky na správu klíčů, např:

• Uložení klíčů
• Distribuce klíčů
• Odvolání klíčů
• Rotace klíčů
• Ochrana klíčů před neoprávněnými uživateli
• Obnovení klíčů

Kdokoli, kdo má přístup k platnému soukromému klíči účtu služby, bude moci přistupovat ke zdrojům prostřednictvím účtu služby. Všimněte si, že životní cyklus přístupu klíče k účtu služby (a tedy i k datům, ke kterým má účet služby přístup) je nezávislý na životním cyklu uživatele, který si klíč stáhl.

Vždy nedoporučujte vývojářům, aby klíče kontrolovali do zdrojového kódu nebo je nechávali v adresáři Downloads na své pracovní stanici.

Chcete-li zvýšit bezpečnost klíčů, postupujte podle následujících pokynů:

• Používejte rozhraní IAM service account API k automatické rotaci klíčů servisních účtů. Klíč můžete rotovat vytvořením nového klíče, přepnutím aplikací na používání nového klíče a následným vymazáním starého klíče. K automatické rotaci použijte společně metody serviceAccount.keys.create()a serviceAccount.keys.delete(). Klíče spravované službou Google Cloud se střídají přibližně jednou týdně.

  • K auditu účtů služeb a klíčů použijte metodu serviceAccount.keys.list().

Používání účtů služeb s Compute Engine

Instance Compute Engine musí běžet jako účty služeb, aby měly přístup k dalším prostředkům Google Cloud. Chcete-li zajistit větší bezpečnost instancíCompute Engine, zvažte následující:

• Ve stejném projektu můžete vytvořit virtuální počítače s různými účty služeb. Chcete-li změnit servisní účet virtuálního počítače po jeho vytvoření, použijte metoduinstances.setServiceAccount.

• Služebním účtům můžete přidělit role IAM a definovat tak, k čemu mají přístup. V mnoha případech se již nebudete muset spoléhat na obzory. To vám dává výhodu, že můžete měnit oprávnění servisního účtu VM, aniž byste museli instanci znovu vytvořit.

• Protože instance závisí na svých servisních účtech, aby měly přístup ke zdrojům služby Google Cloud, vyhněte se mazání servisních účtů, pokud jsou stále používány běžícími instancemi. Pokud účty služeb odstraníte, mohou instance začít selhávat ve svých operacích.

Nejlepší postupy

• Určete, kdo může vystupovat jako účty služeb. Uživatelé, kteří jsouUživatelé účtu služby pro účet služby, mohou nepřímo přistupovat ke všem prostředkům, ke kterým má účet služby přístup. Proto buďte obezřetní při přidělování roleUživatelserviceAccountUser uživateli.

• Udělte servisnímu účtu pouze minimální sadu oprávnění potřebnou k dosažení jeho cíle. Naučte se přidělovat role všem typům členů, včetně servisních účtů.

• Vytvořte servisní účty pro každou službu pouze s oprávněními požadovanými pro danou službu.

• Pro sledování servisních účtů používejte zobrazovaný název servisního účtu. Při vytváření účtu služby vyplňte jeho zobrazovací název účelem účtu služby.

• Definujte konvenci pro pojmenování účtů služby.

• Zavedení procesůautomatizace rotace klíčů účtů služby spravovaných uživatelem.

• Využijte rozhraní API službyIAM k zavedení rotace klíčů.

• Auditujte účty služeb a klíče pomocí metodyserviceAccount.keys.list() nebo stránkyLogs Viewer v konzoli.

• Neodstraňujte účty služeb, které používají spuštěné instance vApp Engine nebo Compute Engine, pokud nechcete, aby tyto aplikace ztratily přístup k účtu služeb.