mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-27 21:23:07 -08:00
Translated ['src/pentesting-cloud/gcp-security/gcp-to-workspace-pivoting
This commit is contained in:
Translator
@@ -4,9 +4,9 @@
|
||||
|
||||
## **De GCP a GWS**
|
||||
|
||||
### **Conceptos básicos de Delegación de Dominio**
|
||||
### **Conceptos básicos de Delegación a Nivel de Dominio**
|
||||
|
||||
La delegación de dominio de Google Workspace permite que un objeto de identidad, ya sea una **aplicación externa** del Google Workspace Marketplace o una **Cuenta de Servicio GCP** interna, **acceda a datos en todo el Workspace en nombre de los usuarios**.
|
||||
La delegación a nivel de dominio de Google Workspace permite que un objeto de identidad, ya sea una **aplicación externa** del Marketplace de Google Workspace o una **Cuenta de Servicio GCP** interna, **acceda a datos en todo el Workspace en nombre de los usuarios**.
|
||||
|
||||
> [!NOTE]
|
||||
> Esto significa básicamente que las **cuentas de servicio** dentro de los proyectos de GCP de una organización podrían ser capaces de **suplantar a los usuarios de Workspace** de la misma organización (o incluso de una diferente).
|
||||
@@ -23,10 +23,10 @@ Si un atacante **comprometió algún acceso sobre GCP** y **conoce un correo ele
|
||||
Con una **lista de todas las cuentas de servicio** a las que tiene **acceso** y la lista de **correos electrónicos de Workspace**, el atacante podría intentar **suplantar al usuario con cada cuenta de servicio**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Ten en cuenta que al configurar la delegación de dominio no se necesita ningún usuario de Workspace, por lo tanto, solo saber que **uno válido es suficiente y requerido para la suplantación**.\
|
||||
> Ten en cuenta que al configurar la delegación a nivel de dominio no se necesita ningún usuario de Workspace, por lo tanto, solo saber que **uno válido es suficiente y requerido para la suplantación**.\
|
||||
> Sin embargo, se utilizarán los **privilegios del usuario suplantado**, así que si es Super Admin podrás acceder a todo. Si no tiene ningún acceso, esto será inútil.
|
||||
|
||||
#### [GCP Generar Token de Delegación](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
#### [GCP Generate Delegation Token](https://github.com/carlospolop/gcp_gen_delegation_token)
|
||||
|
||||
Este script simple **generará un token OAuth como el usuario delegado** que luego puedes usar para acceder a otras APIs de Google con o sin `gcloud`:
|
||||
```bash
|
||||
@@ -45,9 +45,9 @@ Esta es una herramienta que puede realizar el ataque siguiendo estos pasos:
|
||||
3. Iterar sobre **cada rol de cuenta de servicio** y encontrar roles integrados, básicos y personalizados con permiso _**serviceAccountKeys.create**_ en el recurso de cuenta de servicio objetivo. Cabe señalar que el rol de Editor posee inherentemente este permiso.
|
||||
4. Crear una **nueva clave privada `KEY_ALG_RSA_2048`** para cada recurso de cuenta de servicio que se encuentre con el permiso relevante en la política IAM.
|
||||
5. Iterar sobre **cada nueva cuenta de servicio y crear un `JWT`** **objeto** para ella que esté compuesto por las credenciales de la clave privada de la SA y un alcance de OAuth. El proceso de creación de un nuevo objeto _JWT_ **iterará sobre todas las combinaciones existentes de alcances de OAuth** de la lista **oauth_scopes.txt**, con el fin de encontrar todas las posibilidades de delegación. La lista **oauth_scopes.txt** se actualiza con todos los alcances de OAuth que hemos encontrado relevantes para abusar de las identidades de Workspace.
|
||||
6. El método `_make_authorization_grant_assertion` revela la necesidad de declarar un **usuario de workspace objetivo**, referido como _subject_, para generar JWTs bajo DWD. Si bien esto puede parecer requerir un usuario específico, es importante darse cuenta de que **DWD influye en cada identidad dentro de un dominio**. En consecuencia, crear un JWT para **cualquier usuario de dominio** afecta a todas las identidades en ese dominio, de acuerdo con nuestra verificación de enumeración de combinaciones. En términos simples, un usuario válido de Workspace es suficiente para avanzar.\
|
||||
Este usuario puede definirse en el archivo _config.yaml_ de DeleFriend. Si un usuario de workspace objetivo no se conoce ya, la herramienta facilita la identificación automática de usuarios de workspace válidos escaneando usuarios de dominio con roles en proyectos de GCP. Es clave notar (nuevamente) que los JWT son específicos del dominio y no se generan para cada usuario; por lo tanto, el proceso automático se dirige a una única identidad única por dominio.
|
||||
7. **Enumerar y crear un nuevo token de acceso portador** para cada JWT y validar el token contra la API de tokeninfo.
|
||||
6. El método `_make_authorization_grant_assertion` revela la necesidad de declarar un **usuario de workspace objetivo**, referido como _subject_, para generar JWTs bajo DWD. Si bien esto puede parecer requerir un usuario específico, es importante darse cuenta de que **DWD influye en cada identidad dentro de un dominio**. En consecuencia, crear un JWT para **cualquier usuario de dominio** afecta a todas las identidades en ese dominio, de acuerdo con nuestra verificación de enumeración de combinaciones. En pocas palabras, un usuario válido de Workspace es suficiente para avanzar.\
|
||||
Este usuario puede definirse en el archivo _config.yaml_ de DeleFriend. Si no se conoce ya un usuario de workspace objetivo, la herramienta facilita la identificación automática de usuarios de workspace válidos escaneando usuarios de dominio con roles en proyectos de GCP. Es clave notar (nuevamente) que los JWT son específicos del dominio y no se generan para cada usuario; por lo tanto, el proceso automático se dirige a una única identidad única por dominio.
|
||||
7. **Enumerar y crear un nuevo token de acceso bearer** para cada JWT y validar el token contra la API de tokeninfo.
|
||||
|
||||
#### [Script de Python de Gitlab](https://gitlab.com/gitlab-com/gl-security/threatmanagement/redteam/redteam-public/gcp_misc/-/blob/master/gcp_delegation.py)
|
||||
|
||||
@@ -79,19 +79,19 @@ Es posible **ver las Delegaciones de Dominio Amplio en** [**https://admin.google
|
||||
|
||||
Un atacante con la capacidad de **crear cuentas de servicio en un proyecto de GCP** y **privilegios de superadministrador en GWS podría crear una nueva delegación que permita a las cuentas de servicio suplantar a algunos usuarios de GWS:**
|
||||
|
||||
1. **Generación de una nueva cuenta de servicio y su correspondiente par de claves:** En GCP, se pueden producir nuevos recursos de cuentas de servicio de forma interactiva a través de la consola o programáticamente utilizando llamadas a la API y herramientas de CLI directas. Esto requiere el **rol `iam.serviceAccountAdmin`** o cualquier rol personalizado equipado con el **permiso `iam.serviceAccounts.create`**. Una vez creada la cuenta de servicio, procederemos a generar un **par de claves relacionado** (**permiso `iam.serviceAccountKeys.create`**).
|
||||
2. **Creación de una nueva delegación**: Es importante entender que **solo el rol de Super Administrador posee la capacidad de configurar la delegación global de Dominio Amplio en Google Workspace** y la delegación de Dominio Amplio **no se puede configurar programáticamente,** solo puede ser creada y ajustada **manualmente** a través de la **consola** de Google Workspace.
|
||||
1. **Generación de una nueva cuenta de servicio y par de claves correspondiente:** En GCP, se pueden producir nuevos recursos de cuenta de servicio de forma interactiva a través de la consola o programáticamente utilizando llamadas a la API y herramientas de CLI directas. Esto requiere el **rol `iam.serviceAccountAdmin`** o cualquier rol personalizado equipado con el **permiso `iam.serviceAccounts.create`**. Una vez creada la cuenta de servicio, procederemos a generar un **par de claves relacionado** (**`iam.serviceAccountKeys.create`** permiso).
|
||||
2. **Creación de nueva delegación**: Es importante entender que **solo el rol de Super Administrador tiene la capacidad de configurar la delegación global de Dominio Amplio en Google Workspace** y la delegación de Dominio Amplio **no se puede configurar programáticamente,** solo se puede crear y ajustar **manualmente** a través de la **consola** de Google Workspace.
|
||||
- La creación de la regla se puede encontrar en la página **Controles de API → Administrar delegación de Dominio Amplio en la consola de administración de Google Workspace**.
|
||||
3. **Adjuntando privilegios de ámbitos de OAuth**: Al configurar una nueva delegación, Google requiere solo 2 parámetros, el ID de Cliente, que es el **ID de OAuth del recurso de Cuenta de Servicio de GCP**, y los **ámbitos de OAuth** que definen qué llamadas a la API requiere la delegación.
|
||||
3. **Adjuntando privilegios de ámbitos de OAuth**: Al configurar una nueva delegación, Google requiere solo 2 parámetros, el ID de cliente, que es el **ID de OAuth del recurso de Cuenta de Servicio de GCP**, y los **ámbitos de OAuth** que definen qué llamadas a la API requiere la delegación.
|
||||
- La **lista completa de ámbitos de OAuth** se puede encontrar [**aquí**](https://developers.google.com/identity/protocols/oauth2/scopes), pero aquí hay una recomendación: `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. **Actuando en nombre de la identidad objetivo:** En este punto, tenemos un objeto delegado funcional en GWS. Ahora, **usando la clave privada de la Cuenta de Servicio de GCP, podemos realizar llamadas a la API** (en el ámbito definido en el parámetro de ámbito de OAuth) para activarlo y **actuar en nombre de cualquier identidad que exista en Google Workspace**. Como aprendimos, la cuenta de servicio generará tokens de acceso según sus necesidades y de acuerdo con los permisos que tiene para las aplicaciones de la API REST.
|
||||
- Consulta la **sección anterior** para algunas **herramientas** para usar esta delegación.
|
||||
|
||||
#### Delegación entre organizaciones
|
||||
|
||||
El ID de SA de OAuth es global y se puede usar para **delegación entre organizaciones**. No se ha implementado ninguna restricción para prevenir la delegación global cruzada. En términos simples, **las cuentas de servicio de diferentes organizaciones de GCP pueden usarse para configurar la delegación de dominio amplio en otras organizaciones de Workspace**. Esto resultaría en **solo necesitar acceso de Super Administrador a Workspace**, y no acceso a la misma cuenta de GCP, ya que el adversario puede crear Cuentas de Servicio y claves privadas en su cuenta de GCP controlada personalmente.
|
||||
El ID de SA de OAuth es global y se puede usar para **delegación entre organizaciones**. No se ha implementado ninguna restricción para prevenir la delegación cruzada global. En términos simples, **las cuentas de servicio de diferentes organizaciones de GCP se pueden usar para configurar la delegación de dominio amplio en otras organizaciones de Workspace**. Esto resultaría en **solo necesitar acceso de Super Administrador a Workspace**, y no acceso a la misma cuenta de GCP, ya que el adversario puede crear cuentas de servicio y claves privadas en su cuenta de GCP controlada personalmente.
|
||||
|
||||
### Creando un Proyecto para enumerar Workspace
|
||||
### Creando un proyecto para enumerar Workspace
|
||||
|
||||
Por **defecto**, los **usuarios** de Workspace tienen el permiso para **crear nuevos proyectos**, y cuando se crea un nuevo proyecto, el **creador obtiene el rol de Propietario** sobre él.
|
||||
|
||||
@@ -127,10 +127,10 @@ Verifique **más enumeración en**:
|
||||
Puede encontrar más información sobre el flujo de `gcloud` para iniciar sesión en:
|
||||
|
||||
{{#ref}}
|
||||
../gcp-persistence/gcp-non-svc-persistance.md
|
||||
../gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
Como se explicó allí, gcloud puede solicitar el alcance **`https://www.googleapis.com/auth/drive`** que permitiría a un usuario acceder al drive del usuario.\
|
||||
Como se explica allí, gcloud puede solicitar el alcance **`https://www.googleapis.com/auth/drive`** que permitiría a un usuario acceder al drive del usuario.\
|
||||
Como atacante, si ha comprometido **físicamente** la computadora de un usuario y el **usuario aún está conectado** con su cuenta, podría iniciar sesión generando un token con acceso al drive usando:
|
||||
```bash
|
||||
gcloud auth login --enable-gdrive-access
|
||||
@@ -140,7 +140,7 @@ Si un atacante compromete la computadora de un usuario, también podría modific
|
||||
<figure><img src="../../../images/image (342).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
> [!WARNING]
|
||||
> Por lo tanto, la próxima vez que el usuario inicie sesión, creará un **token con acceso a drive** que el atacante podría abusar para acceder al drive. Obviamente, el navegador indicará que el token generado tendrá acceso a drive, pero como el usuario se llamará a sí mismo **`gcloud auth login`**, probablemente **no sospechará nada.**
|
||||
> Por lo tanto, la próxima vez que el usuario inicie sesión, creará un **token con acceso a drive** que el atacante podría abusar para acceder al drive. Obviamente, el navegador indicará que el token generado tendrá acceso a drive, pero como el usuario se llamará a sí mismo el **`gcloud auth login`**, probablemente **no sospechará nada.**
|
||||
>
|
||||
> Para listar archivos de drive: **`curl -H "Authorization: Bearer $(gcloud auth print-access-token)" "https://www.googleapis.com/drive/v3/files"`**
|
||||
|
||||
@@ -148,11 +148,11 @@ Si un atacante compromete la computadora de un usuario, también podría modific
|
||||
|
||||
### Acceso a usuarios privilegiados de GCP
|
||||
|
||||
Si un atacante tiene acceso completo a GWS, podrá acceder a grupos con acceso privilegiado a GCP o incluso a usuarios, por lo tanto, pasar de GWS a GCP suele ser más "simple" solo porque **los usuarios en GWS tienen altos privilegios sobre GCP**.
|
||||
Si un atacante tiene acceso completo a GWS, podrá acceder a grupos con acceso privilegiado a GCP o incluso a usuarios, por lo tanto, pasar de GWS a GCP suele ser más "sencillo" solo porque **los usuarios en GWS tienen altos privilegios sobre GCP**.
|
||||
|
||||
### Escalación de privilegios en Google Groups
|
||||
|
||||
Por defecto, los usuarios pueden **unirse libremente a grupos de Workspace de la Organización** y esos grupos **pueden tener permisos de GCP** asignados (verifica tus grupos en [https://groups.google.com/](https://groups.google.com/)).
|
||||
Por defecto, los usuarios pueden **unirse libremente a grupos de Workspace de la Organización** y esos grupos **pueden tener permisos de GCP** asignados (verifique sus grupos en [https://groups.google.com/](https://groups.google.com/)).
|
||||
|
||||
Abusando de la **escalación de privilegios de google groups**, podrías ser capaz de escalar a un grupo con algún tipo de acceso privilegiado a GCP.
|
||||
|
||||
|
||||
@@ -23,14 +23,14 @@ Puedes **iniciar un chat** con una persona solo teniendo su dirección de correo
|
||||
<figure><img src="../../../images/image (6).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
> [!TIP]
|
||||
> **Sin embargo, en mis pruebas los miembros invitados ni siquiera recibieron una invitación.**
|
||||
> **Sin embargo, en mis pruebas, los miembros invitados ni siquiera recibieron una invitación.**
|
||||
|
||||
Puedes ver cómo funcionó esto en el pasado en: [https://www.youtube.com/watch?v=KTVHLolz6cE\&t=904s](https://www.youtube.com/watch?v=KTVHLolz6cE&t=904s)
|
||||
|
||||
## Phishing en Google Docs
|
||||
|
||||
En el pasado era posible crear un **documento aparentemente legítimo** y en un comentario **mencionar algún correo (como @user@gmail.com)**. Google **enviaba un correo a esa dirección de correo** notificando que fueron mencionados en el documento.\
|
||||
Hoy en día, esto no funciona, pero si **le das al correo de la víctima acceso al documento** Google enviará un correo indicando eso. Este es el mensaje que aparece cuando mencionas a alguien:
|
||||
Hoy en día, esto no funciona, pero si **le das al correo de la víctima acceso al documento**, Google enviará un correo indicando eso. Este es el mensaje que aparece cuando mencionas a alguien:
|
||||
|
||||
<figure><img src="../../../images/image (7).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
@@ -71,25 +71,25 @@ Por ejemplo, al acceder a [https://script.google.com/macros/s/AKfycbwuLlzo0PUaT6
|
||||
|
||||
## Phishing de OAuth de App Scripts
|
||||
|
||||
Es posible crear App Scripts adjuntos a documentos para intentar obtener acceso al token de OAuth de una víctima, para más información consulta:
|
||||
Es posible crear App Scripts adjuntos a documentos para intentar obtener acceso al token OAuth de una víctima, para más información consulta:
|
||||
|
||||
{{#ref}}
|
||||
gws-app-scripts.md
|
||||
{{#endref}}
|
||||
|
||||
## Phishing de Apps de OAuth
|
||||
## Phishing de Apps OAuth
|
||||
|
||||
Cualquiera de las técnicas anteriores podría usarse para hacer que el usuario acceda a una **aplicación de Google OAuth** que **solicitará** al usuario algún **acceso**. Si el usuario **confía** en la **fuente**, podría **confiar** en la **aplicación** (incluso si está pidiendo permisos de alto privilegio).
|
||||
|
||||
> [!NOTE]
|
||||
> Ten en cuenta que Google presenta un aviso poco atractivo advirtiendo que la aplicación no es de confianza en varios casos y los administradores de Workspace incluso pueden prevenir que las personas acepten aplicaciones de OAuth.
|
||||
> Ten en cuenta que Google presenta un aviso poco atractivo advirtiendo que la aplicación no es de confianza en varios casos y los administradores de Workspace incluso pueden prevenir que las personas acepten aplicaciones OAuth.
|
||||
|
||||
**Google** permite crear aplicaciones que pueden **interactuar en nombre de los usuarios** con varios **servicios de Google**: Gmail, Drive, GCP...
|
||||
|
||||
Al crear una aplicación para **actuar en nombre de otros usuarios**, el desarrollador necesita crear una **aplicación de OAuth dentro de GCP** e indicar los scopes (permisos) que la aplicación necesita para acceder a los datos de los usuarios.\
|
||||
Al crear una aplicación para **actuar en nombre de otros usuarios**, el desarrollador necesita crear una **aplicación OAuth dentro de GCP** e indicar los scopes (permisos) que la aplicación necesita para acceder a los datos de los usuarios.\
|
||||
Cuando un **usuario** quiere **usar** esa **aplicación**, se le **pedirá** que **acepte** que la aplicación tendrá acceso a sus datos especificados en los scopes.
|
||||
|
||||
Esta es una forma muy atractiva de **phishing** a usuarios no técnicos para que usen **aplicaciones que acceden a información sensible** porque podrían no entender las consecuencias. Sin embargo, en cuentas de organizaciones, hay formas de prevenir que esto ocurra.
|
||||
Esta es una forma muy jugosa de **phishing** a usuarios no técnicos para que usen **aplicaciones que acceden a información sensible** porque pueden no entender las consecuencias. Sin embargo, en cuentas de organizaciones, hay formas de prevenir que esto suceda.
|
||||
|
||||
### Aviso de Aplicación No Verificada
|
||||
|
||||
@@ -97,7 +97,7 @@ Como se mencionó, Google siempre presentará un **aviso al usuario para aceptar
|
||||
|
||||
Este aviso aparece en aplicaciones que:
|
||||
|
||||
- Usan cualquier scope que pueda acceder a datos privados (Gmail, Drive, GCP, BigQuery...)
|
||||
- Usan cualquier scope que puede acceder a datos privados (Gmail, Drive, GCP, BigQuery...)
|
||||
- Aplicaciones con menos de 100 usuarios (para aplicaciones > 100 también se necesita un proceso de revisión para dejar de mostrar el aviso de no verificada)
|
||||
|
||||
### Scopes Interesantes
|
||||
@@ -107,20 +107,20 @@ Este aviso aparece en aplicaciones que:
|
||||
- **cloud-platform**: Ver y gestionar tus datos en los servicios de **Google Cloud Platform**. Puedes suplantar al usuario en GCP.
|
||||
- **admin.directory.user.readonly**: Ver y descargar el directorio de GSuite de tu organización. Obtener nombres, teléfonos, URLs de calendarios de todos los usuarios.
|
||||
|
||||
### Crear una Aplicación de OAuth
|
||||
### Crear una Aplicación OAuth
|
||||
|
||||
**Comienza creando un ID de Cliente de OAuth**
|
||||
**Comienza creando un ID de Cliente OAuth**
|
||||
|
||||
1. Ve a [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient) y haz clic en configurar la pantalla de consentimiento.
|
||||
2. Luego, se te preguntará si el **tipo de usuario** es **interno** (solo para personas en tu organización) o **externo**. Selecciona el que se ajuste a tus necesidades.
|
||||
- Interno podría ser interesante si ya has comprometido a un usuario de la organización y estás creando esta aplicación para phishing a otro.
|
||||
- Interno puede ser interesante si ya has comprometido a un usuario de la organización y estás creando esta aplicación para phishing a otro.
|
||||
3. Da un **nombre** a la aplicación, un **correo electrónico de soporte** (ten en cuenta que puedes establecer un correo electrónico de grupo de Google para intentar anonimizarte un poco más), un **logo**, **dominios autorizados** y otro **correo electrónico** para **actualizaciones**.
|
||||
4. **Selecciona** los **scopes de OAuth**.
|
||||
4. **Selecciona** los **scopes OAuth**.
|
||||
- Esta página está dividida en permisos no sensibles, permisos sensibles y permisos restringidos. Cada vez que agregas un nuevo permiso, se añade a su categoría. Dependiendo de los permisos solicitados, aparecerán diferentes avisos al usuario indicando cuán sensibles son estos permisos.
|
||||
- Tanto **`admin.directory.user.readonly`** como **`cloud-platform`** son permisos sensibles.
|
||||
5. **Agrega los usuarios de prueba.** Mientras el estado de la aplicación sea de prueba, solo estos usuarios podrán acceder a la aplicación, así que asegúrate de **agregar el correo electrónico que vas a estar phishing**.
|
||||
|
||||
Ahora obtengamos **credenciales para una aplicación web** usando el **ID de Cliente de OAuth previamente creado**:
|
||||
Ahora obtengamos **credenciales para una aplicación web** usando el **ID de Cliente OAuth creado previamente**:
|
||||
|
||||
1. Regresa a [https://console.cloud.google.com/apis/credentials/oauthclient](https://console.cloud.google.com/apis/credentials/oauthclient), esta vez aparecerá una opción diferente.
|
||||
2. Selecciona **crear credenciales para una aplicación web**.
|
||||
@@ -128,7 +128,7 @@ Ahora obtengamos **credenciales para una aplicación web** usando el **ID de Cli
|
||||
- Puedes establecer en ambos algo como **`http://localhost:8000/callback`** para pruebas.
|
||||
4. Obtén las **credenciales** de tu aplicación.
|
||||
|
||||
Finalmente, ejecutemos **una aplicación web que usará las credenciales de la aplicación de OAuth**. Puedes encontrar un ejemplo en [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
Finalmente, ejecutemos **una aplicación web que usará las credenciales de la aplicación OAuth**. Puedes encontrar un ejemplo en [https://github.com/carlospolop/gcp_oauth_phishing_example](https://github.com/carlospolop/gcp_oauth_phishing_example).
|
||||
```bash
|
||||
git clone ttps://github.com/carlospolop/gcp_oauth_phishing_example
|
||||
cd gcp_oauth_phishing_example
|
||||
@@ -142,7 +142,7 @@ Ve a **`http://localhost:8000`**, haz clic en el botón Iniciar sesión con Goog
|
||||
La aplicación mostrará el **token de acceso y el token de actualización** que se pueden usar fácilmente. Para más información sobre **cómo usar estos tokens, consulta**:
|
||||
|
||||
{{#ref}}
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistance.md
|
||||
../../gcp-security/gcp-persistence/gcp-non-svc-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
#### Usando `glcoud`
|
||||
|
||||
Reference in New Issue
Block a user