Context

Un cont de servicii este un tip special de cont Google destinat să reprezinte un utilizator non-uman care trebuie să se autentifice și să fie autorizat să acceseze date în API-urile Google.

În mod obișnuit, conturile de servicii sunt utilizate în scenarii cum ar fi:

• Executarea de sarcini de lucru pe mașini virtuale (VM).
• Executarea de sarcini de lucru pe stații de lucru sau centre de date locale care apelează la API-uriGoogle.
• Executarea de sarcini de lucru care nu sunt legate de ciclul de viață al unui utilizator uman.

Aplicația dvs. își asumă identitatea contului de serviciu pentru a apela API-urile Google,astfel încât utilizatorii nu sunt implicați direct.

Managementul conturilor de servicii

După ce decideți că aveți nevoie de un cont de servicii, vă puteți pune următoareleîntrebări pentru a înțelege cum veți utiliza contul de servicii:

• Ce resurse poate accesa contul de servicii?
• De ce permisiuni are nevoie contul de servicii?
• Unde va fi rulat codul care își asumă identitatea contului de servicii – în Google Cloud sau la fața locului?

Utilizați următoarea organigramă pentru a afla răspunsurile la întrebările de mai sus:

Rețineți că conturile de serviciu pot fi considerate atât ca sursă, cât și ca identitate.

Când vă gândiți la contul de servicii ca la o identitate, puteți acorda un rol unui cont de servicii, permițându-i să acceseze o resursă (cum ar fi un proiect).

Când vă gândiți la un cont de servicii ca la o resursă, puteți acorda roluri altorutilizatori pentru a accesa sau gestiona acel cont de servicii.

Acordarea accesului la conturile de servicii

Accesul la un cont de servicii pentru a accesa o resursă este similar cu acordareaaccesului la orice altă identitate. De exemplu, dacă aveți o aplicație care rulează peCompute Engine și doriți ca aplicația să aibă acces numai pentru a crea obiecte în Cloud Storage. Puteți crea un cont de serviciu pentru aplicație și îi puteți acorda rolul Storage Object Creator.Următoarea diagramă ilustrează acest exemplu:

Învățați despreAcordarea de roluri tuturor tipurilor de membri, inclusiv conturilor de serviciu.

Supravegherea conturilor de servicii

În timp, pe măsură ce creați din ce în ce mai multe conturi de servicii, s-ar putea să pierdeți noțiunea de ce cont de servicii este utilizat în ce scop.

Numele de afișare al unui cont de servicii este o modalitate bună de a capta informații suplimentare despre contul de servicii, cum ar fi scopul contului de servicii sau o persoană de contact pentru contul respectiv. Pentru conturile de servicii noi, puteți completa numele de afișare atunci când creați contul de servicii. Pentru conturile de servicii existente, utilizați metoda serviceAccounts.update() pentru a modifica numele de afișare.

Identificarea conturilor de servicii neutilizate

Conturile de servicii neutilizate creează un risc de securitate inutil, așa că vă recomandăm să dezactivați conturile de servicii neutilizate, apoi să ștergeți conturile de servicii atunci când sunteți sigur că nu mai aveți nevoie de ele. Puteți utiliza următoarele metode pentru a identifica conturile de servicii nefolosite:

• Service account insights vă spune ce conturi de servicii din proiectul dumneavoastră nu s-au autentificat în ultimele 90 de zile.
• Service account usage metrics vă permite să verificați când a fost utilizat ultima dată un cont de servicii.

Ștergerea și recrearea conturilor de servicii

Este posibil să ștergeți un cont de servicii și apoi să creați un nou cont de servicii cu același nume.

Când ștergeți un cont de servicii, legăturile sale de rol nu sunt șterse imediat. În schimb, legăturile de roluri listează contul de servicii cu prefixuldeleted:. Pentru un exemplu, consultați Politici cu membri șterși.

Dacă creați un nou cont de serviciu cu același nume ca un cont de serviciu recent șters, vechile legături pot exista în continuare; cu toate acestea, ele nu se vor aplica noului cont de serviciu, chiar dacă ambele conturi au aceeași adresă de e-mail. Acest comportament apare deoarece conturilor de servicii li se atribuie un ID unic în cadrul Identity and Access Management (IAM) la creare. Pe plan intern, toate legăturile de roluri sunt acordate folosind aceste ID-uri, nu adresa de e-mail a contului de serviciu. Prin urmare, orice legături de rol care au existat pentru un cont de serviciu șters nu se aplică unui cont de serviciu nou care utilizează aceeași adresă de e-mail.

În mod similar, dacă atașați un cont de serviciu la o resursă, apoi ștergeți contul de serviciu și creați un nou cont de serviciu cu același nume,noul cont de serviciu nu va fi atașat la resursă.

Pentru a preveni acest comportament neașteptat, luați în considerare utilizarea unui nume nou, unic pentru fiecare cont de serviciu. De asemenea, dacă ștergeți din greșeală un cont de servicii, puteți încerca să anulați ștergerea contului de servicii în loc să creați un nou cont de servicii.

Dacă nu puteți anula contul de servicii original și trebuie să creați un nou cont de servicii cu același nume și cu aceleași roluri, trebuie să acordați aceste roluri noului cont de servicii. Pentru detalii, consultațiPolitici cu membri șterși.

Dacă aveți nevoie, de asemenea, ca noul cont de servicii să fie atașat la aceleași resurseca și contul de servicii original, efectuați una dintre următoarele:

• Pentru instanțele Compute Engine, puteți modifica contul de servicii care este atașat instanțeipentru a înlocui contul de servicii original cu noul cont de servicii.
• Pentru toate celelalte resurse, trebuie să ștergeți resursa existentă, apoi să creați o nouă resursă de același tip și să atașați noul cont de servicii.

Permisiuni pentru conturile de servicii

Această secțiune descrie scenarii comune pentru permisiunile acordate conturilor de servicii sau conturilor de utilizatori care au permisiuni de a se substitui conturilor de servicii:

• Acordarea permisiunilor minime conturilor de servicii
• Permisiunile conturilor de servicii pentru scenarii comune

Acordarea permisiunilor minime conturilor de servicii

Ca și în cazul tuturor tipurilor de membri, trebuie să acordați contului de servicii numai setul minim de permisiuni necesare pentru a-și atinge obiectivul. Aflați despreacordarea de roluri tuturor tipurilor de membri,inclusiv conturilor de servicii.

Când acordați permisiuni utilizatorilor pentru a accesa un cont de servicii, rețineți că utilizatorul poate accesa toate resursele pentru care contul de servicii arepermisii. Prin urmare, este important să configurați cu atenție permisiunile conturilor de servicii; adică, fiți stricți în ceea ce privește persoanele din echipa dumneavoastră care pot acționa ca (sau pot impersona) un cont de servicii. Fiți deosebit de precauți atunci când permiteți utilizatorilor să impersoneze conturi de servicii cu privilegii ridicate, cum ar fi conturile de servicii DefaultCompute Engine și App Enginedefault.

Utilizatorii cu roluri IAM pentru actualizarea instanțelor App Engine și Compute Engine (cum ar fiApp Engine Deployer sau Compute Instance Admin) pot rula efectiv codul ca și conturile de servicii utilizate pentru a rula aceste instanțe și, indirect, pot obține acces la toate resursele pentru care conturile de servicii au acces. În mod similar,accesul SSH la o instanță Compute Engine poate oferi, de asemenea, posibilitatea de a executa cod ca acea instanță.

Permisiuni pentru conturi de servicii pentru scenarii comune

Conturile de servicii pot fi utilizate în multe scenarii diferite, iar fiecare dintre ele necesită anumite permisiuni. Această secțiune descrie scenarii comune și ce permisiuni sunt necesare.

Ajustarea conturilor de serviciu la resurse

Dacă doriți să porniți o lucrare de lungă durată care se autentifică ca un cont de serviciu,trebuie să atașați un cont de serviciu la resursa care va rula lucrarea.

Permisiuni:

• Permisiuni pentru a crea resursa
• iam.serviceAccounts.actAs

Pentru a găsi rolurile care includ aceste permisiuni, căutați în lista de roluri pentru aceste permisiuni.

Există mai multe resurse Google Cloud diferite care pot rula lucrări cu execuție prelungită ca și conturi de servicii. Câteva exemple de aceste resurse includ:

• Compute Engine VMs
• App Engine apps
• Cloud Functions

Când creați aceste resurse, aveți opțiunea de a atașa un cont de serviciu. Acest cont de serviciu acționează ca identitate a resursei.

Pentru a crea o resursă și a atașa un cont de serviciu, aveți nevoie de permisiuni pentru a crea acea resursă și de permisiunea de a impersonifica contul de serviciu pe care îl veți atașa la resursă. Permisiunea de a personifica contul de servicii este furnizată de orice rol care include permisiunea iam.serviceAccounts.actAs.

După ce creați resursa și îi atașați un cont de servicii, puteți începe o lucrare de lungă durată pe resursă. Lucrarea se execută ca cont de serviciu care este atașat la resursă și utilizează acel cont de serviciu pentru a autoriza cereri către API-urile Google Cloud.

Pentru a afla mai multe despre atașarea conturilor de serviciu la resurse, consultațiAjustarea unui cont de serviciu la o resursă.

Închipuirea directă a unui cont de serviciu

Permisiuni:

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

Roles:

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

După ce i s-au acordat permisiunile necesare, un utilizator (sau un serviciu) poate să imprime (sau să afirme) direct identitatea unui cont de serviciu în câteva scenarii comune.

În primul rând, utilizatorul poate obține credențiale pe termen scurt pentru contul de serviciu folosind permisiuneaiam.serviceAccounts.getAccessToken și apelând metodagenerateAccessToken(). Prin utilizarea acreditărilor pe termen scurt, un utilizator poate emite comenzi cătreGoogle Cloud și poate accesa toate resursele la care contul de servicii areacces. De exemplu, acest flux permite unui utilizator să utilizeze markerulgcloud --impersonate-service-account pentru a se substitui contului de servicii fără a fi necesară utilizarea unei chei de cont de servicii externe descărcate.

În al doilea rând, utilizatorul poate obține artefacte semnate de cheia privată gestionată de Google a contului de servicii utilizând permisiunea iam.serviceAccounts.signBlob și apelând fie metodasignBlob(), fie metodasignJwt(). Cheia privată administrată de Google este întotdeauna păstrată în custodie și nu este niciodată expusă în mod direct. signBlob() permite semnarea de sarcini utile arbitrare (cum ar fi URL-urile semnate de Cloud Storage), în timp ce signJwt() permite doar semnarea de JWT-uri bine formate.

În cele din urmă, utilizatorul poate impersona (sau afirma) contul de servicii fără a recupera vreodată o credențială pentru contul de servicii. Acesta este un caz de utilizare avansată,și este acceptat numai pentru accesul programatic folosind metodagenerateAccessToken(). În scenarii cu cel puțin 3 conturi de servicii, și anume A, B și C: contul de servicii A poate obține un jeton de acces pentru contul de servicii C dacă contului de servicii A i se acordă permisiuneaiam.serviceAccounts.implicitDelegation pentru B, iar lui B i se acordă permisiunea iam.serviceAccounts.getAccessToken pentru C.

Generarea token-urilor de identificare OpenID Connect (OIDC)

Permisiuni:

• iam.serviceAccounts.getOpenIdToken

Roles:

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

Un utilizator (sau serviciu) poate genera un token JWT compatibil cu OpenID Connect (OIDC) semnat de furnizorul Google OIDC (conturi.google.com) care reprezintă identitatea contului de serviciu care utilizează permisiunea iam.serviceAccounts.getOpenIdToken.

Aceste token-uri nu sunt acceptate direct de majoritatea API-urilor Google fără ca organizația dvs. să implementeze o federație de identitate suplimentară pentru a acorda acces laGoogle. Există câteva excepții – de exemplu, Identity-Aware Proxy, care permite accesul bazat peOIDC la aplicațiile gestionate de utilizatori.

Generarea cheilor private externe

Permisiuni:

• iam.serviceAccountKeys.create

Role:

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

Un utilizator sau un serviciu poate genera un material extern de chei private (RSA) care poate fi utilizat pentru a se autentifica direct la Google ca și cont de serviciu. Acest material de chei poate fi apoi utilizat cu bibliotecile Application Default Credentials (ADC),sau cu comandagcloud auth activate-service-account. Orice persoană care obține acces la materialul cheie va avea apoi acces deplin la toate resursele la care are acces contul de servicii. Un astfel de material cu cheie privată trebuie tratat cu cea mai mare grijă și trebuie considerat mai puțin sigur cu cât materialul există mai mult timp. Prin urmare, rotirea materialului de chei private este esențială pentru menținerea unei securități puternice.

Managementul cheilor de cont de serviciu

Există două tipuri de chei de cont de serviciu:

• Chei gestionate de Google Cloud. Aceste chei sunt utilizate de serviciile Google Cloudservices, cum ar fi App Engine și Compute Engine. Ele nu pot fi descărcate și sunt rotite automat și utilizate pentru semnare timp de maximum două săptămâni. Procesul de rotație este probabilistic; utilizarea noii chei va crește și va scădea treptat pe durata de viață a cheii. Recomandăm stocarea în memoria cache a setului de chei publice pentru un cont de servicii pentru cel mult 24 de ore pentru a vă asigura că aveți întotdeauna acces la setul de chei curent.

• Chei gestionate de utilizator. Aceste chei sunt create, descărcabile și gestionate de cătreutilizatori. După ce le ștergeți din contul de serviciu, nu le puteți utiliza pentruautentificare.

Pentru cheile gestionate de utilizator, trebuie să vă asigurați că aveți procese în vigoare pentruadresarea cerințelor de gestionare a cheilor, cum ar fi:

• Stocarea cheilor
• Distribuirea cheilor
• Revocarea cheilor
• Rotația cheilor
• Protejarea cheilor împotriva utilizatorilor neautorizați
• Recuperarea cheilor

Cineva care are acces la o cheie privată valabilă pentru un cont de servicii va puteaaccesa la resurse prin intermediul contului de servicii. Rețineți că ciclul de viață al cheii de acces la contul de servicii (și, prin urmare, datele la care are acces contul de servicii) este independent de ciclul de viață al utilizatorului care a descărcat cheia.

Descurajați întotdeauna dezvoltatorii să verifice cheile în codul sursă sau să le lase în directorul Downloads al stației lor de lucru.

Pentru a spori securitatea cheilor, urmați îndrumările de mai jos:

• Utilizați API-ul contului de servicii IAM pentru a roti automat cheile contului de servicii. Puteți roti o cheie princrearea unei noi chei, schimbarea aplicațiilor pentru a utiliza noua cheie și apoi ștergerea cheii vechi. Utilizați metodele serviceAccount.keys.create()și serviceAccount.keys.delete() împreună pentru a automatiza rotația. Cheile administrate de Google Cloud sunt rotite aproximativ o dată pe săptămână.

  • Utilizați metoda serviceAccount.keys.list() pentru a verifica conturile de servicii și cheile.

Utilizarea conturilor de servicii cu Compute Engine

Instalațiile Compute Engine trebuie să ruleze ca și conturi de servicii pentru a avea acces la alte resurse Google Cloud. Pentru a vă asigura că instanțeleCompute Engine sunt mai sigure, luați în considerare următoarele:

• Puteți crea VM-uri în același proiect cu conturi de servicii diferite. Pentru a schimba contul de serviciu al unei VM după ce a fost creată, utilizați metodainstances.setServiceAccount.

• Puteți acorda roluri IAM conturilor de serviciupentru a defini ce pot accesa. În multe cazuri, nu va mai fi nevoie să vă bazați pe lunete. Acest lucru vă oferă avantajul de a putea modifica permisiunile unui cont de servicii al unei MV fără a recrea instanța.

• Din moment ce instanțele depind de conturile lor de servicii pentru a avea acces la resursele Google Cloud, evitați să ștergeți conturile de servicii atunci când acestea sunt încă folosite de instanțele în curs de execuție. Dacă ștergeți conturile de servicii, este posibil ca instanțele să înceapă să eșueze în operațiunile lor.

Bune practici

• Specificați cine poate acționa ca și conturi de servicii. Utilizatorii care suntutilizatori de cont de serviciupentru un cont de serviciu pot avea acces indirect la toate resursele la care are acces contul de serviciu. Prin urmare, fiți precaut atunci când acordați rolul de utilizator al contului de serviciu unui utilizator.

• Ajungeți contului de serviciu doar setul minim de permisiuni necesare pentru a-și atinge obiectivul. Învățați cum să acordați roluri tuturor tipurilor de membri, inclusiv conturilor de servicii.

• Creați conturi de servicii pentru fiecare serviciu numai cu permisiunile necesare pentru acel serviciu.

• Utilizați numele de afișare al unui cont de servicii pentru a ține evidența conturilor de servicii. Când creați un cont de servicii, completați numele de afișare al acestuia cu scopul contului de servicii.

Definiți o convenție de denumire pentru conturile de servicii.

• Implementați procesepentru a automatiza rotația cheilor conturilor de servicii gestionate de utilizatori.

• Utilizați API-ul conturilor de serviciiIAM pentru a implementa rotația cheilor.

• Auditați conturile de servicii și cheile folosind fie metodaserviceAccount.keys.list(), fie paginaLogs Viewer din consolă.

• Nu ștergeți conturile de servicii care sunt utilizate de instanțele care rulează peApp Engine sau Compute Engine decât dacă doriți ca acele aplicații să nu mai aibă acces la contul de servicii.