Documentation

Appearance

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 #

ComponentDefault identityWhat it should reach
Rescue planedataplicityIdentity, outbound connection, remote-access files and commands allowed to that user
SupervisordpagentDesired state, broker, feature state, optional runtime groups
Product applicationYour service identityProduct hardware and the loopback contract you choose
Privileged helpersroot through fixed command pathsAllowlisted RAUC, console, and product-runtime operations supplied by the image

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.

Dataplicity OS uses system containerd through rootful nerdctl and ctr wrappers allowlisted for dpagent; it does not install Docker Engine. Managed containers normally use host networking to reach the host-local broker. Restrict the broker to its local product contract and do not place device cloud credentials in a container.

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.

Dataplicity OS console boundary #

Production Dataplicity OS locks admin on every boot, disables sshd, and ships no UFW allow rule for port 22. A cloud-requested console unlock sends a password hash for temporary physical-console access. It does not enable SSH or alter the firewall. Passwords, SSH, extra tools, and the debug build channel are available only in the explicit staging debug profile.

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?