Connect an OVHcloud project
The API application and the consumer key limited to the needed routes, the optional S3 pair for buckets, and what Ctadel reads.
This page describes the API application and the consumer key to create so that an OVHcloud Public Cloud project is inventoried, the rights to give it, and what the collector reads.
What you need
Three values from the OVHcloud API and the project id:
| Value | Where to get it |
|---|---|
| "Application Key" and "Application Secret" | Create an application on https://eu.api.ovh.com/createApp/ (ovh-eu endpoint). |
| "Consumer Key" | Request it with POST /auth/credential for the application, or on https://eu.api.ovh.com/createToken/, limited to the routes below and with no expiry date; then validate it in the customer panel. |
| "Project ID" | The Public Cloud project id (Public Cloud, "Project settings"). |
One Ctadel account corresponds to one Public Cloud project. Account-level resources (dedicated servers, DNS zones, IAM policies, Identity users, API applications and credentials, KMS keys) are read with the same account and attached to your customer id, shared by every Ctadel account of the same OVHcloud account.
Routes to allow on the consumer key
Read, for the inventory:
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/*The POST .../kube/*/kubeconfig route serves the Kubernetes scanner: it delivers the kubeconfig of each MKS cluster. The /v2/okms/resource routes serve the reading of KMS keys.
Write, only for the analysis of instance disks:
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 snapshots the volume, creates a scanner instance named ctadel-scanner-<suffix> that receives its login key and its SSH host key through its user data, mounts the copy, reads it, then deletes the instance, the volumes and the snapshot. No SSH key is registered in the project through the API, so as not to fire your own "SSH key added" detection rule. The instance has no security group; its initial configuration accepts port 22 only from the egress address of your Ctadel instance.
The optional S3 pair
API keys do not read object contents. To analyse the content of Object Storage buckets (secrets, personal data), create an Object Storage user in the project (Public Cloud, "Users & Roles") and generate S3 credentials for it; enter them under "Object Storage S3 access key (optional)" and "Object Storage S3 secret key (optional)". Ctadel then reads objects on s3.<region>.io.cloud.ovh.net. Without this pair, buckets are inventoried and their configuration evaluated, but their content is not read.
Declaring the project in Ctadel
- Open "Settings", tab "Integrations", sub-tab "Cloud Providers", then "Add account" on the OVHcloud row.
- Enter a "Label", the "Application Key", the "Application Secret", the "Consumer Key" and the "Project ID".
- Enter the S3 pair if you created one.
- Click "Create".
Credentials are not checked on entry: the first scan calls GET /me and the project, and the account's state shows any error.
What the collector reads
| Family | Resources read |
|---|---|
| Account | Customer id, Identity users, API applications and credentials (status, allowed IP addresses, last use, expiry), IAM policies and their document. |
| Compute | Public Cloud instances, volumes, snapshots, the project's SSH keys, AI Deploy applications, container registries (plan, visibility), dedicated servers (IPMI, monitoring, billing). |
| Network | Private networks (vRack) and subnets, security groups and their rules, load balancers, DNS zones and records (DNSSEC). |
| Data | S3 Object Storage buckets per region and Swift containers, managed databases (engine, version, plan, nodes, backups, network). |
| Kubernetes | MKS clusters (private network, API address restrictions, update policy) and their node pools. |
| Keys | KMS keys (state, algorithm and size, operations, age). |
Limitations
- At the time of writing, no scan has yet been run against a real OVHcloud account.
- The content of managed databases is not analysed: only their configuration is read. A content analysis that does not touch the production service is under study.
- The API exposes neither ACLs nor bucket policies: an S3 bucket's visibility stays unknown rather than being written as "private".
- In IAM policies, only user-type identities are linked to the inventory; accounts and groups are not inventoried.
- A consumer key with an expiry date stops the recurring scans with it.
- Access to an MKS cluster's objects goes through the kubeconfig the API delivers, not through a read-only identity.
- Detection on the account's API call log (
GET /me/api/logs) is under internal validation, not available to customers.