Connecter un compte cloud

Où ajouter un compte, ce que chaque cloud demande, ce que Ctadel écrit ou n'écrit pas, et comment les identifiants sont conservés.

Cette page explique comment un compte cloud s'ajoute à Ctadel, ce qui est commun aux six clouds et où trouver le détail propre à chacun.

Où ajouter un compte

Ouvrez « Paramètres », onglet « Intégrations », sous-onglet « Fournisseurs cloud ». La page présente les « Comptes connectés » puis le « Catalogue », qui liste Scaleway, Amazon Web Services, Microsoft Azure, OVHcloud, 3DS OUTSCALE et Google Cloud Platform. Le bouton « Ajouter un compte » ouvre le dialogue « Ajouter un compte » du cloud choisi.

Il faut la permission « Modifier » du domaine « Paramètres », que porte le rôle « Global Admin ».

Chaque compte reçoit un « Libellé » libre (par exemple « Scaleway — Production ») et un identifiant de périmètre dans le champ « Account ID / Project ID » : un projet Scaleway, un compte AWS, un abonnement Azure, un projet Google Cloud, un projet OVHcloud ou un compte OUTSCALE.

Ce que chaque cloud demande

Cloud	Identifiant demandé	Vérification à la saisie
AWS	Un rôle à endosser (« ARN du rôle » et « Identifiant externe »), créé par le gabarit CloudFormation fourni ; ou une « Clé d'accès ».	Oui : le rôle est endossé, puis les comptes de l'organisation sont listés.
Azure	Un service principal : « Tenant ID », « Client ID (App ID) », « Client Secret », « Subscription ID ».	Oui : un jeton est demandé, puis les abonnements visibles sont listés.
Google Cloud	Une « Clé de service account (JSON) », clé de compte de service ou fichier de fédération d'identité ; « Organization ID » facultatif.	Partielle : seul l'identifiant de projet du fichier est lu, sans appel à l'API.
Scaleway	Une clé d'API : « Access Key » et « Secret Key ».	Oui : les projets de l'organisation sont listés.
OVHcloud	Une application API : « Application Key », « Application Secret », « Consumer Key » ; un couple « Clé d'accès S3 Object Storage » facultatif pour lire le contenu des buckets.	Non : les identifiants sont vérifiés au premier scan.
OUTSCALE	La clé d'accès d'un utilisateur EIM : « Access Key », « Secret Key », et la « Région » ; une entrée par région à scanner.	Non : l'identifiant de compte est vérifié au premier scan.

Droits de lecture pour l'inventaire, droits d'écriture pour les analyses de contenu

Les collecteurs d'inventaire n'écrivent jamais dans votre cloud : ils appellent les API de description et de listage. Les droits à accorder pour cet inventaire sont donnés page par cloud.

Quatre analyses lisent le contenu de vos ressources, et non plus seulement leur configuration. Deux d'entre elles créent des ressources dans votre compte : l'accès de Ctadel n'est en lecture seule que si vous ne les accordez pas. Chacune demande des droits supplémentaires que vous accordez ou non, indépendamment des autres :

Analyse	Ce que Ctadel fait	Ce que vous perdez sans ce droit
Disques des machines virtuelles	Un instantané du volume, une copie, puis une machine de scan temporaire qui lit la copie dans votre compte. Le contenu du disque ne sort pas de votre périmètre. Droits d'écriture : création et suppression d'instantanés, de volumes, d'instances, de paires de clés et de groupes de sécurité, suppression limitée aux ressources étiquetées Ctadel.	Vulnérabilités, secrets, données sensibles et conformité système trouvés sur les disques.
Bases de données	Une copie temporaire restaurée depuis un instantané, lue, puis supprimée. L'instance de production n'est jamais modifiée. Droits d'écriture : création d'instantanés, restauration et modification d'une instance temporaire, suppression limitée aux ressources étiquetées Ctadel.	La classification des données dans les bases ; leur posture (accès public, chiffrement, sauvegardes) reste lue.
Buckets	La lecture des objets, en place, et le déchiffrement si une clé gérée par vous les protège. Aucune écriture.	Secrets et données sensibles dans les objets ; la posture des buckets reste lue.
Kubernetes	L'enregistrement de Ctadel comme identité du cluster. Sur EKS, cet enregistrement automatique associe la politique administrateur du cluster ; créer l'accès vous-même avec le groupe `ctadel-scanner` limite les droits à la lecture (voir Connecter un cluster Kubernetes).	Rien, si vous créez l'accès vous-même.

Les ressources temporaires créées pour ces analyses portent une étiquette Ctadel. Au scan suivant du compte, le scanner de disques supprime celles de plus de deux heures qu'une interruption aurait laissées ; ce balayage n'a lieu qu'au moment d'un scan, quand Ctadel détient les identifiants du compte. Sur AWS, ces quatre analyses correspondent aux paramètres EnableDiskScanning, EnableDatabaseScanning, EnableBucketScanning et EnableKubernetesAccess du gabarit ; les autres clouds les traduisent en rôles ou en identifiants séparés, décrits sur leur page.

Comment les identifiants sont conservés

Les identifiants d'un compte sont chiffrés en AES-256-GCM avant d'être écrits dans la base de Ctadel, avec une clé propre à votre instance et générée à sa création. Ils ne sont déchiffrés que pour être remis aux collecteurs au moment d'un scan. L'interface ne les réaffiche jamais : dans le dialogue « Modifier le compte », les champs secrets indiquent « (inchangé si vide) ».

Pour un compte AWS déclaré par rôle, aucun secret permanent n'est conservé : au début de chaque scan, Ctadel endosse le rôle avec l'identifiant externe et obtient des identifiants temporaires. La session demandée dure douze heures, ou une heure si le rôle n'accepte pas davantage. Supprimer le rôle dans votre compte coupe l'accès.

Découverte et création en masse

Le bouton « Découvrir les abonnements » (Azure) ou « Découvrir les projets » (autres clouds) interroge le cloud avec les identifiants saisis. Sur Scaleway, Azure et AWS, c'est aussi le test de validité : une clé refusée renvoie l'erreur du cloud au lieu d'une liste vide.

Sur AWS, si le rôle vit dans le compte de gestion d'une organisation et peut lister ses comptes, la découverte renvoie tous les comptes actifs ; le bouton « Ajouter les N comptes » les crée d'un coup, chacun avec un rôle du même nom dans le compte membre. Sans ce droit, la découverte retombe sur le compte courant.

Sur Google Cloud, OVHcloud et OUTSCALE, la découverte ne fait aucun appel : elle renvoie l'identifiant lu dans le fichier ou saisi dans le formulaire.

Projets et dossiers

Chaque compte cloud est un projet au sens de Ctadel : c'est le périmètre sur lequel un rôle peut être limité et sur lequel les pages se filtrent. Un compte nouvellement créé est rangé dans le dossier système des comptes non classés ; vous pouvez ensuite le déplacer dans l'arbre de « Dossiers » du même onglet. Voir Projets et dossiers.

Après la création

Un premier scan est déclenché à la création. Le compte apparaît dans « Comptes connectés » avec son état : « En attente », « Sync... », puis « Connecté », « Scan partiel » (certains collecteurs ont échoué ; la dernière erreur s'affiche au survol) ou « Erreur ». Les scans suivants suivent la planification de l'instance ; voir Premier inventaire.

Depuis la même liste, vous pouvez modifier le compte, le désactiver (un compte désactivé n'est plus scanné) ou le supprimer après « Confirmer ».

Pour AWS, OUTSCALE et Google Cloud, le dialogue contient une section « Réseau du scanner de disques (facultatif) » : sous-réseau, adresse privée, transport. Elle est décrite dans Réglages du scanner.

Pages par cloud

Limites

Les identifiants OVHcloud et OUTSCALE ne sont pas vérifiés à la saisie ; une erreur n'apparaît qu'au premier scan, dans l'état du compte.
Sur Google Cloud, la découverte ne liste pas les projets d'une organisation ; le mode organisation passe par le champ « Organization ID », décrit sur la page du cloud.
Il n'y a pas de bouton pour relancer ou tester un seul compte depuis cette liste ; un scan complet se lance depuis l'onglet « Général », « Scanner maintenant ».