carlos / platform Public

Require console signatures on authoritative assignment states

Paul Campbell pushed by paul@keymail.dev 1 month ago 124f14645cf7d45ca91b228aeaf9c334afdeafe0 parent 76414c0

1 file changed, +3 −3

implementation/maintenance-worker-identity/proposal.json +3 −3

diff --git a/implementation/maintenance-worker-identity/proposal.json b/implementation/maintenance-worker-identity/proposal.json

index d0a64d9e1..80b3ad5bc 100644

--- a/implementation/maintenance-worker-identity/proposal.json

+++ b/implementation/maintenance-worker-identity/proposal.json

@@ -4,7 +4,7 @@

"scope": "Initial shared/root platform boxes only, exactly one eligible enrolled box for the target region/pool. Customer fleet targets and ambiguous multi-box placement refuse. Do not distribute deployment decryption keys to customer machines.",

"isolation_prerequisite": "Do not create/persist/activate worker credential or accept private maintenance input on a box with unisolated tenant processes. Existing isolated-exec design revision13 (platform126) owns tenant mount/PrivatePIDs/IMDS/cgroup isolation and must supply observed runtime/layout checks. File0600 owned by carlos cannot isolate secrets from current flat same-UID children. No competing isolation implementation or unchecked feature boolean.",

"identity": "Dedicated maintenance workers, not customer fleets. Reuse canonical per-box token-hash/label conventions only; never put worker credentials in fleet_boxes or human/service auth. Therefore existing fleet tunnel/store/placement doors cannot confer worker authority and need no platform-kind extension. Customer fleets remain unsupported.",

- "authoritative_storage": "Deployment store only for worker admission/revocation and publication state; SQLite never supplies authority or monotonic generation. Existing trusted control-store boundary applies: root signatures authenticate writers but do not by themselves prevent replay of old signed objects by a privileged store administrator. Do not claim anti-rollback against that stronger attacker.",

+ "authoritative_storage": "Deployment store only for worker admission/revocation and publication state; SQLite never supplies authority or monotonic generation. Existing trusted control-store boundary applies: root signatures authenticate writers but do not by themselves prevent replay of old signed objects by a privileged store administrator. Do not claim anti-rollback against that stronger attacker. A stolen old bearer plus privileged ability to roll back all control objects is NOT covered; this requires an independent control-store write boundary. Review must distinguish external token revocation from compromise of platform-wide IAM.",

"head": {

"key": "control/maintenance/workers/<logical-label>/head.json",

"wire": "Closed bounded root-signed control record using existing release signed-wrapper/signature mechanics, disjoint required kind/schema. Contains deployment origin, ops account, logical label, physical box identity digest, generation, token hash, status(active/revoking/detached), placement, candidate identity/digest, audit metadata, and at most8 registered immutable assignment references.",

@@ -15,7 +15,7 @@

"assignment_state": {

"key": "control/maintenance/assignments/<assignment-id>/state.json",

"purpose": "One authoritative typed server-internal CAS record per immutable assignment, covering preflight, compatibility intermediate, execution outcome and resume publication. Their accepted references live in this record so each publication and revocation contend on THE SAME object, independent of console count.",

- "wire": "Bounded closed object with immutable assignment digest/scope/enrollment generation, monotonic revision, disabled flag, and fixed optional accepted preflight/compatibility/execution/resume references. No generic object key/write API. Type validators enforce approved protocol per-kind field/phase rules. Only trusted console code writes it; no offline worker receipt format is added.",

+ "wire": "Bounded closed root-signed server-internal control record with immutable assignment digest/scope/enrollment generation, monotonic revision, disabled flag, and fixed optional accepted preflight/compatibility/execution/resume references. Require console root signature before accepting any state/ref. Type validators enforce approved protocol per-kind field/phase rules. No generic object key/write/signing API and no offline worker receipt format; CLI continues using authenticated server responses and opaque references.",

"create": "Create immutable assignment and initial state, then CAS active worker head to register its exact reference. Until registered, state grants no execution/publication authority. Failed registration leaves inert orphan. Immutable assignment binds record/account/app/host/request/attempt/placement/worker generation; owner approval later binds exact preflight and assignment.",

"publish": "Authenticate current head and registered assignment; read enabled assignment-state snapshot. Recompute/verify approved request/record/artifact/environment/input/recipient/worker-evidence bindings, persist encrypted private payload and immutable receipt create-only. CAS accepted reference into the SAME enabled assignment state using its ETag. This CAS is the acceptance point. CAS conflict requires fresh validation; never retry against a disabled snapshot. Identical publication-ID retry is idempotent; changed bytes conflict. Accepted result does not grant serving resume.",

"projections": "Guard advances and public status/result projections happen only from accepted authoritative assignment-state refs. A projection alone is never accepted provenance. Missing/delayed projection is unavailable or pending until deterministic reconciliation. Current request/attempt checks prevent old accepted refs from entering a newer operation. Compatibility intermediate and final resume refs remain distinct as approved protocol requires; neither can be replaced with a terminal guard CAS alone.",

@@ -31,7 +31,7 @@

"bootstrap": "After observed isolation gate, worker durably creates once a random32-byte token in privatefile.CreateExclusiveDurable storage with protected parent, checked fsync and no replacement on restart. Candidate contains only hash, random candidate ID, physical identity/label and placement; publish through supported agent control-store path. Signed console-origin discovery uses reviewed existing root release signing wrapper, explicit kind, canonical HTTPS origin and persisted monotonic discovery watermark. Ops-owner workers admit selects exact candidate via supported CLI/API; no operator SSH/SSM step. Conflicting candidate/label refuses. Explicit detach/re-admit controls rotation; no self-reactivation.",

"assignment_and_execution": {

"owner_box": "Use stable logical box label (existing valid 1-32-character name), not fleet/label or fleet name. Existing guard continuity keeps OwnerBox fixed; replacing physical hardware under the same logical label requires explicit owner re-enrollment and a new credential generation. Changing logical label for an existing guard is unsupported until a reviewed guard migration.",

- "immutable": "Server creates assignment bound to deployment origin, fleet/kind/account, logical box label, enrollment generation and token-hash identity, app/account/host, request/attempt, record identity/revision and exact placement observation. Request body copies do not select principal or assignment.",

+ "immutable": "Server creates assignment bound to deployment origin, dedicated worker kind/ops account, logical box label, enrollment generation and token-hash identity, app/account/host, request/attempt, record identity/revision and exact placement observation. Request body copies do not select principal or assignment.",

"placement": "Region/pool metadata only establishes eligibility. Target refuses unless exactly one active enrolled shared/root worker matches authoritative deployment placement and current inventory. No first-claim selection. Owner approval binds assignment digest. Serving authority additionally requires global guard/projection, proven local stop and continuously retained per-host lease; enrollment never proves stop or lease ownership.",

"stop": "Use reviewed FenceAndStop and retained lease/executor evidence; missing activator entry is not stop evidence. No remote stop or inference from elapsed lease TTL. Checked quiescence must precede execution."