Answers KEY-WP-0013-T02. Both proposed KV paths are confirmed unchanged; the
field name is corrected to CLIENT_SECRET for the platform uppercase convention
and the CCR validator. Kubernetes delivery references are confirmed against the
live sso namespace. Attended authority is the governed openbao-platform-admin-login
lane, and the rollout is one attended window ordered after the Authelia issuer
precondition.
Adds CCR-2026-0017/0018, two exact-path read policies, two namespace-limited
ClusterSecretStores with Kubernetes auth, two ExternalSecrets, and RPF-WP-0035-T05.
Nothing is applied and no value exists: both CCRs remain proposed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WLUjpv3ssxNRAEPPgLFnEB
Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 1275505@bnt-lap001
Assistant-Session: 97265baa-f08f-4032-b290-a1e2965a69c5
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.
KV store for the sender registry only. Database leases stay on the
OpenBao database engine and are consumed via VaultDynamicSecret in
audit-core. Not added to the coulombcore ArgoCD kustomization.
WP-0011: sync coulomb/target-revenue path k8s/railiance into namespace
target-revenue (revenue.coulomb.social). Requires image, OpenBao secrets,
and DNS before a healthy sync — see target-revenue docs/deployment.md.
QONTO-WP-0004-T06. Requests a second, workload-scoped access lane into
the existing tenants/binky/qonto-api credential (CCR-2026-0008 is
human/OIDC admin access only, not usable by a running pod). Mirrors
CCR-2026-0003's llm-connect pattern: External Secrets Operator reads
the KV path into a namespace-scoped Kubernetes Secret via a
ClusterSecretStore restricted to the new qonto-assistant namespace;
the pod never touches the OpenBao token directly.
Status: proposed, not approved -- requires platform-operator and
binky-tenant-owner sign-off before the auth role/policy are applied.
Draft ClusterSecretStore manifest included, following the same
"deployed separately, not via this kustomization" pattern as the
existing activity-core/forgejo/reuse stores. Validated against
schemas/credential-change-request.schema.yaml.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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.
ArgoCD was still tracking gitea.coulomb.social, which lags Forgejo after the
registry migration. Sync issue-core workload manifests from forgejo.coulomb.social
so backend ConfigMap updates land on CoulombCore.
Also allow forgejo.coulomb.social in railiance-tenants AppProject sourceRepos.
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.
Introduce external-secrets-forgejo policy/role, ClusterSecretStore
openbao-forgejo (forgejo namespace), and make openbao-configure-external-secrets-forgejo.
Define platform-owned AppProjects, root app-of-apps, repository registration
templates, and tenant onboarding docs so issue-core can deploy via ArgoCD.
Ignore encrypted repository secrets locally and cross-link OpenBao delivery
guidance with the new GitOps contract.
