Agentless

Ctadel installs no software on your servers, containers or workstations. Everything it knows comes from four sources: your clouds' APIs, a copy of your disks, a temporary copy of your PostgreSQL databases and the contents of your buckets. This page describes each method, then what it cannot do.

Cloud APIs

One collector per cloud queries the management APIs with the access you granted, read access for this part: an AWS role, an Azure service principal, a Google Cloud service account, a Scaleway, OVHcloud or OUTSCALE API key. It retrieves the list of resources and their configuration: instances, volumes, networks, security groups, identities, managed databases, clusters, buckets, keys, logs. This inventory feeds the graph and the configuration rules. The page for each cloud in Getting started gives the exact permissions.

The disk copy

To read the inside of a server, Ctadel does not connect to it. It asks the cloud for a copy of the disk and reads that copy in your account, on a short-lived machine:

1. A snapshot of the volume is created.
2. A scratch volume is restored from the snapshot.
3. A scanner instance is started in your account, with the scratch volume attached and a key pair generated for this run.
4. The volume is mounted read-only on the instance.
5. Three passes read the mount point: the search for secrets and sensitive data, the list of installed packages (the system's package database, then the Windows registry for NTFS disks) for vulnerabilities, and the host configuration checks.
6. The instance, the scratch volume and the snapshot are deleted, in reverse order of creation.

Deletion happens exactly once, on success, on failure at any step and when the scan is interrupted. A resource whose creation returned an identifier and then failed is deleted too. What is created lives in your account and is billed to you for as long as it exists; the Scanner settings page describes the network the instance is placed in.

These creations, like the temporary database copy described below, need write permissions in your account (creating and deleting snapshots, volumes, instances, key pairs, security groups, database instances), granted on top of the inventory's read permissions. Without them, the API inventory works and these contents are not read. "Agentless" therefore does not mean "read-only": the Connect a cloud account page details what each analysis needs.

The original server is never touched: no SSH connection, no command, no agent. Volumes of managed Kubernetes nodes are skipped, since application data lives in persistent volumes; a disk with no filesystem, or none that can be mounted, is reported as unread rather than as clean.

The temporary database copy

For managed databases, Ctadel never reads the production instance. It asks the cloud to restore a temporary instance, creates a read account named ctadel_dspm_scanner with a generated password on it, reads, then deletes the instance. Here too, deletion happens exactly once, whatever the outcome.

Reading is a sample: in each database, for each column of text, JSON, XML or similar type across every non-system schema, 100 rows picked at random are examined by the sensitive-data rules. Only a masked sample (two characters on each side) is kept per rule and per column, with the number of matches and the row count of the table. Beyond 5,000 columns the result is marked incomplete and no earlier finding is closed.

Only PostgreSQL is read, on AWS RDS, Google Cloud SQL and Scaleway. Other engines are refused before any copy, so you are not billed for a useless restore.

Buckets

The object reader connects directly to the bucket with the granted access (S3, Google Cloud Storage, Azure Blob, OVHcloud and OUTSCALE over S3) and lists its contents, up to 100,000 objects. Empty objects and objects in an archive storage class are skipped. A text file is read as a sample of at most 10 MB; a PDF, an archive or an office document is downloaded in full up to 50 MB and its text extracted. The secret and sensitive-data rules run on the resulting text. Nothing is written to the bucket.

If the listing was truncated, or some objects could not be read, the result is marked incomplete and the findings of unseen objects stay open.

Kubernetes clusters

For a managed cluster, Ctadel obtains access to the cluster API through the cloud API. For a cluster declared with a kubeconfig, the file is checked before use: any exec plugin, auth provider, file path, proxy or non-HTTPS server is refused, and only inline tokens and certificates are accepted. Cluster objects are read through the API; container images are pulled and analysed on your Ctadel instance. No component is deployed inside the cluster.

What the method does not allow

The disk copy is a photograph of the system at rest. It holds the boot configuration, not the state in memory. Host rules account for this:

Check type	Reading from a disk copy
Configuration files, permissions, ownership, kernel parameters, accounts, password policy, SUID, world-writable files	Read
Service active	Read as "enabled at boot"; the finding says so. Whether a service is running right now cannot be known
Package installed, mount options, audit rules, kernel modules	Read from the package database, /etc/fstab, the auditd rules and the modprobe configuration
Command output (command_output)	SKIPPED: no command is run on the host
Windows user rights (windows_user_rights) and advanced audit policy (windows_audit_policy)	SKIPPED: these settings are not read from a disk copy

Rules of the last three types are disabled in the catalogue, with the reason written into their description. A rule aimed at a distribution, a Windows server role or a kind of host other than the one being read is marked SKIPPED and says why, never passed or failed. A configuration file absent from the disk (software not installed) also yields SKIPPED.

Limits

• No command is run on your hosts; checks that depend on one are SKIPPED or disabled.
• Host checks run on a system volume only; a data volume or a Kubernetes persistent volume is read for secrets and sensitive data alone. Immutable systems (Container-Optimized OS, Flatcar, Bottlerocket) receive no host checks.
• Volumes of managed Kubernetes nodes and some legacy volume types are not copied.
• A volume where no filesystem could be mounted (LVM, unsupported format, damaged disk) is a refused scan, not a disk without findings.
• The package list depends on Internet access from the scanner instance; without it, the disk's vulnerabilities are not evaluated.
• The secret search on a disk is bounded to 30 minutes per volume.
• Managed databases: only PostgreSQL is read; Aurora, MySQL, SQL Server and other engines are refused. Azure SQL and OVHcloud managed databases are not read at all.
• Database reading is a sample of 100 rows per column: a rare value may not appear in it.
• Buckets: at most 100,000 objects per bucket, 10 MB per text file, 50 MB per file to extract; unreadable formats (legacy .doc, truncated archive) are skipped.
• Each copy (snapshot, volume, instance, restored database) is billed by your cloud for as long as it exists.