chore(consistency): renormalize lifecycle state [auto]

Updated by fix-consistency on 2026-06-29:
  - workplan status: ready → active
This commit is contained in:
2026-06-29 17:35:59 +02:00
parent 481e64c3f4
commit a07f2d3d7f

View File

@@ -0,0 +1,257 @@
---
id: RAILIANCE-WP-0009
type: workplan
title: "Issue-Core Runtime Ingestion Credential Lane"
domain: financials
repo: railiance-platform
status: active
owner: codex
topic_slug: railiance
planning_priority: high
planning_order: 9
created: "2026-06-29"
updated: "2026-06-29"
depends_on_workplans:
- RAIL-PL-WP-0002
- RAILIANCE-WP-0004
- RAILIANCE-WP-0007
- RAILIANCE-WP-0008
related_state_hub_messages:
- "f76d3a9e-a98f-4081-885d-b79d94312699"
related_ccrs:
- CCR-2026-0002
state_hub_workstream_id: "b059c81d-96f1-451f-896f-a05cd73744a1"
---
# RAILIANCE-WP-0009 - Issue-Core Runtime Ingestion Credential Lane
## Goal
Promote the draft `issue-core-ingestion-api-key` access lane from a proposed
CCR to a reviewed, least-privilege, verified OpenBao workload KV lane that
`issue-core` can consume through External Secrets and that `ops-warden` can
reference without holding secret values.
This follows the same platform pattern proven by `RAILIANCE-WP-0006`, but keeps
the issue-core lane independent so the field set, service-account binding,
verification evidence, and activation decision can be reviewed on their own.
No task in this workplan may paste, commit, log, or send secret values through
Git, State Hub, chat, prompts, shell history, or workplan text.
## Suggestion Reviewed
Ops-warden confirmed the whynot-design lane in State Hub message
`f76d3a9e-a98f-4081-885d-b79d94312699` and noted that
`issue-core-ingestion-api-key` remains draft on its side. The repo already has
the proposed non-secret CCR:
- `credential-change-requests/CCR-2026-0002-issue-core-ingestion-api-key.yaml`
## INTENT Fit
This work belongs in railiance-platform because it provides shared, secure,
operable secret custody and delivery behind stable interfaces. It does not add
issue-core application behavior. The platform-owned output is the OpenBao path,
read policy, Kubernetes auth role, External Secrets contract, verification
evidence, and ops-warden handoff.
The plan supports these `INTENT.md` principles:
- secure custody: secret values stay in OpenBao/operator custody;
- stable interfaces: issue-core consumes a documented path, fields, role, and
External Secrets target rather than internal OpenBao topology;
- operable and observable: activation requires positive and negative checks
plus non-secret audit evidence;
- independently evolvable: the credential store, auth role, and front door can
change underneath the consumer contract.
## Proposed Contract
| Item | Proposed value |
| --- | --- |
| CCR | `CCR-2026-0002` |
| ops-warden catalog id | `issue-core-ingestion-api-key` |
| Tenant/org | `issue-core` |
| Workload/project | `issue-core` |
| KV mount | `platform` |
| OpenBao CLI path | `platform/workloads/issue-core/issue-core/issue-core-runtime` |
| Secret fields | `ISSUE_CORE_API_KEY`, pending decision on `GITEA_BACKEND_TOKEN` |
| Read policy | `workload-kv-read-issue-core-runtime` |
| Policy file | `openbao/policies/workload-kv-read-issue-core-runtime.hcl` |
| Auth method | Kubernetes auth |
| Auth role | `issue-core-runtime-workload-kv-read` |
| Proposed service account | `issue-core` |
| Proposed namespace | `issue-core` |
| Delivery surface | External Secrets into the `issue-core` namespace |
| ops-warden command | `warden access issue-core-ingestion-api-key --fetch ISSUE_CORE_API_KEY` |
The `GITEA_BACKEND_TOKEN` field remains an explicit review point. Remove it
from the CCR before approval if issue-core no longer needs it in this lane.
## Tasks
## T01 - Review CCR scope and field set
```task
id: RAILIANCE-WP-0009-T01
status: todo
priority: high
state_hub_task_id: "64d85288-38fb-4374-b889-fd0d136d3bdf"
```
Review `CCR-2026-0002` with the platform operator and issue-core owner before
any live OpenBao apply.
Acceptance:
- The issue-core owner confirms whether `GITEA_BACKEND_TOKEN` belongs in this
lane or should be removed before approval.
- The approved field set is limited to runtime ingestion credentials needed by
issue-core.
- Review comments and approval state are recorded in the CCR without secret
values.
- The lane remains clearly platform-owned secret custody, not issue-core
application logic.
## T02 - Confirm Kubernetes auth and External Secrets binding
```task
id: RAILIANCE-WP-0009-T02
status: todo
priority: high
state_hub_task_id: "7f4a8317-13f0-4be3-948c-a2e2f90447cf"
```
Confirm the exact Kubernetes service account, namespace, and External Secrets
target that should consume this lane.
Acceptance:
- The service account and namespace are confirmed as `issue-core`/`issue-core`
or the CCR is updated with the approved alternative.
- The auth role binds only the approved service account and namespace.
- The External Secrets target and expected field names are documented.
- No direct human or agent read path is activated unless separately approved.
## T03 - Apply or confirm least-privilege OpenBao metadata
```task
id: RAILIANCE-WP-0009-T03
status: wait
priority: high
state_hub_task_id: "e8566cf4-bb74-4515-b434-7cbf60f9f684"
```
Apply the read policy and Kubernetes auth role only after review and binding
confirmation.
Acceptance:
- `openbao/policies/workload-kv-read-issue-core-runtime.hcl` grants only read
access to the exact KV-v2 data and metadata paths.
- The Kubernetes auth role attaches only
`workload-kv-read-issue-core-runtime`.
- Live apply uses an approved operator path or the delegated applier from
`RAILIANCE-WP-0008`; broad `platform-admin` handoffs are avoided where
possible.
- Apply evidence records only policy name, role name, actor, timestamp, and
non-secret OpenBao request ids.
## T04 - Provision values through approved custody
```task
id: RAILIANCE-WP-0009-T04
status: wait
priority: high
state_hub_task_id: "4990fe6a-ae84-4720-bc8d-e026d73a304b"
```
Have an approved operator create or confirm the OpenBao KV entry and fields.
Acceptance:
- The path exists at
`platform/workloads/issue-core/issue-core/issue-core-runtime`.
- Approved fields are present with the exact reviewed names.
- Values are entered directly through OpenBao/operator custody, never through
Git, State Hub, chat, prompts, workplans, or shell history.
- Non-secret evidence records only path, field names, actor, timestamp, and
verification result.
## T05 - Verify positive and negative access
```task
id: RAILIANCE-WP-0009-T05
status: wait
priority: high
state_hub_task_id: "65e83572-2e46-4196-8f4d-4ab35ba8d1a6"
```
Prove that the approved issue-core identity can consume the lane and that other
identities cannot.
Acceptance:
- Positive verification shows the approved issue-core service account can read
the configured fields through OpenBao or External Secrets without printing
values.
- Negative verification shows an unapproved service account cannot read the
path.
- OpenBao audit evidence exists for allowed and denied attempts, recorded only
as non-secret request ids or timestamps.
- Verification includes the External Secrets delivery path if that is the
production consumer interface.
## T06 - Activate ops-warden catalog front door
```task
id: RAILIANCE-WP-0009-T06
status: wait
priority: medium
state_hub_task_id: "0d9a02da-c032-43d5-8019-61ab4d87b40b"
```
Send ops-warden the non-secret pointers needed to promote
`issue-core-ingestion-api-key` from draft to active.
Acceptance:
- The handoff includes only catalog id, mount, path, field names, auth role,
policy name/path, External Secrets target, optional flex-auth ref, and
runbook/workplan links.
- ops-warden confirms the catalog entry has no unresolved placeholders.
- ops-warden confirms it proxies access as the caller and holds no secret
value.
- The CCR front-door readiness becomes active/resolvable only after positive
and negative verification.
## T07 - Record lifecycle operations
```task
id: RAILIANCE-WP-0009-T07
status: wait
priority: medium
state_hub_task_id: "c85d1139-1f7d-4ed4-a2fc-5ea4ecbdf0c6"
```
Document how to deactivate, rotate, and respond to compromise for this lane.
Acceptance:
- Deactivation disables the ops-warden front door and removes or detaches the
auth role policy without deleting required audit evidence.
- Rotation keeps values inside OpenBao/operator custody and records only
non-secret evidence.
- Compromise response names the immediate front-door disable, affected field
rotation, and follow-up incident workplan path.
## Exit Criteria
- `CCR-2026-0002` is reviewed, approved, applied, verified, and active.
- issue-core can consume the required runtime ingestion credential through the
approved platform interface.
- Unauthorized access is denied and recorded.
- ops-warden can resolve `issue-core-ingestion-api-key` without storing the
value.
- No secret values appear in Git, State Hub, chat, prompts, logs, or workplans.