Connecter un projet ou une organisation Google Cloud
La clé de compte de service ou la fédération d'identité, les rôles à accorder, le mode organisation et ce que Ctadel lit.
Cette page décrit l'identité à donner à Ctadel sur Google Cloud, en mode projet unique ou organisation, les rôles à lui accorder et ce que le collecteur lit.
Ce qu'il vous faut
Un fichier d'identifiants JSON, de l'un des deux types suivants :
| Type | Quand le choisir |
|---|---|
| Clé de compte de service | Le cas courant. Le fichier contient une clé privée et l'identifiant du projet du compte de service. |
Fichier external_account (fédération d'identité de charge de travail) | Quand votre organisation interdit la création de clés de compte de service (contrainte iam.disableServiceAccountKeyCreation). Le fichier ne contient ni clé privée ni identifiant de projet. |
Le fichier se colle tel quel dans le champ « Clé de service account (JSON) ». Les identifiants ne sont pas vérifiés à l'enregistrement : l'application lit seulement l'identifiant de projet du fichier, sans appel à Google Cloud. Le collecteur demande le périmètre cloud-platform au premier scan ; un fichier refusé apparaît alors dans l'état du compte.
Projet unique ou organisation
Le champ « Organization ID » décide du mode :
- vide : Ctadel lit le projet du compte de service, celui que porte le fichier ;
organizations/<numéro>: Ctadel recherche tous les projets actifs visibles par l'identité, remonte leur arborescence de dossiers jusqu'à l'organisation, et lit ceux qui en dépendent. Les projets visibles mais rattachés à une autre organisation sont ignorés. Les politiques IAM des dossiers traversés sont lues, car un rôle accordé sur un dossier s'applique à tous ses projets.
Un identifiant qui n'est pas un numéro d'organisation (un dossier, un domaine) est refusé au lieu d'être ignoré.
Rôles à accorder
Au niveau de l'organisation en mode organisation, du projet en mode projet unique :
| Rôle | Ce qu'il donne |
|---|---|
roles/viewer | L'inventaire général, dont les règles de pare-feu VPC et les politiques de pare-feu réseau globales et régionales. |
roles/iam.securityReviewer | Les politiques IAM des projets, des dossiers et de l'organisation, les comptes de service. |
roles/browser | La hiérarchie de l'organisation : recherche des projets et lecture des dossiers. Mode organisation seulement. |
roles/monitoring.viewer, roles/logging.viewer | Les politiques d'alerte et les destinations de journaux. |
roles/accessapproval.viewer | Les réglages d'approbation d'accès. |
roles/policyanalyzer.activityAnalysisViewer | La dernière authentification des comptes de service, pour détecter les comptes dormants. |
roles/serviceusage.serviceUsageViewer | La liste des API activées par projet. |
Activez sur le projet hôte du compte de service les API cloudresourcemanager, compute, container, iam, logging, monitoring, dns, cloudkms, cloudfunctions, run, sqladmin, storage, bigquery, accessapproval, essentialcontacts, policyanalyzer, serviceusage et securitycenter, plus celles des services que vous utilisez.
Analyses de contenu
| Analyse | Droits à accorder | Ce que fait Ctadel |
|---|---|---|
| Disques des machines virtuelles | roles/compute.storageAdmin restreint par condition à l'étiquette ctadel-managed, et roles/compute.instanceAdmin.v1 sur le projet qui accueille la machine de scan. | Un instantané du disque, étiqueté ctadel-managed, est monté sur une machine de scan temporaire, puis supprimé. |
| Bases Cloud SQL | Des droits d'administration Cloud SQL sur le projet de l'instance : clonage, modification des réseaux autorisés, suppression. | L'instance est clonée sous le nom ctadel-dspm-<horodatage>, le clone n'accepte que l'adresse de sortie de votre instance Ctadel, il est lu puis supprimé. L'instance d'origine n'est pas modifiée. |
| Buckets Cloud Storage | Un rôle de lecture des objets sur les buckets. | Les objets sont lus en place avec le même fichier d'identifiants. |
| Jeux de données BigQuery | roles/bigquery.dataViewer sur les jeux de données. | Les cent premières lignes de chaque table sont lues en place par l'API de lecture ; aucune requête n'est lancée, rien n'est copié. |
| Clusters GKE | Un rôle de lecture sur les clusters. | Un kubeconfig est construit avec un jeton OAuth2 de courte durée du compte de service, puis les objets du cluster sont lus. |
Déclarer le compte dans Ctadel
- Ouvrez « Paramètres », onglet « Intégrations », sous-onglet « Fournisseurs cloud », puis « Ajouter un compte » sur la ligne Google Cloud Platform.
- Saisissez un « Libellé ».
- Laissez « Organization ID » vide, ou saisissez
organizations/<numéro>. - Collez le fichier JSON dans « Clé de service account (JSON) ».
- Cliquez sur « Créer ».
« Découvrir les projets » ne fait pas d'appel à Google Cloud : il affiche l'identifiant de projet lu dans le fichier.
Ce que le collecteur lit
| Famille | Ressources lues |
|---|---|
| Organisation et projets | Réglages de l'organisation, approbation d'accès, politiques IAM de l'organisation, des dossiers et des projets, métadonnées de projet, API activées, Security Command Center. |
| Identités | Comptes de service, leurs clés et leur dernière authentification. |
| Calcul | Instances Compute Engine et leurs disques, clusters GKE, Cloud Functions, Cloud Run, Cloud Build, Artifact Registry. |
| Réseau | Réseaux VPC et sous-réseaux, règles de pare-feu et politiques de pare-feu réseau, répartiteurs de charge, Cloud Armor, zones DNS. |
| Données | Buckets Cloud Storage, instances Cloud SQL, BigQuery, Memorystore, Pub/Sub, Dataflow, Dataproc, Composer. |
| Clés et journaux | Clés Cloud KMS, destinations de journaux, politiques d'alerte Monitoring. |
| IA | Vertex AI : modèles, points de terminaison et ressources associées, par emplacement. |
Limites
- Les politiques de pare-feu hiérarchiques (organisation, dossier) ne sont pas lues ; seules les politiques réseau globales et régionales le sont.
- Avec un fichier de fédération d'identité, le mode projet unique n'est pas possible : le fichier ne porte pas d'identifiant de projet et le formulaire n'en demande pas. Renseignez un « Organization ID ».
- La dormance d'un compte de service se déduit de l'âge de sa plus ancienne clé gérée par l'utilisateur ; un compte sans clé de ce type reste « inconnu ».
- Si la politique IAM d'un bucket ou d'un dépôt Artifact Registry ne peut pas être lue, sa visibilité reste inconnue, sauf si une ACL le déclare public.
- Un emplacement Vertex AI qui refuse l'appel (API non activée, produit non disponible) est ignoré ; un refus de permission est signalé comme tel, pas comme « rien ».
- Un dossier illisible pendant la remontée de l'arborescence n'exclut pas le projet situé dessous.
- La lecture des journaux d'audit pour la détection (rôle
roles/logging.privateLogViewer) est en validation interne, non disponible pour les clients.