# NON-SECRET catalog metadata derived from railiance-platform CCR-2026-0002.
id: issue-core-ingestion-api-key
kind: kv
org: coulomb
repo: issue-core
stage: prod
description: >-
  Runtime credentials for issue-core ingestion and its Forgejo backend. The
  existing workload path is delivered by ESO; native secrets-engine exec is a
  separate exact-path AppRole proposed for attended operator/agent use.

mount: platform
path: workloads/issue-core/issue-core/issue-core-runtime
mount_management: existing
fields:
  - ISSUE_CORE_API_KEY
  - GITEA_BACKEND_TOKEN

consumers:
  - name: issue-core-runtime
    auth: kubernetes
    claim: serviceaccount:external-secrets/external-secrets
    purpose: sync the issue-core runtime Secret through the namespace-limited ESO store
  - name: activity-core-issue-sink
    auth: kubernetes
    claim: serviceaccount:external-secrets/external-secrets
    purpose: sync the shared ingestion key for activity-core issue emission
  - name: secrets-engine-operator-exec
    auth: approle
    claim: catalog:issue-core-ingestion-api-key
    purpose: approved child-process delivery and non-secret verification only

workload_delivery:
  - mode: external-secrets
    owner: railiance-platform + issue-core + activity-core

delivery_modes: [exec-env, read-check]
delivery_auth:
  method: approle
  management: engine
  policy_name: se-prod-issue-core-ingestion-api-key
  role_name: se-prod-issue-core-ingestion-api-key
  token_ttl: 15m
  token_max_ttl: 30m
  secret_id_ttl: 15m
  secret_id_num_uses: 1
  token_num_uses: 8

approval:
  model: ccr
  decision_ref: CCR-2026-0002
  notes: >-
    CCR-2026-0002 approves the existing workload lane. A live native AppRole
    apply remains gated by SECRETS-WP-0006-T05 review and operator approval.

verification:
  positive: approved delivery AppRole can read both declared fields without printing them
  negative: unrelated token is denied on platform/data/workloads/issue-core/issue-core/issue-core-runtime

risk:
  classification: high
  notes: path includes the shared ingestion bearer and the issue-core Forgejo backend token

rotation:
  owner: railiance-platform + issue-core + activity-core
  expectation: >-
    Update OpenBao first, wait for both ESO consumers, roll issue-core and the
    activity-core workers, then revoke the replaced provider credential.
  ttl: provider-defined

deactivation:
  owner: railiance-platform + issue-core
  expectation: >-
    Disable the front door, detach read access, remove materialized workload
    Secrets, restart consumers, and preserve non-secret audit evidence.

audit:
  evidence: CCR id, actor, exact path, field names, audit request ids, timestamps, and pass/fail only