mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -4,12 +4,12 @@
|
||||
|
||||
## **Z GCP do GWS**
|
||||
|
||||
### **Podstawy delegacji w całej domenie**
|
||||
### **Podstawy delegacji w skali domeny**
|
||||
|
||||
Delegacja w całej domenie Google Workspace pozwala obiektowi tożsamości, czy to **zewnętrznej aplikacji** z Google Workspace Marketplace, czy wewnętrznemu **Konto usługi GCP**, na **dostęp do danych w całym Workspace w imieniu użytkowników**.
|
||||
Delegacja w skali domeny Google Workspace pozwala obiektowi tożsamości, czy to **zewnętrznej aplikacji** z Google Workspace Marketplace, czy wewnętrznemu **Konto usługi GCP**, na **dostęp do danych w całym Workspace w imieniu użytkowników**.
|
||||
|
||||
> [!NOTE]
|
||||
> Oznacza to zasadniczo, że **kontakty usług** wewnątrz projektów GCP organizacji mogą być w stanie **udawać użytkowników Workspace** tej samej organizacji (lub nawet z innej).
|
||||
> Oznacza to zasadniczo, że **kontakty usługowe** w projektach GCP organizacji mogą być w stanie **udawać użytkowników Workspace** tej samej organizacji (lub nawet z innej).
|
||||
|
||||
Aby uzyskać więcej informacji na temat tego, jak to dokładnie działa, sprawdź:
|
||||
|
||||
@@ -19,16 +19,16 @@ gcp-understanding-domain-wide-delegation.md
|
||||
|
||||
### Kompromitacja istniejącej delegacji
|
||||
|
||||
Jeśli atakujący **skomprymował jakiś dostęp do GCP** i **zna ważny adres e-mail użytkownika Workspace** (najlepiej **super admina**) firmy, mógłby **wyliczyć wszystkie projekty**, do których ma dostęp, **wyliczyć wszystkie SA** projektów, sprawdzić, do których **kont usług ma dostęp**, i **powtórzyć** wszystkie te kroki z każdym SA, którego może udawać.\
|
||||
Mając **listę wszystkich kont usług**, do których ma **dostęp**, oraz listę **adresów e-mail Workspace**, atakujący mógłby spróbować **udawać użytkownika z każdym kontem usługi**.
|
||||
Jeśli atakujący **skomprymował dostęp do GCP** i **zna ważny adres e-mail użytkownika Workspace** (najlepiej **super admina**) firmy, mógłby **wyliczyć wszystkie projekty**, do których ma dostęp, **wyliczyć wszystkie SA** projektów, sprawdzić, do których **kont usług ma dostęp**, i **powtórzyć** te kroki z każdym SA, którego może udawać.\
|
||||
Mając **listę wszystkich kont usługowych**, do których ma **dostęp**, oraz listę **e-maili Workspace**, atakujący mógłby spróbować **udawać użytkownika z każdym kontem usługi**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Zauważ, że podczas konfigurowania delegacji w całej domenie nie jest potrzebny żaden użytkownik Workspace, dlatego wystarczy **znać jeden ważny, aby było to wymagane do udawania**.\
|
||||
> Zauważ, że podczas konfigurowania delegacji w skali domeny nie jest potrzebny żaden użytkownik Workspace, dlatego wystarczy **znać jednego ważnego, aby było to wymagane do udawania**.\
|
||||
> Jednak **uprawnienia udawanego użytkownika będą używane**, więc jeśli to Super Admin, będziesz mógł uzyskać dostęp do wszystkiego. Jeśli nie ma żadnego dostępu, to będzie bezużyteczne.
|
||||
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
Ten prosty skrypt **wygeneruje token OAuth jako delegowany użytkownik**, który możesz następnie użyć do uzyskania dostępu do innych interfejsów API Google z lub bez `gcloud`:
|
||||
Ten prosty skrypt **wygeneruje token OAuth jako delegowany użytkownik**, którego możesz następnie użyć do uzyskania dostępu do innych interfejsów API Google z lub bez `gcloud`:
|
||||
```bash
|
||||
# Impersonate indicated user
|
||||
python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-key-file>
|
||||
@@ -38,15 +38,15 @@ python3 gen_delegation_token.py --user-email <user-email> --key-file <path-to-ke
|
||||
```
|
||||
#### [**DeleFriend**](https://github.com/axon-git/DeleFriend)
|
||||
|
||||
To jest narzędzie, które może przeprowadzić atak, wykonując następujące kroki:
|
||||
To narzędzie, które może przeprowadzić atak, wykonując następujące kroki:
|
||||
|
||||
1. **Enumerate GCP Projects** przy użyciu Resource Manager API.
|
||||
2. Iteruj po każdym zasobie projektu i **enumerate GCP Service account resources**, do których ma dostęp początkowy użytkownik IAM, używając _GetIAMPolicy_.
|
||||
3. Iteruj po **każdej roli konta usługi** i znajdź wbudowane, podstawowe i niestandardowe role z uprawnieniem _**serviceAccountKeys.create**_ na docelowym zasobie konta usługi. Należy zauważyć, że rola Edytora z natury posiada to uprawnienie.
|
||||
4. Utwórz **nowy `KEY_ALG_RSA_2048`** klucz prywatny dla każdego zasobu konta usługi, które zostało znalezione z odpowiednim uprawnieniem w polityce IAM.
|
||||
5. Iteruj po **każdym nowym koncie usługi i utwórz obiekt `JWT`**, który składa się z poświadczeń klucza prywatnego SA i zakresu OAuth. Proces tworzenia nowego obiektu _JWT_ będzie **iterować po wszystkich istniejących kombinacjach zakresów OAuth** z listy **oauth_scopes.txt**, aby znaleźć wszystkie możliwości delegacji. Lista **oauth_scopes.txt** jest aktualizowana o wszystkie zakresy OAuth, które uznaliśmy za istotne dla nadużywania tożsamości Workspace.
|
||||
6. Metoda `_make_authorization_grant_assertion` ujawnia konieczność zadeklarowania **docelowego użytkownika workspace**, określanego jako _subject_, do generowania JWT pod DWD. Chociaż może się wydawać, że wymaga to konkretnego użytkownika, ważne jest, aby zrozumieć, że **DWD wpływa na każdą tożsamość w domenie**. W związku z tym, tworzenie JWT dla **dowolnego użytkownika domeny** wpływa na wszystkie tożsamości w tej domenie, zgodnie z naszym sprawdzeniem enumeracji kombinacji. Mówiąc prosto, jeden ważny użytkownik Workspace jest wystarczający, aby kontynuować.\
|
||||
Ten użytkownik może być zdefiniowany w pliku _config.yaml_ DeleFriend. Jeśli docelowy użytkownik workspace nie jest jeszcze znany, narzędzie ułatwia automatyczne identyfikowanie ważnych użytkowników workspace, skanując użytkowników domeny z rolami w projektach GCP. Kluczowe jest ponowne zauważenie, że JWT są specyficzne dla domeny i nie są generowane dla każdego użytkownika; dlatego automatyczny proces celuje w jedną unikalną tożsamość na domenę.
|
||||
5. Iteruj po **każdym nowym koncie usługi i utwórz obiekt `JWT`**, który składa się z poświadczeń klucza prywatnego SA i zakresu OAuth. Proces tworzenia nowego obiektu _JWT_ będzie **iterować po wszystkich istniejących kombinacjach zakresów OAuth** z listy **oauth_scopes.txt**, aby znaleźć wszystkie możliwości delegacji. Lista **oauth_scopes.txt** jest aktualizowana o wszystkie zakresy OAuth, które uznaliśmy za istotne do nadużywania tożsamości Workspace.
|
||||
6. Metoda `_make_authorization_grant_assertion` ujawnia konieczność zadeklarowania **docelowego użytkownika workspace**, określanego jako _subject_, do generowania JWT pod DWD. Chociaż może się wydawać, że wymaga to konkretnego użytkownika, ważne jest, aby zrozumieć, że **DWD wpływa na każdą tożsamość w domenie**. W związku z tym, tworzenie JWT dla **dowolnego użytkownika domeny** wpływa na wszystkie tożsamości w tej domenie, zgodnie z naszą kontrolą enumeracji kombinacji. Mówiąc prosto, jeden ważny użytkownik Workspace jest wystarczający, aby przejść dalej.\
|
||||
Ten użytkownik może być zdefiniowany w pliku _config.yaml_ DeleFriend. Jeśli docelowy użytkownik workspace nie jest jeszcze znany, narzędzie ułatwia automatyczne identyfikowanie ważnych użytkowników workspace poprzez skanowanie użytkowników domeny z rolami w projektach GCP. Kluczowe jest ponowne zauważenie, że JWT są specyficzne dla domeny i nie są generowane dla każdego użytkownika; dlatego automatyczny proces celuje w jedną unikalną tożsamość na domenę.
|
||||
7. **Enumerate and create a new bearer access token** dla każdego JWT i zweryfikuj token za pomocą tokeninfo API.
|
||||
|
||||
#### [Gitlab's Python script](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
@@ -80,9 +80,9 @@ Możliwe jest **sprawdzenie delegacji w całej domenie w** [**https://admin.goog
|
||||
Napastnik, który ma możliwość **tworzenia kont serwisowych w projekcie GCP** oraz **uprawnienia super administratora do GWS, może utworzyć nową delegację, pozwalającą kontom serwisowym na podszywanie się pod niektórych użytkowników GWS:**
|
||||
|
||||
1. **Generowanie nowego konta serwisowego i odpowiadającej pary kluczy:** W GCP nowe zasoby kont serwisowych mogą być tworzone interaktywnie za pomocą konsoli lub programowo przy użyciu bezpośrednich wywołań API i narzędzi CLI. Wymaga to **roli `iam.serviceAccountAdmin`** lub dowolnej niestandardowej roli wyposażonej w **uprawnienie `iam.serviceAccounts.create`**. Po utworzeniu konta serwisowego przystąpimy do generowania **odpowiedniej pary kluczy** (**uprawnienie `iam.serviceAccountKeys.create`**).
|
||||
2. **Utworzenie nowej delegacji**: Ważne jest, aby zrozumieć, że **tylko rola Super Admin ma możliwość skonfigurowania globalnej delegacji w całej domenie w Google Workspace** i delegacja w całej domenie **nie może być skonfigurowana programowo,** może być tworzona i dostosowywana **ręcznie** za pośrednictwem konsoli Google Workspace.
|
||||
2. **Utworzenie nowej delegacji:** Ważne jest, aby zrozumieć, że **tylko rola Super Admin ma możliwość skonfigurowania globalnej delegacji w całej domenie w Google Workspace** i delegacja w całej domenie **nie może być skonfigurowana programowo,** może być tworzona i dostosowywana **ręcznie** za pośrednictwem konsoli Google Workspace.
|
||||
- Utworzenie reguły można znaleźć na stronie **API controls → Manage Domain-Wide delegation in Google Workspace Admin console**.
|
||||
3. **Przypisanie uprawnień zakresów OAuth**: Podczas konfigurowania nowej delegacji Google wymaga tylko 2 parametrów, identyfikatora klienta, który jest **identyfikatorem OAuth zasobu konta serwisowego GCP**, oraz **zakresów OAuth**, które definiują, jakie wywołania API są wymagane przez delegację.
|
||||
3. **Przypisanie uprawnień zakresów OAuth:** Podczas konfigurowania nowej delegacji Google wymaga tylko 2 parametrów, identyfikatora klienta, który jest **identyfikatorem OAuth zasobu konta serwisowego GCP**, oraz **zakresów OAuth**, które definiują, jakie wywołania API są wymagane przez delegację.
|
||||
- **Pełna lista zakresów OAuth** jest dostępna [**tutaj**](https://developers.google.com/identity/protocols/oauth2/scopes), ale oto rekomendacja: `https://www.googleapis.com/auth/userinfo.email, https://www.googleapis.com/auth/cloud-platform, https://www.googleapis.com/auth/admin.directory.group, https://www.googleapis.com/auth/admin.directory.user, https://www.googleapis.com/auth/admin.directory.domain, https://mail.google.com/, https://www.googleapis.com/auth/drive, openid`
|
||||
4. **Działanie w imieniu docelowej tożsamości:** Na tym etapie mamy działający obiekt delegacji w GWS. Teraz, **używając prywatnego klucza konta serwisowego GCP, możemy wykonywać wywołania API** (w zakresie zdefiniowanym w parametrze zakresu OAuth), aby go uruchomić i **działać w imieniu dowolnej tożsamości, która istnieje w Google Workspace**. Jak się dowiedzieliśmy, konto serwisowe wygeneruje tokeny dostępu zgodnie z jego potrzebami i w zależności od uprawnień, jakie ma do aplikacji REST API.
|
||||
- Sprawdź **poprzednią sekcję** w celu uzyskania **narzędzi** do wykorzystania tej delegacji.
|
||||
@@ -93,11 +93,11 @@ Identyfikator SA OAuth jest globalny i może być używany do **delegacji międz
|
||||
|
||||
### Tworzenie projektu do enumeracji Workspace
|
||||
|
||||
Zgodnie z **domyślnymi ustawieniami** użytkownicy Workspace mają uprawnienia do **tworzenia nowych projektów**, a gdy nowy projekt jest tworzony, **twórca otrzymuje rolę właściciela**.
|
||||
Z **domyślnie** użytkownicy Workspace **mają uprawnienia do** **tworzenia nowych projektów**, a gdy nowy projekt jest tworzony, **twórca otrzymuje rolę właściciela**.
|
||||
|
||||
Dlatego użytkownik może **utworzyć projekt**, **włączyć** **API** do enumeracji Workspace w swoim nowym projekcie i spróbować **enumerować** go.
|
||||
|
||||
> [!CAUTION]
|
||||
> [!OSTRZEŻENIE]
|
||||
> Aby użytkownik mógł enumerować Workspace, musi również mieć wystarczające uprawnienia Workspace (nie każdy użytkownik będzie mógł enumerować katalog).
|
||||
```bash
|
||||
# Create project
|
||||
@@ -127,7 +127,7 @@ Sprawdź **więcej enumeracji w**:
|
||||
Możesz znaleźć dalsze informacje na temat przepływu `gcloud` do logowania w:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Jak tam wyjaśniono, gcloud może żądać zakresu **`https://www.googleapis.com/auth/drive`**, co pozwoliłoby użytkownikowi uzyskać dostęp do dysku użytkownika.\
|
||||
@@ -152,9 +152,9 @@ Jeśli atakujący ma pełny dostęp do GWS, będzie mógł uzyskać dostęp do g
|
||||
|
||||
### Eskalacja uprawnień Google Groups
|
||||
|
||||
Domyślnie użytkownicy mogą **swobodnie dołączać do grup Workspace w Organizacji**, a te grupy **mogą mieć przypisane uprawnienia GCP** (sprawdź swoje grupy w [https://groups.google.com/](https://groups.google.com/)).
|
||||
Domyślnie użytkownicy mogą **swobodnie dołączać do grup Workspace w Organizacji** i te grupy **mogą mieć przypisane uprawnienia GCP** (sprawdź swoje grupy w [https://groups.google.com/](https://groups.google.com/)).
|
||||
|
||||
Wykorzystując **google groups privesc**, możesz być w stanie eskalować do grupy z jakimś rodzajem uprzywilejowanego dostępu do GCP.
|
||||
Wykorzystując **eskalację uprawnień google groups**, możesz być w stanie eskalować do grupy z jakimś rodzajem uprzywilejowanego dostępu do GCP.
|
||||
|
||||
### Referencje
|
||||
|
||||
|
||||
@@ -39,7 +39,7 @@ Obecnie to nie działa, ale jeśli **dajesz ofierze dostęp do dokumentu**, Goog
|
||||
|
||||
## Phishing w Google Calendar
|
||||
|
||||
Możesz **utworzyć wydarzenie w kalendarzu** i dodać tyle adresów e-mail firmy, którą atakujesz, ile masz. Zaplanuj to wydarzenie w **5 lub 15 minut** od aktualnego czasu. Spraw, aby wydarzenie wyglądało legitnie i **dodaj komentarz oraz tytuł wskazujący, że muszą coś przeczytać** (z **linkiem phishingowym**).
|
||||
Możesz **utworzyć wydarzenie kalendarza** i dodać tyle adresów e-mail firmy, którą atakujesz, ile masz. Zaplanuj to wydarzenie kalendarza na **5 lub 15 minut** od aktualnego czasu. Spraw, aby wydarzenie wyglądało legitnie i **dodaj komentarz oraz tytuł wskazujący, że muszą coś przeczytać** (z **linkiem phishingowym**).
|
||||
|
||||
To jest alert, który pojawi się w przeglądarce z tytułem spotkania "Zwalnianie ludzi", więc możesz ustawić bardziej phishingowy tytuł (a nawet zmienić nazwisko powiązane z twoim e-mailem).
|
||||
|
||||
@@ -53,7 +53,7 @@ Aby wyglądało to mniej podejrzanie:
|
||||
|
||||
## Phishing z przekierowaniem skryptów aplikacji
|
||||
|
||||
Możliwe jest stworzenie skryptu w [https://script.google.com/](https://script.google.com/) i **udostępnienie go jako aplikacji webowej dostępnej dla wszystkich**, która będzie używać legalnej domeny **`script.google.com`**.\
|
||||
Możliwe jest stworzenie skryptu w [https://script.google.com/](https://script.google.com/) i **udostępnienie go jako aplikacji internetowej dostępnej dla wszystkich**, która będzie używać legalnej domeny **`script.google.com`**.\
|
||||
Z kodem takim jak poniżej, atakujący mógłby sprawić, że skrypt załadowałby dowolną treść na tej stronie bez przestawania dostępu do domeny:
|
||||
```javascript
|
||||
function doGet() {
|
||||
@@ -71,7 +71,7 @@ Na przykład, uzyskując dostęp do [https://script.google.com/macros/s/AKfycbwu
|
||||
|
||||
## Phishing OAuth w App Scripts
|
||||
|
||||
Możliwe jest stworzenie App Scripts dołączonych do dokumentów, aby spróbować uzyskać dostęp do tokena OAuth ofiary, więcej informacji znajdziesz w:
|
||||
Możliwe jest stworzenie App Scripts dołączonych do dokumentów, aby spróbować uzyskać dostęp do tokena OAuth ofiary, aby uzyskać więcej informacji, sprawdź:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
@@ -82,27 +82,27 @@ gws-app-scripts.md
|
||||
Każda z wcześniejszych technik może być użyta, aby skłonić użytkownika do uzyskania dostępu do **aplikacji Google OAuth**, która **zażąda** od użytkownika pewnych **uprawnień**. Jeśli użytkownik **ufa** **źródłu**, może **ufać** **aplikacji** (nawet jeśli prosi o uprawnienia o wysokim poziomie).
|
||||
|
||||
> [!NOTE]
|
||||
> Zauważ, że Google wyświetla brzydkie okno dialogowe ostrzegające, że aplikacja jest nieznana w kilku przypadkach, a administratorzy Workspace mogą nawet zapobiec akceptacji aplikacji OAuth przez użytkowników.
|
||||
> Zauważ, że Google wyświetla brzydkie okno dialogowe ostrzegające, że aplikacja jest nieufna w kilku przypadkach, a administratorzy Workspace mogą nawet zapobiec akceptacji aplikacji OAuth przez użytkowników.
|
||||
|
||||
**Google** pozwala na tworzenie aplikacji, które mogą **działać w imieniu użytkowników** z różnymi **usługami Google**: Gmail, Drive, GCP...
|
||||
|
||||
Podczas tworzenia aplikacji, aby **działać w imieniu innych użytkowników**, deweloper musi stworzyć **aplikację OAuth w GCP** i wskazać zakresy (uprawnienia), które aplikacja potrzebuje, aby uzyskać dostęp do danych użytkowników.\
|
||||
Gdy **użytkownik** chce **użyć** tej **aplikacji**, zostanie **poproszony** o **zaakceptowanie**, że aplikacja będzie miała dostęp do ich danych określonych w zakresach.
|
||||
Kiedy **użytkownik** chce **użyć** tej **aplikacji**, zostanie **poproszony** o **zaakceptowanie**, że aplikacja będzie miała dostęp do ich danych określonych w zakresach.
|
||||
|
||||
To bardzo atrakcyjny sposób na **phishing** użytkowników nietechnicznych do korzystania z **aplikacji, które uzyskują dostęp do wrażliwych informacji**, ponieważ mogą nie rozumieć konsekwencji. Jednak w kontach organizacyjnych istnieją sposoby, aby temu zapobiec.
|
||||
To bardzo kuszący sposób na **phishing** użytkowników nietechnicznych do korzystania z **aplikacji, które uzyskują dostęp do wrażliwych informacji**, ponieważ mogą nie rozumieć konsekwencji. Jednak w kontach organizacyjnych istnieją sposoby, aby temu zapobiec.
|
||||
|
||||
### Okno dialogowe aplikacji niezweryfikowanej
|
||||
### Ostrzeżenie o niezweryfikowanej aplikacji
|
||||
|
||||
Jak wspomniano, Google zawsze wyświetli **okno dialogowe dla użytkownika, aby zaakceptować** uprawnienia, które przyznają aplikacji w ich imieniu. Jednak jeśli aplikacja jest uważana za **niebezpieczną**, Google najpierw pokaże **okno dialogowe** wskazujące, że jest **niebezpieczna** i **utrudnia** użytkownikowi przyznanie uprawnień aplikacji.
|
||||
Jak wspomniano, Google zawsze wyświetli **okno dialogowe dla użytkownika, aby zaakceptował** uprawnienia, które przyznają aplikacji w ich imieniu. Jednak jeśli aplikacja jest uważana za **niebezpieczną**, Google najpierw pokaże **okno dialogowe** wskazujące, że jest **niebezpieczna** i **utrudnia** użytkownikowi przyznanie uprawnień aplikacji.
|
||||
|
||||
To okno dialogowe pojawia się w aplikacjach, które:
|
||||
|
||||
- Używają jakiegokolwiek zakresu, który może uzyskać dostęp do danych prywatnych (Gmail, Drive, GCP, BigQuery...)
|
||||
- Aplikacje z mniej niż 100 użytkownikami (aplikacje > 100 wymagają również procesu przeglądu, aby przestać wyświetlać okno dialogowe niezweryfikowanej aplikacji)
|
||||
- Aplikacje z mniej niż 100 użytkownikami (aplikacje > 100 wymagają również procesu przeglądu, aby przestać wyświetlać niezweryfikowane okno dialogowe)
|
||||
|
||||
### Interesujące zakresy
|
||||
|
||||
[**Tutaj**](https://developers.google.com/identity/protocols/oauth2/scopes) znajdziesz listę wszystkich zakresów Google OAuth.
|
||||
[**Tutaj**](https://developers.google.com/identity/protocols/oauth2/scopes) możesz znaleźć listę wszystkich zakresów Google OAuth.
|
||||
|
||||
- **cloud-platform**: Wyświetlaj i zarządzaj swoimi danymi w usługach **Google Cloud Platform**. Możesz udawać użytkownika w GCP.
|
||||
- **admin.directory.user.readonly**: Zobacz i pobierz katalog GSuite swojej organizacji. Uzyskaj imiona, numery telefonów, adresy URL kalendarzy wszystkich użytkowników.
|
||||
@@ -135,14 +135,14 @@ cd gcp_oauth_phishing_example
|
||||
pip install flask requests google-auth-oauthlib
|
||||
python3 app.py --client-id "<client_id>" --client-secret "<client_secret>"
|
||||
```
|
||||
Przejdź do **`http://localhost:8000`**, kliknij przycisk Zaloguj się za pomocą Google, a pojawi się **komunikat** jak ten:
|
||||
Przejdź do **`http://localhost:8000`**, kliknij przycisk Zaloguj się za pomocą Google, a pojawi się komunikat podobny do tego:
|
||||
|
||||
<figure><img src="../../../images/image (333).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Aplikacja wyświetli **token dostępu i token odświeżania**, które można łatwo wykorzystać. Aby uzyskać więcej informacji na temat **jak używać tych tokenów, sprawdź**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Używanie `glcoud`
|
||||
|
||||
Reference in New Issue
Block a user