Security & trust
What the collector reads. What it never writes.
The collector observes your Proxmox VE hosts read-only. This page details the rights it is granted, what leaves your infrastructure, what never does, and how to verify all of it yourself.
01 · In plain terms
Four statements, each verifiable below.
Each one can be checked below: rights matrix, sudo rule and flow diagram.
- The collector reads, it never writes : no automatic action is performed on a node, a VM or a container, and no write permission is requested from Proxmox VE.
- No inbound channel to the collector : the collector opens its own outbound connection to the console. It opens no port and the Proxmox API is never exposed to the internet.
- No root account to read the hosts : a dedicated system account with no password, constrained by a forced command and a sudo rule that forbids any argument.
- Host keys are pinned : strict checking is enabled and automatic key updates are disabled; a changed key set is refused rather than accepted.
02 · Read rights
Source by source, right by right.
Four sources feed the console. Each one receives the minimum right its reading requires.
Rights granted to the collector
4 sources
| Source | What is read | Right granted | Write |
|---|---|---|---|
| Proxmox VE API | Nodes, VMs and containers, storages, networks, firewall, HA, tasks, accounts, roles, API tokens and certificates. | Passwordless account and a separate token, role PVEAuditor VM.Audit · Sys.Audit · Datastore.Audit |
None |
| Host logs | Tasks, authentications and errors kept as evidence, filtered on the host before sending. | Read by the fixed reader, with no interactive access. | None |
| SSH reader | Corosync, pmxcfs, file systems, watchdog, Ceph, LVM-thin, ZFS, APT repositories, targeted hardware counters, and the write date of the cluster configuration files, never their content. | Dedicated system account, forced command, sudo -n |
None |
| QEMU guest agent | Guest operating system, services and interfaces, according to the chosen profile: disabled, Basic or Extended. | Optional, dedicated role VM.GuestAgent.Audit | None |
- A source that would require broader privileges shows up as unreachable in Sources & evidence. No write permission is granted to unblock it, and the checks that depend on it stay “Not assessable”.
- The unrestricted guest-agent privilege is never granted to the main token: guest inspection stays bounded by the chosen profile.
03 · Reader account
An account that can run exactly one command.
On every prepared host, the collector key opens a session on a dedicated system account that has no usable shell. The sudo rule it installs is reproduced here verbatim.
proxtrace ALL=(root) NOPASSWD: /usr/local/libexec/proxtrace-read ""- Forced command : the authorized keys file only accepts restricted entries pointing at the fixed reader. Whatever command the client sends is ignored.
- Inert shell : the account shell does nothing but launch the reader, and ignores any argument passed to it.
- The account owns nothing : neither its keys nor its home directory belong to it: it cannot add a key or remove the forced command.
- No broadened rights : no general sudo rule, no extra group and no change to the host’s global SSH configuration.
- No package installed : the installer puts nothing on your hypervisors. If sudo is missing, the node reports it instead of widening its rights.
- Existing account refused : an account of the same name that ProxTrace did not create, that is privileged, or that belongs to another group is set aside.
04 · Host keys
Every host is authenticated by a pinned key.
Reads, installation probes and relay connections all use a stable host alias, so a change of address or management interface keeps the same expected identity.
- Strict checking : host key verification is required and automatic key updates are disabled. No key failure ever triggers an automatic acceptance.
- Administrative origin : public keys come from the local host key files and, for peers, from the per-node Proxmox trust file. A missing, invalid or altered source blocks that node.
- Change refused : a change to a known node’s key set is rejected; its former keys are kept and the other nodes keep working.
- No private key copied : no key scan is run, no administrative private key is copied, and the trust file stays owned by root.
- Shared connection : reads of the same node go through a single SSH connection, opened with the same key and the same pinned host key; each read remains a separate forced command. The connection is renewed at least every 30 minutes: a removed key or a changed host key takes effect within that time. The nodes’ journal does not record one session per read.
05 · What leaves
What leaves, and what stays with you.
The collector transmits the outcome of its observations and the evidence behind them. It does not transmit the contents of your machines, nor those of your backups.
What leaves your infrastructure
- Normalized observations and their fingerprints: inventory of nodes, machines, storages and networks.
- Events with their task identifier, node, the account or token involved and the source address.
- Before and after values of the configurations observed.
- The log lines kept as evidence for an event.
- The collector’s own state: version, source freshness and the size of its outbound queue.
What never leaves
- The contents of your machines’ disks and of your backups.
- The contents of the Proxmox private directory: only its permissions are observed.
- Raw kernel warning lines: only targeted counters are transmitted.
- One organization’s data to another: scope is enforced on the server side.
- A command from the console: there is none to receive.
06 · Direction of flow
One direction of flow only.
Data travels up from your hosts to the console, never the other way.
- Proxmox VE hostsRead-only API, filtered logs and the fixed reader run under the restricted account.
- Agent · Proxmox nodesNormalizes, deduplicates and queues locally. A single destination, over HTTPS.
- ProxTrace consoleAcknowledges receipt, normalizes and keeps the history in PostgreSQL.
- No return arrow : the console has no way to send a command, a script or an argument to the collector. The collector’s capabilities are fixed and determined by the version installed.
- Local queue : if the console is unreachable, observations wait in the collector’s local queue and are sent in batches once it is back, without loss.
- Removed only once acknowledged : the queue is cleared only after the exact list of accepted events comes back. A partial or invalid answer keeps the data for a retry.
- Bounded sizes : batches are capped on both sides, and compression is used only when it genuinely shortens the payload.
07 · Retention
Where the history lives, and what seals it.
History and reports live in the console database. How long they last depends on the deployment you chose.
- Sealed reports : the state of a given date stays readable exactly as it was assessed. A sealed report is not rewritten by a later evaluation.
- A single database : observations, events and reports are kept in PostgreSQL, on the console side. Self-hosted, that database and its backups are entirely yours.
- Retention period : it follows the effective configuration of the deployment hosting the console, and is not set by this page.
Per-organization retention settings, full data export and deletion on request are not available yet.
08 · SaaS or self-hosted
The console with us, or with you.
Either way, the collector stays installed in your environment and keeps exactly the same read rights.
SaaS
- We run the console; you only install the collector in your Proxmox VE.
- Observations travel over HTTPS to a single destination, fixed at enrolment.
- Several organizations coexist in the console, each within its own scope.
Self-hosted
- Server, interface and PostgreSQL together in a Docker Compose deployment, on your infrastructure.
- No observation leaves your network: the collector’s destination is your own console.
- You keep control of the database, its backups and the retention period.
09 · Limits
What ProxTrace does not do.
- Administer Proxmox VE : Proxmox VE remains the administration tool. ProxTrace performs no automatic action on nodes or machines.
- Monitor real-time metrics : continuous CPU, memory and network tracking remains the job of your monitoring tools.
- Certify an infrastructure : the checks assess best practices and keep the available evidence; that assessment is not a certification.
- Track another hypervisor : ProxTrace is built for Proxmox VE only, whether a cluster or a single host.
Open beta
Try ProxTrace on your cluster.
Free account, no credit card. The collector installs with one command and only reads.