mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-16 23:01:43 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
Translator
@@ -4,7 +4,7 @@
|
||||
|
||||
## **Jerarquía de recursos**
|
||||
|
||||
Google Cloud utiliza una [Jerarquía de recursos](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) que es similar, conceptualmente, a la de un sistema de archivos tradicional. Esto proporciona un flujo de trabajo lógico de padre/hijo con puntos de adjunto específicos para políticas y permisos.
|
||||
Google Cloud utiliza una [jerarquía de recursos](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) que es similar, conceptualmente, a la de un sistema de archivos tradicional. Esto proporciona un flujo de trabajo lógico de padre/hijo con puntos de adjunto específicos para políticas y permisos.
|
||||
|
||||
A un alto nivel, se ve así:
|
||||
```
|
||||
@@ -64,29 +64,29 @@ Hay muchas más restricciones que te dan un control detallado sobre los recursos
|
||||
|
||||
- **Deshabilitar concesiones automáticas de IAM:** Previene que las cuentas de servicio predeterminadas de App Engine y Compute Engine sean automáticamente otorgadas el rol de Editor de IAM en un proyecto al crearse. Esto asegura que las cuentas de servicio no reciban roles de IAM excesivamente permisivos al crearse.
|
||||
- **Deshabilitar la creación de claves de cuentas de servicio:** Previene la creación de claves de cuentas de servicio públicas. Esto ayuda a reducir el riesgo de exponer credenciales persistentes.
|
||||
- **Deshabilitar la carga de claves de cuentas de servicio:** Previene la carga de claves de cuentas de servicio públicas. Esto ayuda a reducir el riesgo de material de clave filtrado o reutilizado.
|
||||
- **Deshabilitar la carga de claves de cuentas de servicio:** Previene la carga de claves de cuentas de servicio públicas. Esto ayuda a reducir el riesgo de filtraciones o reutilización de material de clave.
|
||||
|
||||
**Políticas de configuración de red VPC segura**
|
||||
**Políticas de configuración de red VPC seguras**
|
||||
|
||||
- **Definir IPs externas permitidas para instancias de VM:** Previene la creación de instancias Compute con una IP pública, lo que puede exponerlas al tráfico de internet.
|
||||
|
||||
* **Deshabilitar virtualización anidada de VM:** Previene la creación de VMs anidadas en VMs de Compute Engine. Esto disminuye el riesgo de seguridad de tener VMs anidadas no monitoreadas.
|
||||
* **Deshabilitar la virtualización anidada de VM:** Previene la creación de VMs anidadas en VMs de Compute Engine. Esto disminuye el riesgo de seguridad de tener VMs anidadas no monitoreadas.
|
||||
|
||||
- **Deshabilitar puerto serie de VM:** Previene el acceso al puerto serie de VMs de Compute Engine. Esto previene la entrada al puerto serie de un servidor usando la API de Compute Engine.
|
||||
- **Deshabilitar el puerto serie de VM:** Previene el acceso al puerto serie de VMs de Compute Engine. Esto previene la entrada a un puerto serie de servidor usando la API de Compute Engine.
|
||||
|
||||
* **Restringir redes autorizadas en instancias de Cloud SQL:** Previene que rangos de red públicos o no internos accedan a tus bases de datos de Cloud SQL.
|
||||
|
||||
- **Restringir el reenvío de protocolos según el tipo de dirección IP:** Previene el reenvío de protocolos de VM para direcciones IP externas.
|
||||
|
||||
* **Restringir el acceso IP público en instancias de Cloud SQL:** Previene la creación de instancias de Cloud SQL con una IP pública, lo que puede exponerlas al tráfico de internet.
|
||||
* **Restringir el acceso a IP pública en instancias de Cloud SQL:** Previene la creación de instancias de Cloud SQL con una IP pública, lo que puede exponerlas al tráfico de internet.
|
||||
|
||||
- **Restringir la eliminación de gravámenes de proyectos VPC compartidos:** Previene la eliminación accidental de proyectos anfitriones de VPC compartidos.
|
||||
- **Restringir la eliminación de gravámenes de proyectos compartidos de VPC:** Previene la eliminación accidental de proyectos anfitriones de VPC compartidos.
|
||||
|
||||
* **Establece la configuración de DNS interno para nuevos proyectos a Solo DNS Zonal:** Previene el uso de una configuración de DNS heredada que ha reducido la disponibilidad del servicio.
|
||||
* **Establecer la configuración de DNS interno para nuevos proyectos a Solo DNS Zonal:** Previene el uso de una configuración de DNS heredada que ha reducido la disponibilidad del servicio.
|
||||
|
||||
- **Omitir la creación de red predeterminada:** Previene la creación automática de la red VPC predeterminada y recursos relacionados. Esto evita reglas de firewall predeterminadas excesivamente permisivas.
|
||||
|
||||
* **Deshabilitar el uso de IPv6 externo en VPC:** Previene la creación de subredes IPv6 externas, que pueden ser expuestas a accesos no autorizados a internet.
|
||||
* **Deshabilitar el uso de IPv6 externo en VPC:** Previene la creación de subredes IPv6 externas, que pueden estar expuestas a accesos no autorizados a internet.
|
||||
|
||||
</details>
|
||||
|
||||
@@ -94,8 +94,8 @@ Hay muchas más restricciones que te dan un control detallado sobre los recursos
|
||||
|
||||
Estos son como las políticas de IAM en AWS ya que **cada rol contiene un conjunto de permisos.**
|
||||
|
||||
Sin embargo, a diferencia de AWS, **no hay un repositorio centralizado** de roles. En lugar de eso, **los recursos dan X roles de acceso a Y principales**, y la única forma de averiguar quién tiene acceso a un recurso es usar el **método `get-iam-policy` sobre ese recurso**.\
|
||||
Esto podría ser un problema porque esto significa que la única forma de averiguar **qué permisos tiene un principal es preguntar a cada recurso a quién le está dando permisos**, y un usuario podría no tener permisos para obtener permisos de todos los recursos.
|
||||
Sin embargo, a diferencia de AWS, no hay **un repositorio centralizado** de roles. En lugar de eso, **los recursos dan X roles de acceso a Y principales**, y la única forma de averiguar quién tiene acceso a un recurso es usar el **método `get-iam-policy` sobre ese recurso**.\
|
||||
Esto podría ser un problema porque significa que la única forma de averiguar **qué permisos tiene un principal es preguntar a cada recurso a quién le está dando permisos**, y un usuario podría no tener permisos para obtener permisos de todos los recursos.
|
||||
|
||||
Hay **tres tipos** de roles en IAM:
|
||||
|
||||
@@ -106,7 +106,7 @@ Hay **tres tipos** de roles en IAM:
|
||||
Hay miles de permisos en GCP. Para verificar si un rol tiene un permiso, puedes [**buscar el permiso aquí**](https://cloud.google.com/iam/docs/permissions-reference) y ver qué roles lo tienen.
|
||||
|
||||
También puedes [**buscar aquí roles predefinidos**](https://cloud.google.com/iam/docs/understanding-roles#product_specific_documentation) **ofrecidos por cada producto.** Ten en cuenta que algunos **roles** no pueden ser asignados a usuarios y **solo a cuentas de servicio debido a algunos permisos** que contienen.\
|
||||
Además, ten en cuenta que los **permisos** solo **tendrán efecto** si están **adjuntos al servicio relevante.**
|
||||
Además, ten en cuenta que los **permisos** solo **tendrán efecto** si están **asignados al servicio relevante.**
|
||||
|
||||
O verifica si un **rol personalizado puede usar un** [**permiso específico aquí**](https://cloud.google.com/iam/docs/custom-roles-permissions-support)**.**
|
||||
|
||||
@@ -126,7 +126,7 @@ Puedes acceder a los **usuarios y grupos de Workspaces en** [**https://admin.goo
|
||||
|
||||
Cuando se crea una organización, se **sugiere encarecidamente crear varios grupos.** Si gestionas alguno de ellos, podrías haber comprometido toda o una parte importante de la organización:
|
||||
|
||||
<table data-header-hidden><thead><tr><th width="299.3076923076923"></th><th></th></tr></thead><tbody><tr><td><strong>Grupo</strong></td><td><strong>Función</strong></td></tr><tr><td><strong><code>gcp-organization-admins</code></strong><br><em>(se requieren cuentas de grupo o individuales para la lista de verificación)</em></td><td>Administrar cualquier recurso que pertenezca a la organización. Asigna este rol con moderación; los administradores de la organización tienen acceso a todos tus recursos de Google Cloud. Alternativamente, dado que esta función tiene privilegios altos, considera usar cuentas individuales en lugar de crear un grupo.</td></tr><tr><td><strong><code>gcp-network-admins</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Crear redes, subredes, reglas de firewall y dispositivos de red como Cloud Router, Cloud VPN y balanceadores de carga en la nube.</td></tr><tr><td><strong><code>gcp-billing-admins</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Configurar cuentas de facturación y monitorear su uso.</td></tr><tr><td><strong><code>gcp-developers</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Diseñar, codificar y probar aplicaciones.</td></tr><tr><td><strong><code>gcp-security-admins</code></strong><br></td><td>Establecer y gestionar políticas de seguridad para toda la organización, incluyendo gestión de acceso y <a href="https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints">políticas de restricciones de organización</a>. Consulta la <a href="https://cloud.google.com/architecture/security-foundations/authentication-authorization#users_and_groups">guía de fundamentos de seguridad de Google Cloud</a> para más información sobre la planificación de tu infraestructura de seguridad en Google Cloud.</td></tr><tr><td><strong><code>gcp-devops</code></strong></td><td>Crear o gestionar pipelines de extremo a extremo que soporten integración y entrega continuas, monitoreo y aprovisionamiento de sistemas.</td></tr><tr><td><strong><code>gcp-logging-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-logging-viewers</code></strong></td><td></td></tr><tr><td><strong><code>gcp-monitor-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-billing-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Monitorear el gasto en proyectos. Los miembros típicos son parte del equipo de finanzas.</td></tr><tr><td><strong><code>gcp-platform-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar información de recursos a través de la organización de Google Cloud.</td></tr><tr><td><strong><code>gcp-security-reviewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar la seguridad en la nube.</td></tr><tr><td><strong><code>gcp-network-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar configuraciones de red.</td></tr><tr><td><strong><code>grp-gcp-audit-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Ver registros de auditoría.</td></tr><tr><td><strong><code>gcp-scc-admin</code></strong><br><em>(ya no por defecto)</em></td><td>Administrar el Centro de Comando de Seguridad.</td></tr><tr><td><strong><code>gcp-secrets-admin</code></strong><br><em>(ya no por defecto)</em></td><td>Gestionar secretos en Secret Manager.</td></tr></tbody></table>
|
||||
<table data-header-hidden><thead><tr><th width="299.3076923076923"></th><th></th></tr></thead><tbody><tr><td><strong>Grupo</strong></td><td><strong>Función</strong></td></tr><tr><td><strong><code>gcp-organization-admins</code></strong><br><em>(se requieren cuentas de grupo o individuales para la lista de verificación)</em></td><td>Administrar cualquier recurso que pertenezca a la organización. Asigna este rol con moderación; los administradores de la organización tienen acceso a todos tus recursos de Google Cloud. Alternativamente, dado que esta función tiene privilegios altos, considera usar cuentas individuales en lugar de crear un grupo.</td></tr><tr><td><strong><code>gcp-network-admins</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Crear redes, subredes, reglas de firewall y dispositivos de red como Cloud Router, Cloud VPN y balanceadores de carga en la nube.</td></tr><tr><td><strong><code>gcp-billing-admins</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Configurar cuentas de facturación y monitorear su uso.</td></tr><tr><td><strong><code>gcp-developers</code></strong><br><em>(requerido para la lista de verificación)</em></td><td>Diseñar, codificar y probar aplicaciones.</td></tr><tr><td><strong><code>gcp-security-admins</code></strong><br></td><td>Establecer y gestionar políticas de seguridad para toda la organización, incluyendo gestión de acceso y <a href="https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints">políticas de restricciones de organización</a>. Consulta la <a href="https://cloud.google.com/architecture/security-foundations/authentication-authorization#users_and_groups">guía de fundamentos de seguridad de Google Cloud</a> para más información sobre la planificación de tu infraestructura de seguridad en Google Cloud.</td></tr><tr><td><strong><code>gcp-devops</code></strong></td><td>Crear o gestionar pipelines de extremo a extremo que soporten integración y entrega continua, monitoreo y aprovisionamiento de sistemas.</td></tr><tr><td><strong><code>gcp-logging-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-logging-viewers</code></strong></td><td></td></tr><tr><td><strong><code>gcp-monitor-admins</code></strong></td><td></td></tr><tr><td><strong><code>gcp-billing-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Monitorear el gasto en proyectos. Los miembros típicos son parte del equipo de finanzas.</td></tr><tr><td><strong><code>gcp-platform-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar información de recursos a través de la organización de Google Cloud.</td></tr><tr><td><strong><code>gcp-security-reviewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar la seguridad en la nube.</td></tr><tr><td><strong><code>gcp-network-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Revisar configuraciones de red.</td></tr><tr><td><strong><code>grp-gcp-audit-viewer</code></strong><br><em>(ya no por defecto)</em></td><td>Ver registros de auditoría.</td></tr><tr><td><strong><code>gcp-scc-admin</code></strong><br><em>(ya no por defecto)</em></td><td>Administrar el Centro de Comando de Seguridad.</td></tr><tr><td><strong><code>gcp-secrets-admin</code></strong><br><em>(ya no por defecto)</em></td><td>Gestionar secretos en Secret Manager.</td></tr></tbody></table>
|
||||
|
||||
## **Política de Contraseñas Predeterminada**
|
||||
|
||||
@@ -142,7 +142,7 @@ Cuando se crea una organización, se **sugiere encarecidamente crear varios grup
|
||||
|
||||
## **Cuentas de servicio**
|
||||
|
||||
Estos son los principales que **los recursos** pueden **tener** **adjuntos** y acceso para interactuar fácilmente con GCP. Por ejemplo, es posible acceder al **token de autenticación** de una Cuenta de Servicio **adjunta a una VM** en los metadatos.\
|
||||
Estas son los principales que **los recursos** pueden **tener** **adjuntos** y acceso para interactuar fácilmente con GCP. Por ejemplo, es posible acceder al **token de autenticación** de una Cuenta de Servicio **adjunta a una VM** en los metadatos.\
|
||||
Es posible encontrar algunos **conflictos** al usar tanto **IAM como scopes de acceso**. Por ejemplo, tu cuenta de servicio puede tener el rol de IAM de `compute.instanceAdmin`, pero la instancia que has comprometido ha sido limitada con la restricción de scope de `https://www.googleapis.com/auth/compute.readonly`. Esto te impediría hacer cualquier cambio usando el token OAuth que se asigna automáticamente a tu instancia.
|
||||
|
||||
Es similar a **los roles de IAM de AWS**. Pero a diferencia de AWS, **cualquier** cuenta de servicio puede ser **adjunta a cualquier servicio** (no necesita permitirlo a través de una política).
|
||||
@@ -169,7 +169,7 @@ Hay 2 formas principales de acceder a GCP como una cuenta de servicio:
|
||||
Los alcances de acceso están **adjuntos a los tokens OAuth generados** para acceder a los puntos finales de la API de GCP. **Restringen los permisos** del token OAuth.\
|
||||
Esto significa que si un token pertenece a un Propietario de un recurso pero no tiene en el alcance del token acceso a ese recurso, el token **no puede ser utilizado para (ab)usar esos privilegios**.
|
||||
|
||||
Google de hecho [recomienda](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) que **no se utilicen alcances de acceso y que se confíe totalmente en IAM**. El portal de gestión web de hecho hace cumplir esto, pero los alcances de acceso aún se pueden aplicar a instancias utilizando cuentas de servicio personalizadas programáticamente.
|
||||
Google en realidad [recomienda](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) que **no se utilicen alcances de acceso y se confíe totalmente en IAM**. El portal de gestión web en realidad hace cumplir esto, pero los alcances de acceso aún se pueden aplicar a instancias utilizando cuentas de servicio personalizadas programáticamente.
|
||||
|
||||
Puedes ver qué **alcances** están **asignados** consultando:
|
||||
```bash
|
||||
@@ -186,7 +186,7 @@ curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>
|
||||
"access_type": "offline"
|
||||
}
|
||||
```
|
||||
Los **alcances** anteriores son los que se generan por **defecto** utilizando **`gcloud`** para acceder a datos. Esto se debe a que cuando usas **`gcloud`** primero creas un token de OAuth y luego lo usas para contactar los endpoints.
|
||||
Los **alcances** anteriores son los generados por **defecto** usando **`gcloud`** para acceder a datos. Esto se debe a que cuando usas **`gcloud`** primero creas un token de OAuth y luego lo usas para contactar los endpoints.
|
||||
|
||||
El alcance más importante de esos potencialmente es **`cloud-platform`**, que básicamente significa que es posible **acceder a cualquier servicio en GCP**.
|
||||
|
||||
@@ -204,13 +204,13 @@ gcloud auth application-default print-access-token
|
||||
|
||||
# To use this token with some API you might need to use curl to indicate the project header with --header "X-Goog-User-Project: <project-name>"
|
||||
```
|
||||
## **Políticas, Vinculaciones y Membresías de IAM en Terraform**
|
||||
## **Políticas, Vínculos y Membresías de IAM en Terraform**
|
||||
|
||||
Como se define en terraform en [https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam](https://registry.terraform.io/providers/hashicorp/google/latest/docs/resources/google_project_iam), al usar terraform con GCP hay diferentes formas de otorgar acceso a un principal sobre un recurso:
|
||||
|
||||
- **Membresías**: Estableces **principales como miembros de roles** **sin restricciones** sobre el rol o los principales. Puedes poner un usuario como miembro de un rol y luego poner un grupo como miembro del mismo rol y también establecer esos principales (usuario y grupo) como miembros de otros roles.
|
||||
- **Vinculaciones**: Varios **principales pueden estar vinculados a un rol**. Esos **principales aún pueden estar vinculados o ser miembros de otros roles**. Sin embargo, si un principal que no está vinculado al rol se establece como **miembro de un rol vinculado**, la próxima vez que se **aplique la vinculación, la membresía desaparecerá**.
|
||||
- **Políticas**: Una política es **autoritativa**, indica roles y principales y luego, **esos principales no pueden tener más roles y esos roles no pueden tener más principales** a menos que esa política sea modificada (ni siquiera en otras políticas, vinculaciones o membresías). Por lo tanto, cuando un rol o principal se especifica en la política, todos sus privilegios están **limitados por esa política**. Obviamente, esto puede ser eludido en caso de que al principal se le dé la opción de modificar la política o permisos de escalada de privilegios (como crear un nuevo principal y vincularlo a un nuevo rol).
|
||||
- **Membresías**: Estableces **principales como miembros de roles** **sin restricciones** sobre el rol o los principales. Puedes poner a un usuario como miembro de un rol y luego poner a un grupo como miembro del mismo rol y también establecer esos principales (usuario y grupo) como miembros de otros roles.
|
||||
- **Vínculos**: Varios **principales pueden estar vinculados a un rol**. Esos **principales aún pueden estar vinculados o ser miembros de otros roles**. Sin embargo, si un principal que no está vinculado al rol se establece como **miembro de un rol vinculado**, la próxima vez que se **aplique el vínculo, la membresía desaparecerá**.
|
||||
- **Políticas**: Una política es **autoritativa**, indica roles y principales y luego, **esos principales no pueden tener más roles y esos roles no pueden tener más principales** a menos que esa política sea modificada (ni siquiera en otras políticas, vínculos o membresías). Por lo tanto, cuando un rol o principal se especifica en la política, todos sus privilegios están **limitados por esa política**. Obviamente, esto puede ser eludido en caso de que al principal se le dé la opción de modificar la política o permisos de escalada de privilegios (como crear un nuevo principal y vincularlo a un nuevo rol).
|
||||
|
||||
## Referencias
|
||||
|
||||
|
||||
@@ -65,7 +65,7 @@ gcloud iam service-accounts add-iam-policy-binding $saId \
|
||||
> [!WARNING]
|
||||
> Nota cómo en el miembro anterior estamos especificando el **`org-name/repo-name`** como condiciones para poder acceder a la cuenta de servicio (otros parámetros que la hacen **más restrictiva** como la rama también podrían ser utilizados).
|
||||
>
|
||||
> Sin embargo, también es posible **permitir que todos en github accedan** a la cuenta de servicio creando un proveedor como el siguiente usando un comodín:
|
||||
> Sin embargo, también es posible **permitir que todo github acceda** a la cuenta de servicio creando un proveedor como el siguiente usando un comodín:
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash"># Crear un Pool de Identidad de Carga de Trabajo
|
||||
poolName=wi-pool2
|
||||
@@ -99,7 +99,7 @@ providerId=$(gcloud iam workload-identity-pools providers describe $poolName \
|
||||
</strong></code></pre>
|
||||
|
||||
> [!WARNING]
|
||||
> En este caso, cualquiera podría acceder a la cuenta de servicio desde github actions, por lo que es importante siempre **verificar cómo está definido el miembro**.\
|
||||
> En este caso, cualquiera podría acceder a la cuenta de servicio desde github actions, por lo que es importante siempre **verificar cómo se define el miembro**.\
|
||||
> Siempre debería ser algo como esto:
|
||||
>
|
||||
> `attribute.{custom_attribute}`:`principalSet://iam.googleapis.com/projects/{project}/locations/{location}/workloadIdentityPools/{pool}/attribute.{custom_attribute}/{value}`
|
||||
|
||||
Reference in New Issue
Block a user