Shared responsibility

Where the platform’s responsibility ends and yours begins.

SPEKTRA Edge runs your containers on your hardware. That splits ownership in a way that is obvious once stated and a frequent source of surprise until then: the platform is responsible for getting your workload running and keeping the device healthy, and you are responsible for what is inside the workload.

This page draws the line. Most questions of the form “does SPEKTRA Edge handle X for me?” are answered by finding X in one of the two columns below.

The division

Area Platform You
Device identity and onboarding Issues device identity, attests hardware, enrolls the device Physically install the device; supply site network details
Device OS Ships, upgrades, and rolls back SPEKTRA Edge OS Choose when to upgrade; test your workload against a version
Connectivity to the platform Maintains the outbound control-plane connection Allow the required egress; keep the clock accurate
Disk encryption Seals the storage key to the TPM and unlocks at boot Keep the recovery passphrase
Deployment Delivers desired state and starts, restarts, and reports on containers Define the distribution, pod template, and labels
The container image Pulls it and runs it Build it; patch it; own its base image and dependencies
Application configuration Delivers config maps and secrets to the container Decide what the values are and how the app reads them
Application identity — Authenticate and authorize your application’s own users
Application data in transit Encrypts platform traffic Encrypt your application’s own protocols
Filesystem permissions Provides the mount Match the image’s UID/GID to the mounted directory
Application egress — Configure your app’s own proxy, DNS, and TLS trust
Application keys Uses the TPM for device identity and disk encryption Manage your own application keys, including any TPM use
Monitoring Collects device metrics, logs, and audit records Emit useful application logs and metrics
Backups of application data — Back up whatever you store on the device

What this means in practice

A few consequences come up often enough to state directly.

Deploying a third-party workload does not normally require anything from us. If the software ships as a container and expects a normal Linux environment, you package it, point a distribution at some labelled devices, and bind-mount its data directory. Platform changes only become necessary when a workload needs something the platform does not expose — unusual hardware, a kernel module, a privileged network mode, or a lifecycle the container model does not cover. If you are unsure, the question to ask is whether the workload needs anything outside its container.

Nothing about your application’s traffic is automatic. The platform’s own connection is encrypted and, where configured, proxied. Your application’s connections are not: they do not inherit the device proxy settings, they are not encrypted on your behalf, and the platform does not terminate TLS for them.

The TPM is not a general-purpose key store for your application. The device TPM is used for device identity and to seal the disk-encryption key, releasing it only when the boot state is as expected. An application that wants to generate or hold its own keys in the TPM has to talk to the TPM itself and speak the relevant protocol. The platform neither manages those keys nor mediates that access. See TPM attestation.

File permissions behave exactly as they would anywhere else. The platform adds no special handling. If the image runs as a non-root UID and the bind-mounted host directory is owned by root, the container cannot write to it — the same as on any Docker host. See Storage.