1dc1d2f3a1
Assistant: codex Assistant-Model: gpt-6.1-sol Assistant-Session: 01a126e1-76f8-7643-8cf3-e93336539ade
98 lines
6.1 KiB
Markdown
98 lines
6.1 KiB
Markdown
# Activity-core unattended release admission
|
|
|
|
Owner: ACTIVITY-WP-0041-T03, with RPF-WP-0048-T02 for platform activation.
|
|
Status: proposed contract; no credential minted and no automatic sync enabled.
|
|
The user authorized implementation; these are enforcement requirements, not a
|
|
request to reapprove the existing adoption.
|
|
|
|
## Required enforcement
|
|
|
|
Use a dedicated non-admin service principal. Separate producer and reviewer
|
|
identities. Public source reads need no repository credential. A general repository
|
|
write PAT cannot enforce image-only changes by itself: the executor must validate
|
|
the exact before/after commits and authenticated receipts before writing, while
|
|
protected branches and required checks prevent bypass. Restrict its repository
|
|
membership to the release repository and reconciliation to the single
|
|
`activity-core/activity-core` application. This installation is ArgoCD Core:
|
|
there is no ArgoCD API-server role/token lane to reuse. Kubernetes RBAC cannot
|
|
restrict Application patch access to only the operation fields. Use a narrowly
|
|
implemented sync broker with admission enforcement before granting such patch
|
|
access; an Application-scoped Kubernetes Role alone is insufficient. No root-wide
|
|
sync, arbitrary application spec updates, project updates, exec, prune, overrides,
|
|
secrets or other applications.
|
|
|
|
The present parent Application pins the child's source revision in the platform
|
|
repository. Therefore an app-only ArgoCD sync grant alone cannot perform durable
|
|
promotion. Implement a reviewed broker for the single child revision field or a
|
|
separately reviewed source-tracking design; do not grant the executor unrestricted
|
|
platform repository writes to work around this boundary.
|
|
|
|
Keep credentials in OpenBao with the existing delivery subsystem; never in Git,
|
|
receipts or prompts. Publish the exact subject, repository/branch/path scope,
|
|
ArgoCD resource, TTL, revocation and negative-test evidence before admission.
|
|
The warden routing catalog currently has no ready release-specific lane. Do not
|
|
reuse source-read or package-admin credentials as deployment authority.
|
|
|
|
## Receipt and failure requirements
|
|
|
|
Authenticate CI completion against the expected Forgejo repository and full commit;
|
|
require the image-build and smoke checks. Bind the independently authenticated
|
|
reviewer result to that same commit and actual image digest. Fetch current ArgoCD
|
|
health from its authority, with bounded staleness; preserve observations proving
|
|
at least 24 healthy hours. Producer-provided booleans are insufficient.
|
|
|
|
Before promotion retain the exact prior source revision and protect both live and
|
|
rollback images in the additive registry inventory. Serialize releases, compare
|
|
the current revision before writing, persist state, and recover idempotently after
|
|
restart. Reconcile through ArgoCD without pruning. Check deployment readiness,
|
|
report sink and schedule invariants. On timeout/failure revert the pinned revision
|
|
through the same Git path, reconcile, verify recovery, and stop further promotion
|
|
if recovery fails. Store sanitized receipts in the activity-core/State Hub run.
|
|
|
|
Acceptance must include denied out-of-scope mutation, stale/mismatched/forged
|
|
receipts, concurrent release, restart, failed health and successful rollback.
|
|
Run destructive failure fixtures in an isolated environment; production must not
|
|
be intentionally broken to manufacture proof. Admit only after tests and the
|
|
observation gate pass. Access, budget or scope expansion stays a monthly decision.
|
|
|
|
## Deterministic platform readiness gate
|
|
|
|
`python3 scripts/activity_promotion_readiness.py --live --observation observation.json
|
|
--receipt readiness.json` verifies only the current bounded adoption and reports
|
|
an explicit owner-proof wait until ACTIVITY-WP-0041-T03 acceptance exists. This
|
|
read-only check neither creates a principal nor activates a release worker. D2
|
|
removes the founder reapproval; the identity/custody and runtime proofs above
|
|
remain required. ACTIVITY-WP-0042 scheduling acceptance does not supply them.
|
|
|
|
Later activation checks require operator-owned `--trusted-owner-key` (raw
|
|
32-byte Ed25519 public key) and `--trusted-owner-principal`, supplied separately
|
|
from `--owner-acceptance`. No signer key supplied inside a receipt is trusted.
|
|
The acceptance envelope has exactly `payload` and `signature` (base64 Ed25519
|
|
signature of sorted compact JSON). Its payload uses
|
|
`schema_version: activity-core-release-acceptance/v1`, binds the existing
|
|
`owner_task: ACTIVITY-WP-0041-T03`, issuer, dedicated release principal,
|
|
`authority: ACTIVITY-WP-0041-image-only-v1`, application, exact estate cluster UID,
|
|
adoption revision and full broker implementation revision. It expires within
|
|
five minutes; the operator owns signer admission/revocation and actual native
|
|
evidence verification. An agent must not synthesize this production acceptance
|
|
from test fixtures or a producer's booleans.
|
|
|
|
The `targets` mapping is the exact single platform child
|
|
`targetRevision` path on `main`, selective root sync of only activity-core,
|
|
child activity-core and prune false, as named in the checker. `checks` must
|
|
contain exactly its named acceptance checks, all actual owner-verified: bounded
|
|
identity/custody/revocation/denials, independent authenticated receipts/CI digest
|
|
binding, continuous observer, image-only scope, source CAS/single-flight,
|
|
restart/lost-response recovery, retention, real failed-health rollback, Temporal
|
|
registration, durable audit sink and report/schedule invariants.
|
|
`continuous_health` binds the adoption revision and a current actual 24h sampled
|
|
interval with at most 90-second gaps. A source timestamp or snapshot is not this
|
|
proof. Signatures authenticate the accepted owner's assertions; the owner still
|
|
must ground them in actual runtime receipts.
|
|
|
|
Native adoption mismatch or malformed/forged/stale/widened owner acceptance
|
|
returns unverified. Missing owner acceptance/trust binding returns waiting on
|
|
the existing owner task, with its cross-owner coordination case. Only ready
|
|
returns exit code zero. No automatic-sync source candidate is generated:
|
|
ACTIVITY-WP-0041's current broker contract still relies on explicit selective
|
|
manual child/root sync and forbids an automated child policy.
|