113 lines
5.7 KiB
Markdown
113 lines
5.7 KiB
Markdown
---
|
|
id: rapp-qonto-openbao-kubernetes-lane
|
|
demand_source: reef-railiance/workplans/REEF-RAILIANCE-WP-0003-T01
|
|
consumer_repo: rapp-qonto
|
|
credential_type: openbao-kubernetes-kv
|
|
status: reviewed
|
|
approved_by: null
|
|
approved_at: null
|
|
created: "2026-07-27"
|
|
updated: "2026-07-27"
|
|
---
|
|
|
|
# Construction plan: rapp-qonto OpenBao Kubernetes lane
|
|
|
|
## 1. Demand
|
|
|
|
`rapp-qonto` needs non-interactive, read-only delivery of the existing Binky
|
|
Qonto API credential from `tenants/binky/qonto-api` into its dedicated
|
|
Kubernetes namespace. External Secrets Operator should authenticate to OpenBao
|
|
with Kubernetes workload identity; neither the application nor a
|
|
ClusterSecretStore should hold a long-lived OpenBao token.
|
|
|
|
## 2. Existing-structure survey
|
|
|
|
Live OpenBao state was checked on 2026-07-27:
|
|
|
|
- auth mounts include `kubernetes/`; its configured API endpoint is the
|
|
cluster-local `https://10.43.0.1:443`;
|
|
- existing Kubernetes roles are `external-secrets-activity-core`,
|
|
`external-secrets-issue-core`, and `external-secrets-reuse-surface`;
|
|
- policy `workload-kv-read-binky-qonto-api` already exists and is scoped to
|
|
the existing tenant credential;
|
|
- the `tenants/` KV v2 mount and `tenants/binky/qonto-api` value already
|
|
exist; this plan does not create or read the value;
|
|
- existing cluster stores use an interim static-token pattern, despite the
|
|
Kubernetes roles existing;
|
|
- `CCR-2026-0009` proposed a duplicate
|
|
`workload-kv-read-qonto-assistant` policy and the transitional
|
|
`qonto-assistant` namespace/name.
|
|
|
|
The existing read policy satisfies the requested data scope exactly. Reuse it;
|
|
do not create the duplicate policy from CCR-2026-0009. A new authentication
|
|
role is still required because no existing role should gain Qonto access and
|
|
no existing Qonto lane is workload-authenticated.
|
|
|
|
## 3. Proposed changes
|
|
|
|
| # | Action | Object | Reuse-vs-new rationale |
|
|
|---|---|---|---|
|
|
| 1 | reuse | policy `workload-kv-read-binky-qonto-api` | Already grants the exact required read scope; a second equivalent policy adds drift without isolation |
|
|
| 2 | create | Kubernetes auth role `external-secrets-rapp-qonto` | New identity binding only; bound to service account `external-secrets` in namespace `external-secrets`, policy #1, token TTL 15 minutes |
|
|
| 3 | create | `ClusterSecretStore/openbao-rapp-qonto` | Uses Vault Kubernetes auth role #2 and the `tenants` KV v2 mount; namespace condition permits only `rapp-qonto` |
|
|
| 4 | modify | `rapp-qonto` ExternalSecret | Map remote fields `API_USER` -> `QONTO_LOGIN` and `API_KEY` -> `QONTO_SECRET_KEY`; no values enter Git or logs |
|
|
| 5 | retire | proposed `openbao-qonto-assistant` static-token store | Superseded before deployment; avoids a long-lived OpenBao token in a Kubernetes Secret |
|
|
| 6 | propose | ops-warden catalog entry `rapp-qonto-workload-kv` | Pointer to the built Kubernetes-auth lane, `warden_executes: false`, initially `draft` |
|
|
|
|
No underlying Qonto secret is created, changed, printed, or rotated.
|
|
|
|
## 4. Review notes
|
|
|
|
- **Naming:** steady-state `rapp-qonto` names replace the migration-only
|
|
`qonto-assistant` names.
|
|
- **TTL/scoping:** 15-minute tokens match existing External Secrets roles.
|
|
The role binds only the ESO service account; the ClusterSecretStore
|
|
condition restricts consumers to one namespace.
|
|
- **Redundancy:** reuses the exact existing policy. This removes the duplicate
|
|
policy proposed by CCR-2026-0009.
|
|
- **Compaction:** the draft static-token Qonto store is retired before it is
|
|
deployed. Existing unrelated stores are untouched.
|
|
- **Consumer usability:** External Secrets performs authentication and
|
|
delivery. The application consumes only a namespaced Kubernetes Secret.
|
|
- **Posture:** the lane accesses a high-risk bank credential, but it is
|
|
read-only and the runtime exposes no financial write operation. Production
|
|
still requires egress, audit, revocation, and failure-domain gates.
|
|
- **Build executor extension:** ops-mason currently builds AppRole lanes only.
|
|
Phase 4 must add a narrowly tested Kubernetes-role operation with the same
|
|
approval refusal and metadata-only audit guarantees before applying this
|
|
plan.
|
|
|
|
## 5. Executive summary
|
|
|
|
**One-line ask:** allow External Secrets on railiance01 to deliver the existing
|
|
Binky Qonto read credential to `rapp-qonto` without storing a long-lived
|
|
OpenBao token in Kubernetes.
|
|
|
|
**Who/what gets access:** a new OpenBao Kubernetes role named
|
|
`external-secrets-rapp-qonto`, usable only by the existing
|
|
`external-secrets` service account in the `external-secrets` namespace. No
|
|
application pod, human role, or unrelated service account receives OpenBao
|
|
login rights.
|
|
|
|
**To what:** read-only access through the existing
|
|
`workload-kv-read-binky-qonto-api` policy to exactly
|
|
`tenants/binky/qonto-api`. Store use is limited to ExternalSecret resources in
|
|
the `rapp-qonto` namespace.
|
|
|
|
**For how long:** each Kubernetes-auth login receives a 15-minute OpenBao
|
|
token. There is no delivered AppRole secret ID and no long-lived OpenBao token
|
|
stored in Kubernetes. The Kubernetes service-account identity remains valid
|
|
while the ESO deployment and role binding exist.
|
|
|
|
**Blast radius if the identity is abused:** an attacker able to act as the ESO
|
|
service account and use this role could read the Binky Qonto API credential.
|
|
The OpenBao policy cannot read any sibling tenant secret. The downstream Qonto
|
|
key remains high-risk and must be rotated if exposed.
|
|
|
|
**Cost to reverse:** delete one Kubernetes auth role, one ClusterSecretStore,
|
|
and the `rapp-qonto` ExternalSecret/derived Secret. The existing human Qonto
|
|
lane and underlying credential remain intact; no unrelated consumer changes.
|
|
|
|
**Decision needed:** approve as proposed, reject, or send back to phase 1 with
|
|
changes. Approval authorizes the structural access lane only, never disclosure
|
|
or modification of the Qonto credential value.
|