Modern agent security and privilege model

The useful security property is not simply “outbound-only.” It is that each on-device responsibility has a bounded identity and path. Your image, permissions and runtime choices determine whether those bounds remain narrow.

Device identity and network

After provisioning, the modern agent authenticates with a device-specific identity. Keep its credential files readable only by the required service accounts and never copy one device's state into another production image.

Connections are initiated by the device over HTTPS. Customer networks do not need inbound port forwarding for Dataplicity access. They still need correct DNS, certificate trust, time and outbound policy. See Firewall requirements.

Linux privilege boundary

Component	Default identity	What it should reach
Rescue plane	dataplicity	Identity, outbound connection, remote-access files and commands allowed to that user
Supervisor	dpagent	Desired state, broker, feature state, optional runtime groups
Product application	Your service identity	Product hardware and the loopback contract you choose
Privileged helper	root through a fixed command path	RAUC install, RAUC mark-good and reboot only

Remote Shell inherits the rescue user's Linux permissions. Fleet jobs through the agent do not inherently become root.

Adding groups, ACLs, credentials, device nodes, sockets or sudo rules expands the effective remote boundary. Review those grants as product security changes.

Container runtime boundary

Membership of a Docker-compatible runtime group is commonly equivalent to broad host control. Grant it only to the supervisor on products that use Class Software, and treat the decision accordingly in your threat model.

Dataplicity-managed containers should be distinguishable from your other host containers. The platform must not mutate unrelated workloads merely because it can inventory them.

Storage and secrets

Identity and state live under /var/lib/dataplicity. Treat backups, support bundles and decommissioned storage as credential-bearing material.

On A/B images, persistence is required for identity and state. Persistence is not the same as confidentiality: choose filesystem protection, full-disk encryption and physical controls appropriate to the product.

RAUC boundary

The unprivileged supervisor may request only fixed helper operations. Bundle size, digest, signature, compatible identity, target version and inactive-slot policy are checked before installation.

This does not replace:

• secure boot or key protection;
• a bootloader attempt counter;
• automatic fallback to the previous good slot;
• physical failed-boot testing;
• product-specific post-boot validation.

See RAUC image OTA requirements.

Security review questions

1. Which people and systems can provision a device identity?
2. What can the dataplicity and dpagent users read, write and execute?
3. Is a container-runtime group really required?
4. Does the product remain locally safe during cloud loss or a delayed command?
5. Which state survives reimage, and how is it erased at decommissioning?
6. Are agent, product application and OS/image changes independently auditable?