Agentless does not mean read-only

The promise “agentless, read-only” is on many websites. It is half true, and the false half deserves to be explained before you sign, not after your IAM team’s review.

What really is read-only

The inventory: instances, volumes, networks, security groups, identities, managed databases, clusters, buckets, keys, logs. All of it comes from your clouds’ management APIs and is read with read access: an AWS role with the audit policies, an Azure service principal with Reader on the subscription, a Google Cloud service account, a Scaleway, OVHcloud or OUTSCALE API key limited to reads.

With that access alone, Ctadel already knows a lot: the configuration of every resource, the effective permissions of identities, the ports open to the world, the Kubernetes clusters and their contents, the code in your repositories, and the attack paths that connect all of it.

What cannot be

To know what is inside a server, there are two methods. Install an agent that runs permanently on your side. Or ask the cloud for a copy of the disk and read it elsewhere. Ctadel does the second, and that is where read-only stops.

For a disk, Ctadel creates a snapshot of the volume, restores a working volume, starts an ephemeral instance in your account with that volume mounted read-only, searches it for secrets, sensitive data, the list of installed packages and host settings, then deletes the instance, the volume and the snapshot. The original server is never touched: no connection, no command.

For a managed database, Ctadel never reads the production instance. It requests a restore into a temporary instance, reads a sample of every text column there, then deletes it.

Creating a snapshot, a volume, an instance, a key pair, a security group, a database instance: these are write permissions. Saying otherwise would be false.

How they are requested

Three design choices make these permissions acceptable to an IAM team.

• They are separate. The AWS template has one option per capability: disk copy, database copy, bucket content reading, cluster access. On Scaleway, OVHcloud, OUTSCALE, Azure and Google Cloud, the copy permissions are a separate policy. Each one can be disabled: the inventory works, those contents are simply not read.
• They are bounded. The scan instance lives in your account, in a subnet you choose, with a security group restricted to the single egress address of your Ctadel instance. If that group cannot be created, the scan fails rather than opening up.
• Everything is destroyed, exactly once. On success, on failure at any step or on interruption, the instance, the working volume and the snapshot are deleted in reverse order of creation. A resource whose creation returned an identifier and then failed is deleted too.

What is created is billed by your cloud for as long as it exists, a few minutes per volume. The Agentless page describes each step and what a disk copy cannot see: memory state, a service running right now, the output of a command.

The question to ask any vendor

“To read inside my servers, what do you create in my account, with which permissions, and what happens if the scan crashes halfway?” If the answer is “nothing, we are read-only”, either the vendor does not analyse your disks, or it installs an agent, or it is not telling you everything.

Ctadel’s permission templates for each cloud are in the connection documentation, readable before any demonstration.