Use IAM application resource-control and policy Scoped backup access.
OpenBao path is platform/workloads/railiance/backup/object-storage.
rapp-postgres keeps Secret platform-pg-backup-s3 as the first projection.
Publish capacity, recovery, labor, and allocation-driver evidence for
resource:railiance:apps-pg so resource-control can forecast and allocate
without reading application data or inventing booked cost.
Document the one recipe a new rapp uses to acquire runtime secrets:
standing KV secrets bind through a CCR target.rapp, leases through
grant rapp_id. Stamp the existing postgres grants and the qonto
workload CCR. Gate, delivery, and revocation are unchanged.
Converge the S3 platform-service pattern onto ADR-0007, emit the
reef-railiance live deployable inventory for the family coverage
check, and mark T02 done. Declaration edits land in rapp-openbao
and rapp-postgres.
Gitea has been replaced by Forgejo. Updates prose mentions in docs/ while
deliberately preserving live names that a blind sweep would have broken:
GITEA_BACKEND_TOKEN is a provisioned OpenBao field in CCR-2026-0002, GITEA_URL
is a Makefile variable, and gitea-db is a running cnpg cluster. Capitalisation
discriminates prose from identifiers. Archived workplans are left as historical
record.
Blueprint 5.2: forge placement decided - workload to rapp-forgejo, layer
responsibility to S4 railiance-enablement, which already declares the handoff
contract and gains its first concrete owned responsibility.
Blueprint 5.6: whether Railiance should use ArgoCD at all is recorded as an open
decision rather than acted on by removing mentions. S3 runs four live ArgoCD
Applications plus AppProjects, and the two most recent commits here add more, so
deleting the documentation would describe a system that does not exist. The
question is real; it needs a decision and a migration, not a docs edit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Operator design review considered binding bounded rapp context to Forgejo orgs
or State Hub domains and rejected both. OAS P1 governs - independent
perspectives must stay in separate dimensions - and cardinality forces it: a
repo has exactly one Forgejo org (a path segment in the clone URL) so org:repo
is 1:many, while rapp:repo is many:many, and a many:many grouping cannot be
derived from a 1:many one.
Records the dimension table, the composition block (first-party member repos
plus pinned upstream components and a stated purpose), and the precision that
makes enforcement well-defined: repos are many:many with rapps but deployables
are 1:1, so the validator can ask whether every live deployable belongs to
exactly one rapp. That is the coverage check that would have caught all three
of this survey's drift findings at once.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
T01: docs/rapp-platform-service-pattern.md generalizes the ownership split
already drawn in the rapp-openbao and rapp-postgres boundary docs into a
reusable four-question test, a reference rapp.yaml for platform services, the
grouped-rapp member rule, and the credential-lane position. It deliberately
does not restate the four-axis model, which railiance-master owns.
T03/T04/T05: proposals routed to the repos that own the model rather than
authored here - reef-railiance (bound_rapps lists 1 of 3 live rapps, and should
be derived rather than hand-listed), railiance-master (rapp.schema.json plus a
family declaration validator, grouped-rapp members field, wave-2 candidate
refresh), the-custodian (canon promotion of the four-axis model, which also
closes the open C-31 multi-segment prefix failures).
T02 is held until the schema settles so the platform rapps and the schema do
not converge on different answers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Add cnpg-option-a-backup JSON runner, vendored static age, kubectl install
helper, and ESO policy path for offsite lane so railiance01 workers can
upload without workstation OIDC (RAILIANCE-WP-0016).
Align path and fields (API_KEY, API_USER) with provisioned secret; policy and
OIDC role applied; agent-high-risk-boundary deny on data path. Front door ready.
34 candidates, 0 errors, no live tag in would_delete. state-hub
main-1cf949b protected via railiance01 live-images export; helm-pinned
and cluster-scanned tags absent from candidates; activity-core's 19
candidates have no live registry consumer (prod runs a locally-imported
image). Token via forgejo-admin-api-token warden lane, no file drops.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Enable tenant commercial secrets: applier accepts mount tenants/, apply
policy and OIDC role for company-email IMAP (metadata only; values are
founder Red provision). Extend agent-high-risk-boundary for the path.
Establish proposed workload-kv-read custody for the Forgejo site-admin
PAT at platform/workloads/forgejo/forgejo-admin, sibling to forgejo-mailer.
OIDC workstation fetch mirrors the railiance-backup-offsite pattern.
List and optionally delete package versions beyond the newest three,
protecting production Helm image tags. Adds Make targets and unit tests
for ACTIVITY-WP-0020.
Remove interim ClusterSecretStores (forgejo, activity-core, reuse) from
coulombcore ArgoCD kustomization. Those stores target railiance01 namespaces
and are bootstrapped via railiance-apps/activity-core Make targets.
Switch openbao-activity-core ClusterSecretStore to interim coulombcore
token auth like forgejo/reuse, broaden the activity-core ESO policy to
include the shared issue-core runtime path, and document ESO-managed rotation.
Add workload KV lane for Nextcloud WebDAV token, URL, and age recovery
escrow at platform/workloads/railiance/backup/offsite-lane. Apply read
policy and OIDC role railiance-backup-workload-kv-read; wire forgejo-backup
to load credentials from OpenBao when env is unset.
Commented seal "transit" stanza in the OpenBao server config plus an
'Auto-Unseal via Transit Seal' doc section covering provisioning, seal
migration, pod-restart proof, and the net-kingdom console evidence flags.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
