Close RAILIANCE-WP-0015-T06 rapp credential-lane binding
Some checks failed
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Has been cancelled

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.
This commit is contained in:
codex 2026-08-14 00:47:28 +02:00
parent 6ab882cc44
commit dfa6373985
10 changed files with 342 additions and 10 deletions

View file

@ -193,11 +193,12 @@ explicitly in `consumers:`. That is the shape to copy.
## Credential lanes
A platform-service rapp never owns credential custody. It declares what it
needs; S3 vends it through the existing broker. The binding between a rapp's
`runtime_dependencies` / `secret_references` and the S3 grant catalog and CCR
lanes is specified in `RAILIANCE-WP-0015-T06` — until that lands, follow
`docs/credential-broker.md` and `docs/credential-change-approval.md` directly
and do not create a package-local lane.
needs; S3 vends it through the existing broker. The bind is
`docs/rapp-credential-lane-binding.md`: standing secrets go through a CCR
and `secret_references`; short-lived leases go through the grant catalog
and `rapp_id`. Follow `docs/credential-broker.md` and
`docs/credential-change-approval.md` for gate, delivery, and revocation —
this pattern does not replace them.
The existing rule holds without exception: the package never commits
credentials, and a workload receives a short-lived lease through the platform