Skip to content

Define multi-identity workload security contract #65

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
omry wants to merge 1 commit into from
Closed

Define multi-identity workload security contract #65

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 20 additions & 3 deletions docs/FUTURE_DIRECTIONS.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
---
status: Active
updated: 2026-07-06
updated: 2026-08-14
summary: Current parking lot for longer-term product directions outside the near-term release path.
---

Expand Down Expand Up @@ -76,6 +76,22 @@ Open questions:
- Can the generated app control script stay identical across Docker Engine,
Docker Desktop, Colima/Lima, and VM-backed runtimes?

### Isolated Multi-Identity Workloads

Some applications need several image-local UIDs and GIDs while remaining
untrusted and isolated from host accounts and other workloads. Reploy's threat
model, identity boundary, lifecycle terminology, and acceptance ledger are
recorded in
[`MULTI_IDENTITY_SECURITY_CONTRACT.md`](MULTI_IDENTITY_SECURITY_CONTRACT.md).

The initial capability will be Podman-only and provide two explicit profiles:
an exact mapping of accepted identities and a bounded contiguous range. Docker
Engine must reject both profiles before workload mutation, even where it can
approximate the range profile. Product integration may begin only after
repeated probes prove private, non-overlapping subordinate mappings, each
profile's identity boundary, and loss of identity-changing authority before
untrusted application execution. No public blueprint schema is defined yet.

### Podman Userland Backend

Evaluate Podman as a uniform user-scope backend for Reploy. Podman is
Expand All @@ -86,8 +102,9 @@ closer across platforms: stage, build, run, install, generated control script,
and uninstall would all exercise installed-app behavior without requiring
Linux root/systemd system services for the common user-scope case.

This should be evaluated as a backend option, not assumed as a replacement for
the current Docker/systemd and Docker-managed paths. On macOS and Windows,
Multi-identity workloads make Podman a required second backend, but that does
not make it a general replacement for the current Docker/systemd and
Docker-managed paths. On macOS and Windows,
Podman containers still run on the host machine inside a Linux VM, so the
security and lifecycle promises are VM-backed userland promises rather than
native OS service promises. On Linux, rootless Podman depends on host
Expand Down
Loading
Loading