Scaleway, OVHcloud, OUTSCALE: why treat them on par with AWS

The European teams we meet rarely have a single cloud. A legacy at OVHcloud, production at Scaleway, a contract that imposes OUTSCALE for a qualified scope, and AWS or Azure for everything that came from an acquisition or a partner. Their security tool covers three of the six. The other three are blind spots.

What “covering a cloud” means

Putting a cloud’s logo on a page costs nothing. Covering it takes five building blocks, and each one is often missing.

1. The API inventory. Instances, volumes, networks, security groups, identities and policies, managed databases, clusters, buckets, encryption keys, functions, registries, DNS, load balancers. Each cloud has its own APIs, its own pagination, its own way of describing a private address or a policy.
2. Rules written for its services. An AWS rule about an S3 bucket does not transpose to a Scaleway bucket by renaming: the encryption, versioning, logging and public-policy options have neither the same names nor the same defaults.
3. Reading the contents. Copying a disk or a database means asking the cloud for a snapshot, a restore, an ephemeral instance. APIs, delays and limits differ everywhere.
4. Activity logs. Who created what, disabled which log, opened which port, from which address. Log-based detection means reading each cloud’s format.
5. Code. Terraform rules for each cloud’s provider, to catch the problem before it is deployed.

Without these five blocks, a resource of that cloud does not enter the graph, and an attack path that crosses it does not exist for the tool.

What Ctadel reads on the French clouds

On Scaleway, Ctadel reads the whole product range through the API: instances, volumes, private networks and gateways, security groups, IAM, managed databases, Kapsule, object storage, Key Manager, Serverless, registries, DNS, load balancers, Audit Trail. Disks and PostgreSQL databases are copied and read inside your project.

On OVHcloud, Public Cloud, dedicated servers, Managed Kubernetes Service, object storage and KMS, with a consumer key limited to reads and, if you wish, an S3 credential pair to read buckets.

On OUTSCALE, virtual machines, volumes, snapshots, images, networks, security groups, EIM, OKS, object storage, VPNs and direct links, with a dedicated EIM user. The frameworks displayed include SecNumCloud, for the scopes that require it.

For each of the three, the same scanners as everywhere else: configuration, identities, data, secrets, Kubernetes, hosts, vulnerabilities, logs, code, and the attack paths that connect it all. The Scaleway, OVHcloud and OUTSCALE pages detail what is read, what is checked and the access requested.

What it changes when you have several

The value is not in covering each cloud on its own. It is in the shared graph.

• The same person, present in AWS, in Azure and in Scaleway IAM under three identities, appears as one identity with effective permissions across all three.
• An attack path can start on an OVHcloud instance and end on a Scaleway bucket, if a key found on the first opens the second. A tool that covers both separately will not see it.
• The same framework (ISO 27001, PCI DSS, GDPR, SecNumCloud) is read across the whole scope, not cloud by cloud, with different rules but the same requirement in front.
• The same remediation panel offers the console, the command line and Terraform for the cloud concerned, and the ticket goes to the same tool.

And hosting in France

It is a bonus, not the argument. Each customer’s Ctadel instance runs with a French hosting provider; the details and subprocessors are in the trust centre. But if you choose Ctadel, let it be because it sees your six clouds in a single graph, not because its host is French.