Connecter un projet OVHcloud

L'application API et la consumer key limitée aux routes nécessaires, le couple S3 facultatif pour les buckets, et ce que Ctadel lit.

Cette page décrit l'application API et la consumer key à créer pour qu'un projet Public Cloud OVHcloud soit inventorié, les droits à lui donner, et ce que le collecteur lit.

Ce qu'il vous faut

Trois valeurs issues de l'API OVHcloud et l'identifiant du projet :

Valeur	Où l'obtenir
« Application Key » et « Application Secret »	Créez une application sur `https://eu.api.ovh.com/createApp/` (point d'entrée `ovh-eu`).
« Consumer Key »	Demandez-la par `POST /auth/credential` avec l'application, ou sur `https://eu.api.ovh.com/createToken/`, limitée aux routes ci-dessous et sans date d'expiration ; puis validez-la dans l'espace client.
« Project ID »	L'identifiant du projet Public Cloud (Public Cloud, « Paramètres du projet »).

Un compte Ctadel correspond à un projet Public Cloud. Les ressources de niveau compte (serveurs dédiés, zones DNS, politiques IAM, utilisateurs Identity, applications et credentials API, clés KMS) sont lues avec le même compte et rattachées à votre identifiant client, commun à tous les comptes Ctadel du même compte OVHcloud.

Routes à autoriser sur la consumer key

Lecture, pour l'inventaire :

GET  /me
GET  /me/api/credential
GET  /me/api/credential/*
GET  /me/api/application
GET  /me/api/application/*
GET  /me/identity/user
GET  /me/identity/user/*
GET  /iam/policy
GET  /iam/policy/*
GET  /cloud/project/<PROJECT_ID>
GET  /cloud/project/<PROJECT_ID>/*
POST /cloud/project/<PROJECT_ID>/kube/*/kubeconfig
GET  /dedicated/server
GET  /dedicated/server/*
GET  /domain/zone
GET  /domain/zone/*
GET  /v2/okms/resource
GET  /v2/okms/resource/*

La route POST .../kube/*/kubeconfig sert au scanner Kubernetes : elle lui délivre le kubeconfig de chaque cluster MKS. Les routes /v2/okms/resource servent à la lecture des clés KMS.

Écriture, uniquement pour l'analyse des disques d'instances :

POST   /cloud/project/<PROJECT_ID>/volume/*/snapshot
DELETE /cloud/project/<PROJECT_ID>/volume/snapshot/*
POST   /cloud/project/<PROJECT_ID>/volume/*/attach
POST   /cloud/project/<PROJECT_ID>/volume/*/detach
DELETE /cloud/project/<PROJECT_ID>/volume/*
POST   /cloud/project/<PROJECT_ID>/instance
DELETE /cloud/project/<PROJECT_ID>/instance/*

Ctadel prend un instantané du volume, crée une instance de scan nommée ctadel-scanner-<suffixe> qui reçoit sa clé de connexion et sa clé d'hôte SSH par ses données utilisateur, monte la copie, la lit, puis supprime instance, volumes et instantané. Aucune clé SSH n'est enregistrée dans le projet par l'API, pour ne pas déclencher votre propre règle de détection « clé SSH ajoutée ». L'instance n'a pas de groupe de sécurité ; sa configuration initiale n'accepte le port 22 que depuis l'adresse de sortie de votre instance Ctadel.

Le couple S3 facultatif

Les clés API ne lisent pas le contenu des objets. Pour analyser le contenu des buckets Object Storage (secrets, données personnelles), créez un utilisateur Object Storage dans le projet (Public Cloud, « Users & Roles ») et générez-lui des identifiants S3 ; renseignez-les dans « Clé d'accès S3 Object Storage (optionnel) » et « Clé secrète S3 Object Storage (optionnel) ». Ctadel lit alors les objets sur s3.<région>.io.cloud.ovh.net. Sans ce couple, les buckets sont inventoriés et leur configuration évaluée, mais leur contenu n'est pas lu.

Déclarer le projet dans Ctadel

Ouvrez « Paramètres », onglet « Intégrations », sous-onglet « Fournisseurs cloud », puis « Ajouter un compte » sur la ligne OVHcloud.
Saisissez un « Libellé », l'« Application Key », l'« Application Secret », la « Consumer Key » et le « Project ID ».
Renseignez le couple S3 si vous l'avez créé.
Cliquez sur « Créer ».

Les identifiants ne sont pas vérifiés à la saisie : le premier scan appelle GET /me et le projet, et l'état du compte indique l'erreur éventuelle.

Ce que le collecteur lit

Famille	Ressources lues
Compte	Identifiant client, utilisateurs Identity, applications et credentials API (statut, adresses IP autorisées, dernière utilisation, expiration), politiques IAM et leur document.
Calcul	Instances Public Cloud, volumes, instantanés, clés SSH du projet, applications AI Deploy, registres de conteneurs (plan, visibilité), serveurs dédiés (IPMI, supervision, facturation).
Réseau	Réseaux privés (vRack) et sous-réseaux, groupes de sécurité et leurs règles, répartiteurs de charge, zones et enregistrements DNS (DNSSEC).
Données	Buckets Object Storage S3 par région et conteneurs Swift, bases de données managées (moteur, version, plan, nœuds, sauvegardes, réseau).
Kubernetes	Clusters MKS (réseau privé, restrictions d'adresses de l'API, politique de mise à jour) et leurs pools de nœuds.
Clés	Clés KMS (état, algorithme et taille, opérations, âge).

Limites

Au moment de la rédaction, aucun scan n'a encore été exécuté contre un vrai compte OVHcloud.
Le contenu des bases de données managées n'est pas analysé : seule leur configuration est lue. Une analyse de contenu qui ne touche pas le service de production est à l'étude.
L'API n'expose ni ACL ni politique de bucket : la visibilité d'un bucket S3 reste inconnue plutôt qu'écrite « privée ».
Dans les politiques IAM, seules les identités de type utilisateur sont reliées à l'inventaire ; les comptes et les groupes ne sont pas inventoriés.
Une consumer key avec date d'expiration arrête les scans récurrents avec elle.
L'accès aux objets d'un cluster MKS passe par le kubeconfig que l'API délivre, pas par une identité en lecture seule.
La détection sur le journal des appels API du compte (GET /me/api/logs) est en validation interne, non disponible pour les clients.