# GCP - Informations de base

{{#include ../../../banners/hacktricks-training.md}}

## **Hiérarchie des ressources**

Google Cloud utilise une [hiérarchie des ressources](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy) qui est conceptuellement similaire à celle d'un système de fichiers traditionnel. Cela fournit un flux de travail logique parent/enfant avec des points d'attache spécifiques pour les politiques et les autorisations.

À un niveau élevé, cela ressemble à ceci :
```
Organization
--> Folders
--> Projects
--> Resources
```
Une machine virtuelle (appelée une instance de calcul) est une ressource. Une ressource réside dans un projet, probablement aux côtés d'autres instances de calcul, de buckets de stockage, etc.

<figure><img src="../../../images/image (1) (1) (1) (1) (1) (1) (1).png" alt=""><figcaption><p><a href="https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg">https://cloud.google.com/static/resource-manager/img/cloud-hierarchy.svg</a></p></figcaption></figure>

## **Migration de Projets**

Il est possible de **migrer un projet sans organisation** vers une organisation avec les permissions `roles/resourcemanager.projectCreator` et `roles/resourcemanager.projectMover`. Si le projet se trouve dans une autre organisation, il est nécessaire de contacter le support GCP pour **les déplacer hors de l'organisation d'abord**. Pour plus d'infos, consultez [**ceci**](https://medium.com/google-cloud/migrating-a-project-from-one-organization-to-another-gcp-4b37a86dd9e6).

## **Politiques d'Organisation**

Permettent de centraliser le contrôle sur les ressources cloud de votre organisation :

- Centraliser le contrôle pour **configurer des restrictions** sur la façon dont les ressources de votre organisation peuvent être utilisées.
- Définir et établir des **garde-fous** pour que vos équipes de développement restent dans les limites de conformité.
- Aider les propriétaires de projets et leurs équipes à avancer rapidement sans craindre de violer la conformité.

Ces politiques peuvent être créées pour **affecter l'ensemble de l'organisation, le(s) dossier(s) ou le(s) projet(s)**. Les descendants du nœud de hiérarchie de ressources ciblé **héritent de la politique d'organisation**.

Pour **définir** une politique d'organisation, **vous choisissez un** [**contrainte**](https://cloud.google.com/resource-manager/docs/organization-policy/overview#constraints), qui est un type particulier de restriction contre un service Google Cloud ou un groupe de services Google Cloud. Vous **configurez cette contrainte avec vos restrictions souhaitées**.

<figure><img src="../../../images/image (217).png" alt=""><figcaption><p><a href="https://cloud.google.com/resource-manager/img/org-policy-concepts.svg">https://cloud.google.com/resource-manager/img/org-policy-concepts.svg</a></p></figcaption></figure>

#### Cas d'utilisation courants <a href="#common_use_cases" id="common_use_cases"></a>

- Limiter le partage de ressources en fonction du domaine.
- Limiter l'utilisation des comptes de service Identity and Access Management.
- Restreindre l'emplacement physique des ressources nouvellement créées.
- Désactiver la création de comptes de service.

<figure><img src="../../../images/image (172).png" alt=""><figcaption></figcaption></figure>

Il existe de nombreuses autres contraintes qui vous donnent un contrôle granulaire sur les ressources de votre organisation. Pour **plus d'informations, consultez la** [**liste de toutes les contraintes du Service de Politique d'Organisation**](https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints)**.**

### **Politiques d'Organisation par Défaut**

<details>

<summary>Voici les politiques que Google ajoutera par défaut lors de la configuration de votre organisation GCP :</summary>

**Politiques de Gestion des Accès**

- **Contacts restreints par domaine :** Empêche l'ajout d'utilisateurs aux Contacts Essentiels en dehors de vos domaines spécifiés. Cela limite les Contacts Essentiels à n'autoriser que les identités d'utilisateur gérées dans vos domaines sélectionnés à recevoir des notifications de la plateforme.
- **Partage restreint par domaine :** Empêche l'ajout d'utilisateurs aux politiques IAM en dehors de vos domaines spécifiés. Cela limite les politiques IAM à n'autoriser que les identités d'utilisateur gérées dans vos domaines sélectionnés à accéder aux ressources de cette organisation.
- **Prévention de l'accès public :** Empêche les buckets Cloud Storage d'être exposés au public. Cela garantit qu'un développeur ne peut pas configurer les buckets Cloud Storage pour avoir un accès Internet non authentifié.
- **Accès uniforme au niveau du bucket :** Empêche les listes de contrôle d'accès (ACL) au niveau des objets dans les buckets Cloud Storage. Cela simplifie votre gestion des accès en appliquant les politiques IAM de manière cohérente à tous les objets dans les buckets Cloud Storage.
- **Exiger la connexion OS :** Les VM créées dans de nouveaux projets auront la connexion OS activée. Cela vous permet de gérer l'accès SSH à vos instances en utilisant IAM sans avoir besoin de créer et de gérer des clés SSH individuelles.

**Politiques de sécurité supplémentaires pour les comptes de service**

- **Désactiver les attributions IAM automatiques :** Empêche les comptes de service par défaut App Engine et Compute Engine d'être automatiquement attribués au rôle IAM Éditeur lors de la création d'un projet. Cela garantit que les comptes de service ne reçoivent pas de rôles IAM trop permissifs lors de leur création.
- **Désactiver la création de clés de compte de service :** Empêche la création de clés de compte de service publiques. Cela aide à réduire le risque d'exposition de credentials persistants.
- **Désactiver le téléchargement de clés de compte de service :** Empêche le téléchargement de clés de compte de service publiques. Cela aide à réduire le risque de fuite ou de réutilisation de matériel de clé.

**Politiques de configuration sécurisée du réseau VPC**

- **Définir les IP externes autorisées pour les instances VM :** Empêche la création d'instances de calcul avec une IP publique, ce qui peut les exposer au trafic Internet.

* **Désactiver la virtualisation imbriquée des VM :** Empêche la création de VM imbriquées sur les VM Compute Engine. Cela diminue le risque de sécurité d'avoir des VM imbriquées non surveillées.

- **Désactiver le port série des VM :** Empêche l'accès au port série des VM Compute Engine. Cela empêche l'entrée dans le port série d'un serveur en utilisant l'API Compute Engine.

* **Restreindre les réseaux autorisés sur les instances Cloud SQL :** Empêche les plages de réseaux publics ou non internes d'accéder à vos bases de données Cloud SQL.

- **Restreindre le transfert de protocole en fonction du type d'adresse IP :** Empêche le transfert de protocole VM pour les adresses IP externes.

* **Restreindre l'accès IP public sur les instances Cloud SQL :** Empêche la création d'instances Cloud SQL avec une IP publique, ce qui peut les exposer au trafic Internet.

- **Restreindre la suppression de la ligne de projet VPC partagé :** Empêche la suppression accidentelle des projets hôtes VPC partagés.

* **Définir le paramètre DNS interne pour les nouveaux projets sur DNS Zonal uniquement :** Empêche l'utilisation d'un paramètre DNS hérité qui a réduit la disponibilité du service.

- **Ignorer la création de réseau par défaut :** Empêche la création automatique du réseau VPC par défaut et des ressources associées. Cela évite des règles de pare-feu par défaut trop permissives.

* **Désactiver l'utilisation d'IPv6 externe VPC :** Empêche la création de sous-réseaux IPv6 externes, qui peuvent être exposés à un accès Internet non autorisé.

</details>

## **Rôles IAM**

Ce sont comme des politiques IAM dans AWS car **chaque rôle contient un ensemble de permissions.**

Cependant, contrairement à AWS, il n'y a **pas de dépôt centralisé** de rôles. Au lieu de cela, **les ressources donnent X rôles d'accès à Y principaux**, et le seul moyen de savoir qui a accès à une ressource est d'utiliser la **méthode `get-iam-policy` sur cette ressource**.\
Cela pourrait poser un problème car cela signifie que le seul moyen de savoir **quelles permissions un principal a est de demander à chaque ressource à qui elle accorde des permissions**, et un utilisateur pourrait ne pas avoir les permissions nécessaires pour obtenir les permissions de toutes les ressources.

Il existe **trois types** de rôles dans IAM :

- **Rôles de base/primitive**, qui incluent les rôles **Propriétaire**, **Éditeur** et **Visionneur** qui existaient avant l'introduction de l'IAM.
- **Rôles prédéfinis**, qui fournissent un accès granulaire pour un service spécifique et sont gérés par Google Cloud. Il existe de nombreux rôles prédéfinis, vous pouvez **voir tous ceux-ci avec les privilèges qu'ils ont** [**ici**](https://cloud.google.com/iam/docs/understanding-roles#predefined_roles).
- **Rôles personnalisés**, qui fournissent un accès granulaire selon une liste de permissions spécifiée par l'utilisateur.

Il existe des milliers de permissions dans GCP. Pour vérifier si un rôle a une permission, vous pouvez [**chercher la permission ici**](https://cloud.google.com/iam/docs/permissions-reference) et voir quels rôles l'ont.

Vous pouvez également [**chercher ici les rôles prédéfinis**](https://cloud.google.com/iam/docs/understanding-roles#product_specific_documentation) **offerts par chaque produit.** Notez que certains **rôles** ne peuvent pas être attachés à des utilisateurs et **uniquement à des SAs en raison de certaines permissions** qu'ils contiennent.\
De plus, notez que les **permissions** ne **prendront effet** que si elles sont **attachées au service pertinent.**

Ou vérifiez si un **rôle personnalisé peut utiliser une** [**permission spécifique ici**](https://cloud.google.com/iam/docs/custom-roles-permissions-support)**.**

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

## Utilisateurs <a href="#default-credentials" id="default-credentials"></a>

Dans la **console GCP**, il **n'y a pas de gestion des Utilisateurs ou Groupes**, cela se fait dans **Google Workspace**. Bien que vous puissiez synchroniser un autre fournisseur d'identité dans Google Workspace.

Vous pouvez accéder aux **utilisateurs et groupes de Workspaces** à [**https://admin.google.com**](https://admin.google.com/).

**MFA** peut être **forcée** pour les utilisateurs de Workspaces, cependant, un **attaquant** pourrait utiliser un jeton pour accéder à GCP **via cli qui ne sera pas protégé par MFA** (il sera protégé par MFA uniquement lorsque l'utilisateur se connecte pour le générer : `gcloud auth login`).

## Groupes

Lorsqu'une organisation est créée, plusieurs groupes sont **fortement suggérés à être créés.** Si vous gérez l'un d'eux, vous pourriez avoir compromis tout ou une partie importante de l'organisation :

<table data-header-hidden><thead><tr><th width="299.3076923076923"></th><th></th></tr></thead><tbody><tr><td><strong>Groupe</strong></td><td><strong>Fonction</strong></td></tr><tr><td><strong><code>gcp-organization-admins</code></strong><br><em>(groupes ou comptes individuels requis pour la liste de contrôle)</em></td><td>Administrer toute ressource appartenant à l'organisation. Attribuez ce rôle avec parcimonie ; les administrateurs d'organisation ont accès à toutes vos ressources Google Cloud. Alternativement, comme cette fonction est hautement privilégiée, envisagez d'utiliser des comptes individuels au lieu de créer un groupe.</td></tr><tr><td><strong><code>gcp-network-admins</code></strong><br><em>(requis pour la liste de contrôle)</em></td><td>Créer des réseaux, sous-réseaux, règles de pare-feu et dispositifs réseau tels que Cloud Router, Cloud VPN et équilibreurs de charge cloud.</td></tr><tr><td><strong><code>gcp-billing-admins</code></strong><br><em>(requis pour la liste de contrôle)</em></td><td>Configurer des comptes de facturation et surveiller leur utilisation.</td></tr><tr><td><strong><code>gcp-developers</code></strong><br><em>(requis pour la liste de contrôle)</em></td><td>Concevoir, coder et tester des applications.</td></tr><tr><td><strong><code>gcp-security-admins</code></strong><br></td><td>Établir et gérer des politiques de sécurité pour l'ensemble de l'organisation, y compris la gestion des accès et les <a href="https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints">politiques de contraintes d'organisation</a>. Consultez le <a href="https://cloud.google.com/architecture/security-foundations/authentication-authorization#users_and_groups">guide des fondations de sécurité Google Cloud</a> pour plus d'informations sur la planification de votre infrastructure de sécurité Google Cloud.</td></tr><tr><td><strong><code>gcp-devops</code></strong></td><td>Créer ou gérer des pipelines de bout en bout qui soutiennent l'intégration et la livraison continues, la surveillance et le provisionnement des systèmes.</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>(plus par défaut)</em></td><td>Surveiller les dépenses sur les projets. Les membres typiques font partie de l'équipe financière.</td></tr><tr><td><strong><code>gcp-platform-viewer</code></strong><br><em>(plus par défaut)</em></td><td>Examiner les informations sur les ressources à travers l'organisation Google Cloud.</td></tr><tr><td><strong><code>gcp-security-reviewer</code></strong><br><em>(plus par défaut)</em></td><td>Examiner la sécurité cloud.</td></tr><tr><td><strong><code>gcp-network-viewer</code></strong><br><em>(plus par défaut)</em></td><td>Examiner les configurations réseau.</td></tr><tr><td><strong><code>grp-gcp-audit-viewer</code></strong><br><em>(plus par défaut)</em></td><td>Voir les journaux d'audit.</td></tr><tr><td><strong><code>gcp-scc-admin</code></strong><br><em>(plus par défaut)</em></td><td>Administrer le Security Command Center.</td></tr><tr><td><strong><code>gcp-secrets-admin</code></strong><br><em>(plus par défaut)</em></td><td>Gérer les secrets dans le Secret Manager.</td></tr></tbody></table>

## **Politique de Mot de Passe par Défaut**

- Appliquer des mots de passe forts
- Entre 8 et 100 caractères
- Pas de réutilisation
- Pas d'expiration
- Si des personnes accèdent à Workspace via un fournisseur tiers, ces exigences ne s'appliquent pas.

<figure><img src="../../../images/image (20).png" alt=""><figcaption></figcaption></figure>

<figure><img src="../../../images/image (22).png" alt=""><figcaption></figcaption></figure>

## **Comptes de service**

Ce sont les principaux que **les ressources** peuvent **avoir** **attachés** et accéder pour interagir facilement avec GCP. Par exemple, il est possible d'accéder au **jeton d'authentification** d'un compte de service **attaché à une VM** dans les métadonnées.\
Il est possible de rencontrer certains **conflits** lors de l'utilisation à la fois de **IAM et des portées d'accès**. Par exemple, votre compte de service peut avoir le rôle IAM de `compute.instanceAdmin`, mais l'instance que vous avez compromise a été limitée par la restriction de portée de `https://www.googleapis.com/auth/compute.readonly`. Cela vous empêcherait d'apporter des modifications en utilisant le jeton OAuth qui est automatiquement attribué à votre instance.

C'est similaire aux **rôles IAM d'AWS**. Mais contrairement à AWS, **tout** compte de service peut être **attaché à n'importe quel service** (il n'est pas nécessaire de l'autoriser via une politique).

Plusieurs des comptes de service que vous trouverez sont en fait **générés automatiquement par GCP** lorsque vous commencez à utiliser un service, comme :
```
PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_ID@appspot.gserviceaccount.com
```
Cependant, il est également possible de créer et d'attacher des **comptes de service personnalisés** aux ressources, qui ressembleront à ceci :
```
SERVICE_ACCOUNT_NAME@PROJECT_NAME.iam.gserviceaccount.com
```
### **Clés & Jetons**

Il existe 2 principales façons d'accéder à GCP en tant que compte de service :

- **Via des jetons OAuth** : Ce sont des jetons que vous obtiendrez à partir d'endroits comme les points de terminaison de métadonnées ou en volant des requêtes http et ils sont limités par les **portées d'accès**.
- **Clés** : Ce sont des paires de clés publiques et privées qui vous permettront de signer des requêtes en tant que compte de service et même de générer des jetons OAuth pour effectuer des actions en tant que compte de service. Ces clés sont dangereuses car elles sont plus compliquées à limiter et à contrôler, c'est pourquoi GCP recommande de ne pas les générer.
- Notez qu'à chaque fois qu'un SA est créé, **GCP génère une clé pour le compte de service** à laquelle l'utilisateur n'a pas accès (et qui ne sera pas listée dans l'application web). Selon [**ce fil**](https://www.reddit.com/r/googlecloud/comments/f0ospy/service_account_keys_observations/), cette clé est **utilisée en interne par GCP** pour donner accès aux points de terminaison de métadonnées afin de générer les jetons OAuth accessibles.

### **Portées d'accès**

Les portées d'accès sont **attachées aux jetons OAuth générés** pour accéder aux points de terminaison de l'API GCP. Elles **restreignent les permissions** du jeton OAuth.\
Cela signifie que si un jeton appartient à un Propriétaire d'une ressource mais n'a pas la portée dans le jeton pour accéder à cette ressource, le jeton **ne peut pas être utilisé pour (ab)user de ces privilèges**.

Google recommande en fait [de ne pas utiliser](https://cloud.google.com/compute/docs/access/service-accounts#service_account_permissions) les **portées d'accès et de s'appuyer totalement sur IAM**. Le portail de gestion web impose en fait cela, mais les portées d'accès peuvent toujours être appliquées aux instances en utilisant des comptes de service personnalisés de manière programmatique.

Vous pouvez voir quelles **portées** sont **assignées** en **interrogeant :**
```bash
curl 'https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=<access_token>'

{
"issued_to": "223044615559.apps.googleusercontent.com",
"audience": "223044615559.apps.googleusercontent.com",
"user_id": "139746512919298469201",
"scope": "openid https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/appengine.admin https://www.googleapis.com/auth/sqlservice.login https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/accounts.reauth",
"expires_in": 2253,
"email": "username@testing.com",
"verified_email": true,
"access_type": "offline"
}
```
Les **scopes** précédents sont ceux générés par **défaut** en utilisant **`gcloud`** pour accéder aux données. Cela est dû au fait que lorsque vous utilisez **`gcloud`**, vous créez d'abord un jeton OAuth, puis l'utilisez pour contacter les points de terminaison.

Le scope le plus important de ceux-ci est **`cloud-platform`**, ce qui signifie essentiellement qu'il est possible d'**accéder à n'importe quel service dans GCP**.

Vous pouvez **trouver une liste de** [**tous les scopes possibles ici**](https://developers.google.com/identity/protocols/googlescopes)**.**

Si vous avez des identifiants de navigateur **`gcloud`**, il est possible d'**obtenir un jeton avec d'autres scopes,** en faisant quelque chose comme :
```bash
# Maybe you can get a user token with other scopes changing the scopes array from ~/.config/gcloud/credentials.db

# Set new scopes for SDKs credentials
gcloud auth application-default login --scopes=https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/cloud-platform,https://www.googleapis.com/auth/sqlservice.login,https://www.googleapis.com/auth/appengine.admin,https://www.googleapis.com/auth/compute,https://www.googleapis.com/auth/accounts.reauth,https://www.googleapis.com/auth/admin.directory.user,https://www.googleapis.com/auth/admin.directory.group,https://www.googleapis.com/auth/admin.directory.domain,https://www.googleapis.com/auth/admin.directory.user

# Print new token
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>"
```
## **Politiques IAM Terraform, Liens et Adhésions**

Comme défini par terraform dans [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), en utilisant terraform avec GCP, il existe différentes manières d'accorder à un principal l'accès à une ressource :

- **Adhésions** : Vous définissez **des principaux comme membres de rôles** **sans restrictions** sur le rôle ou les principaux. Vous pouvez mettre un utilisateur comme membre d'un rôle, puis mettre un groupe comme membre du même rôle et également définir ces principaux (utilisateur et groupe) comme membres d'autres rôles.
- **Liens** : Plusieurs **principaux peuvent être liés à un rôle**. Ces **principaux peuvent toujours être liés ou être membres d'autres rôles**. Cependant, si un principal qui n'est pas lié au rôle est défini comme **membre d'un rôle lié**, la prochaine fois que le **lien est appliqué, l'adhésion disparaîtra**.
- **Politiques** : Une politique est **autoritaire**, elle indique des rôles et des principaux et ensuite, **ces principaux ne peuvent pas avoir plus de rôles et ces rôles ne peuvent pas avoir plus de principaux** à moins que cette politique ne soit modifiée (pas même dans d'autres politiques, liens ou adhésions). Par conséquent, lorsqu'un rôle ou un principal est spécifié dans une politique, tous ses privilèges sont **limités par cette politique**. Évidemment, cela peut être contourné si le principal a la possibilité de modifier la politique ou des permissions d'escalade de privilèges (comme créer un nouveau principal et le lier à un nouveau rôle).

## Références

- [https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/](https://about.gitlab.com/blog/2020/02/12/plundering-gcp-escalating-privileges-in-google-cloud-platform/)
- [https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy](https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy)

{{#include ../../../banners/hacktricks-training.md}}
