id: CCR-2026-0029 kind: credential-change-request schema_version: 1 request_type: workload-kv-read title: activity-core ops_run worker token for rein-aharness@railiance01 via the activity-core-eso store status: approved created: '2026-09-23' updated: '2026-09-23' requester: agent: activity-core message_id: e87bdefc reason: ACTIVITY-WP-0039-T02. secrets-engine (SECRETS-WP-0009-T03, SECRETS-WP-0011-T04) asked that the ops_run worker tokens move from a hand-generated value into OpenBao custody and be delivered by the existing openbao-activity-core ClusterSecretStore. review: required: true required_approvers: - platform-operator - activity-core-owner comments: - at: '2026-09-23' reviewer: claude-code decision: metadata_review_pending_owner_approval comment: Both paths already hold values (founder-attended mint 2026-09-23, ACTIVITY-WP-0039-T03). The consuming ExternalSecret activity-core/actcore-ops-run-worker-tokens (activity-core k8s/railiance/15-externalsecret-worker-tokens.yaml, not yet applied) reads field token at exactly these two paths through store openbao-activity-core. That store is on Kubernetes auth role activity-core-eso (RPF-WP-0045). The change adds two exact data-read paths to that role's policy. There is no wildcard, no metadata or list, and no new role. - at: '2026-09-23' reviewer: bernd.worsch decision: approved comment: 'Approved in chat (Claude Code session, 2026-09-23) acting as all required approvers: platform-operator, activity-core-owner.' target: domain: financials tenant: activity-core workload: activity-core-ops-run-worker-rein-aharness-railiance01 environment: production purpose: Deliver the bearer token of ops_run queue worker rein-aharness@railiance01 to the activity-core runtime Secret through External Secrets. The companion lane is CCR-2026-0030 (the other worker identity, same policy change). openbao: mount: platform kv_path: platform/workloads/activity-core/ops-run-workers/rein-aharness-railiance01 fields: - token policy_name: workload-kv-read-activity-core-eso policy_file: openbao/policies/workload-kv-read-activity-core-eso.hcl auth: method: kubernetes mount: kubernetes role: activity-core-eso bound_claims: service_account_names: - activity-core-eso service_account_namespaces: - activity-core bound_claims_confirmed: true policies: - workload-kv-read-activity-core-eso access_frontdoor: type: external-secrets catalog_id: activity-core-ops-run-worker-rein-aharness-railiance01 readiness: pending-review resolvable: false delivery: surface: external-secrets target: ExternalSecret actcore-ops-run-worker-tokens merges ACTIVITY_CORE_WORKER_TOKEN into Secret actcore-runtime-secret in namespace activity-core. risk: classification: high notes: - Each token authenticates one queue worker identity to activity-core. A leaked token lets its holder claim ops_run work as that worker. - Read is limited to the two exact paths. Other ops-run-workers paths stay unreadable. - A read-only lane for the metered worker's path is being catalogued separately by secrets-engine. It is not granted by this CCR. verification: positive: - ExternalSecret actcore-ops-run-worker-tokens reaches SecretSynced without printing values. negative: - The activity-core-eso role cannot read a sibling path under platform/data/workloads/activity-core/ops-run-workers/. - Metadata and list on ops-run-workers are denied. activation_conditions: - Policy applied with platform-admin authority through scripts/openbao-policy-sync.sh, guarded by the prior declared digest 41f4278c3f62ff879575e62ef52071feaeb794fabd05868cb3ee40608cfd4785. - Values provisioned directly in OpenBao (done, ACTIVITY-WP-0039-T03). evidence: [] lifecycle: deactivate: Remove the two path blocks from workload-kv-read-activity-core-eso and re-apply it. rotate: activity-core re-mints the worker token at its path. ESO syncs it within 1h, and the queue accepts the new token per ACTIVITY_CORE_WORKERS. compromised: Re-mint the affected worker token, force-sync the ExternalSecret, and record blast-radius notes. state_hub: workplan_id: ACTIVITY-WP-0039