Docker / Build evidence and production operations / Lesson 17

Rootless operation and image supply-chain evidence

Reduce daemon authority while verifying where release content came from and what supporting metadata actually proves.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Distinguish rootless daemon, container USER, and user-namespace remapping.
Assess trusted origins, digests, SBOMs, provenance, and policy checks.

Rootless changes the daemon authority boundary

Rootless Docker runs both the daemon and containers within a non-root user's user-namespace arrangement. This differs from merely selecting USER 10001 in a container under a rootful daemon, and from userns-remap where the daemon itself remains rootful. Reduced host authority can limit some consequences of compromise, but does not eliminate kernel risk, credential theft, or dangerous access granted to the user. Review the complete trust boundary rather than treating the rootless label as a security certificate.

Identity mapping and resource support remain explicit

Rootless operation depends on host prerequisites such as user-namespace support and subordinate id mappings. Resource control support also depends on cgroup and service-manager configuration; cgroup v2 with appropriate systemd delegation matters for supported controls. Storage ownership, low-numbered ports, networking, and host integration can differ from rootful behavior. This course never installs or reconfigures those host facilities. Prefer an approved pre-provisioned environment and ordinary high ports rather than changing privileged host settings to copy a tutorial.

bash Read the selected endpoint and security mode

docker context show
docker info --format '{{json .SecurityOptions}}'

The context identifies which endpoint would be queried, and the info field can report active security options for an authorized engine. No fixed output is fabricated. A non-root username in a Dockerfile alone cannot establish that the daemon is rootless, and a client connected to another context may observe a completely different engine.

Digest identity is necessary but not sufficient trust

A digest verifies content identity relative to the bytes received, not the publisher's legitimacy or the application's safety. Define trusted registries, publishers, source repositories, and update reviewers. Signature verification requires an explicit policy for expected identity and claims; accepting any available signature is weak evidence. Pin reviewed content for adoption, preserve the resolved platform relationship, and regularly evaluate security updates instead of freezing a known vulnerable digest indefinitely.

An SBOM and provenance answer different questions

An SBOM inventories discovered components. Provenance describes aspects of how an artifact was produced, such as builder and source inputs. Neither proves the software is vulnerability-free or that all components were detected. Review metadata scope, generator trust, and linkage to the actual artifact digest. Provenance can expose build arguments and source details, so keep secrets out of those channels and choose an appropriate disclosure mode before sharing attestations.

bash Request supporting build attestations

# Review-only artifact plan for the complete source context:
docker buildx build --sbom=true --provenance=mode=min \
  --tag parcel-api:review --output type=oci,dest=parcel-reviewed.tar .

This command would build an OCI artifact with requested SBOM and provenance metadata using a compatible builder and generator. It is not executed. Attestation persistence depends on the output and image-store path; verify the exported metadata and its digest association rather than assuming requested flags prove durable available evidence.

Combine evidence into an adoption decision

A release policy can require approved source, controlled build inputs, linked provenance, a useful SBOM, vulnerability assessment, non-root runtime, and functional tests. Evaluate severity, exploitability, reachable components, and remediation deadlines rather than treating one scanner score as a complete decision. Keep exceptions explicit and time-bounded. Rootless operation reduces one authority surface, while supply-chain controls address content origin; they reinforce each other but cannot substitute for each other or for application-level security.

Common errors and fixes

USER 10001 is reported as proof of rootless Docker.

Why it happens: Container process identity was confused with daemon authority and endpoint mode.
How to fix it: Inspect the approved engine mode and selected context separately.
Prevent it next time: Keep daemon, host mapping, and application identities distinct in evidence.

A digest is trusted solely because its hash matches.

Why it happens: Content integrity was mistaken for publisher authorization or secure behavior.
How to fix it: Verify trusted origin, expected claims, policy checks, and the artifact link.
Prevent it next time: Define an adoption policy beyond hash equality.

Requested attestations are missing from the consumer artifact.

Why it happens: The export or image-store path did not retain or expose the expected metadata.
How to fix it: Inspect supported output behavior and verify the actual distributed artifact.
Prevent it next time: Test evidence preservation across build, registry, and promotion paths.

Check your understanding

1. Can a rootless daemon make an untrusted image safe to run without review?

Show worked solution

No. It reduces some daemon-related host authority but the image can still access granted files, credentials, network destinations, and user resources. Verify content origin and behavior, minimize those grants, and assess the kernel and tenancy boundary before adopting untrusted workloads.

2. Why keep an SBOM linked to a digest instead of only a mutable tag?