Wg raportu Gartnera rynek chmur publicznych jest dość stały, przynajmniej w tym najważniejszych kwadracie, opisującym liderów – od lat są to niezmiennie Amazon Web Services, Microsoft Azure i właśnie Google Cloud.

Chmura Google idzie jednak w nieco innym kierunku niż konkurenci – np. jeśli chodzi o bazy danych, Amazon i Microsoft oferują w swoich chmurach usługi oparte o dobrze znane silniki MySQL i PostgreSQL (a Microsoft również swój SQL Server), a dopiero potem o swoje autorskie technologie, o tyle Google od samego początku motywuje użytkowników do korzystania ze swoich autorskich technologii – często lepszych technologicznie, ale jednocześnie przywiązujących użytkowników do ekosystemu Google (w sumie to samo można powiedzieć i o całej firmie Google).

Struktura uprawnień

Zarządzanie użytkownikami w Google Cloud dużo bardziej przypomina Azure niż AWS: również używany jest model kont federacyjnych (czyli w tym przypadku po prostu kont Google), a więc podstawowym podmiotem zabezpieczeń nie jest sztucznie stworzony użytkownik w ramach projektu Google Cloud, tylko konto imienne Google – dokładnie to samo, za pomocą którego można zalogować się do Gmaila, edytować arkusze kalkulacyjne w G-Suite itd. Jest to jednak model federacyjny, a więc konto Google jest luźno powiązane rolą (lub wieloma rolami) z projektem Google Cloud – podobnie jak np. w usłudze Google Analytics.

Model taki ma dość zasadniczą wadę z punktu widzenia użytkownika: zalogowanie się na konto Google w jednej zakładce przeglądarki wpływa również na inne zakładki – dlatego też ciężko jest używać kilku (a tym bardziej kilkunastu czy kilkudziesięciu) kont Google do różnych usług w ramach jednej przeglądarki. W przeciwieństwie do kont AWS, które po pierwsze są „sztuczne” (tj. nie muszą być z nikim powiązane imiennie, a jedynie ze sztucznie wykreowaną rolą) i służą tylko i wyłącznie do obsługi konsoli AWS, a po drugie bazują wyłącznie na ciasteczkach sesyjnych – nie kolidują więc z usługami typu poczta, kalendarz, G-Suite itp.

Znaczącą różnicą w stosunku do Azure (a tym bardziej do AWS) jest brak „konta głównego”, jakim w Azure jest Subskrypcja. Zamiast niego istnieją 2 osobne typy „obiektów głównych”:

• projekty – do nich są przypisywane role użytkowników (np. administrator, operator billingu, wyświetlający obiekty Cloud Storage itd.) – również sam billing i dane płatnościowe są kojarzone bezpośrednio z konkretnymi projektami
• organizacje – do nich są przypisywane pewne role globalne (administrator organizacji), oraz różne ustawienia związane z całą organizacją (RODO, globalne zasady bezpieczeństwa dla wszystkich projektów itp.)

Pojedyncze konto Google może być przypisane do wielu projektów, do każdego z innym zestawem ról (i wynikających z nich uprawnień).

Organizacja natomiast jest tożsama z główną domeną przypisaną do konta G-Suite (czyli najczęściej z domeną, w której jest utworzone imienne konto Google, z którego został utworzony projekt). Np. jeśli administrator Jan Kowalski ma konto jan.kowalski@payload.pl obsługiwane przez G-Suite i tworzy z poziomu tego konta nowy projekt Payload-Produkcja, to organizacja związana z tym projektem będzie się nazywać payload.pl.

Sposoby dostępu

W Google Cloud jest 5 głównych sposobów dostępu do usług:

• przez konsolę webową, po zalogowaniu na konto Google – a jeśli użytkownik ma przypisane uprawnienia do więcej niż jednego projektu, może się między nimi przełączać po zalogowaniu
• przez API Google Cloud jako „end user”, za pomocą OAuth2, konta Google zalogowanego w przeglądarce i wizyty na stronie https://accounts.google.com/o/oauth2/auth – metoda deweloperska
• przez API Google Cloud jako „service account”, za pomocą zmiennej środowiskowej GOOGLE_APPLICATION_CREDENTIALS i klucza prywatnego wskazywanego przez tą zmienną – metoda produkcyjna
• przez API Google Cloud z użyciem klucza API – metoda ta jest ograniczona do niektórych API i stosowana np. dla aplikacji mobilnych
• dedykowany dostęp do wybranych usług w specjalny sposób, np.:
  • logowanie ssh do instancji Compute Engine za pomocą klucza ssh (w przeciwieństwie do AWS, tworzonego wyłącznie lokalnie – treść klucza publicznego przekazywana jest każdorazowo przy tworzeniu instancji)
  • osobny system uprawnień w usłudze Kubernetes Engine
  • osobny system uprawnień w usłudze VMware Engine

Sposoby zapisu kluczy i innych danych dostępowych do API

Metoda produkcyjna

Jedyną istotną zmienną środowiskową o stałej nazwie jest GOOGLE_APPLICATION_CREDENTIALS – zawiera ona ścieżkę bezwzględną do klucza prywatnego. Klucz ten ma najczęściej postać pliku JSON, zawierającego m.in. zmienne o nazwach:

• project_id
• client_id
• client_email
• private_key_id
• private_key – tutaj jest właściwy klucz prywatny, w postaci jednej, bardzo długiej linii rozpoczynającej się od ciągu znaków -----BEGIN PRIVATE KEY----- i kończące się na -----END PRIVATE KEY-----, pomiędzy nimi są kolejne linie klucza prywatnego, rozdzielone znakami \n

Zmiennych tych jest nieco więcej, jednak wartości pozostałych zmiennych albo są stałe, albo można je wygenerować z powyższych.

Zamiast pliku JSON spotykane są też inne formaty plików, w szczególności JSON osadzony wewnątrz bazy Sqlite3, a także Yaml z właściwym kluczem prywatnym wydzielonym do osobnego pliku.

Metoda deweloperska i obsługa wielu kont

Klient może być też zalogowany na stałe do konta Google metodą deweloperską – wówczas aplikacja w ogóle nie musi przechowywać żadnych danych logowania, a jedynie nazwę projektu.

Wszystkie potrzebne dane zawarte są w 2 plikach Sqlite3:

• ~/.config/gcloud/access_tokens.db – tutaj jest bieżący token OAuth2
• ~/.config/gcloud/credentials.db – tutaj są dane autoryzujące i pozwalające regenerować ten token

Klient konsolowy gcloud może być jednocześnie zalogowany do kilku kont Google. W takim przypadku:

• nazwa domyślnego profilu znajduje się w pliku ~/.config/gcloud/active_config
• dane poszczególnych profili znajdują się w plikach ~/.config/gcloud/configurations/config_nazwa – w środku pliki te zawierają klucz „account” wskazujący na konto Google, będące kluczem do obu powyższych baz Sqlite3
• wyboru profilu w wywołaniach gcloud dokonuje się parametrem --configuration

Oprócz powyższych, w starszych instalacjach może się jeszcze znajdować katalog ~/.config/gcloud/legacy_credentials, a w nim pliki .boto i adc.json, zawierające niezbędne minimum danych do odnowienia tokena dostępowego, w wersji tekstowej (a więc łatwiejszej do przeszukania narzędziami typu grep).

Narzędzia do enumeracji zawartości kont Google Cloud

Rekomendowanym rozwiązaniem do enumeracji kont Google Cloud będzie projekt Polynimbus – jest to narzędzie typu inventory, zorientowane na codzienne, bardzo dogłębne skanowanie konta Google Cloud pod kątem wielu usług, oraz udostępnienie panelu webowego, w którym można nawigować po listach użytkowników i poszczególnych usług.