# NON-SECRET catalog metadata derived from railiance-platform CCR-2026-0010.
id: email-connect-transactional
kind: kv
org: coulomb
repo: email-connect
stage: prod
description: >-
  IONOS transactional SMTP identity and the shared user-engine ingest bearer for
  email-connect. user-engine must never receive the SMTP fields.

mount: platform
path: workloads/email-connect/transactional
mount_management: existing
fields:
  - EMAIL_CONNECT_INGEST_TOKEN
  - EMAIL_CONNECT_SMTP_USERNAME
  - EMAIL_CONNECT_SMTP_PASSWORD

consumers:
  - name: email-connect-runtime
    auth: token
    claim: clustersecretstore:openbao-email-connect
    purpose: sync email-connect-runtime through the namespace-limited ESO store
  - name: user-engine-ingest-caller
    auth: shared-bearer-copy
    claim: service:user-engine
    purpose: consume only EMAIL_CONNECT_INGEST_TOKEN from its separately managed runtime Secret
  - name: secrets-engine-operator-exec
    auth: approle
    claim: catalog:email-connect-transactional
    purpose: approved SMTP/ingest smoke in a child process and non-secret verification

workload_delivery:
  - mode: external-secrets
    owner: railiance-platform + email-connect

delivery_modes: [exec-env, read-check]
delivery_auth:
  method: approle
  management: engine
  policy_name: se-prod-email-connect-transactional
  role_name: se-prod-email-connect-transactional
  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-0010
  notes: >-
    CCR-2026-0010 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 each declared field without printing it
  negative: unrelated token is denied on platform/data/workloads/email-connect/transactional

risk:
  classification: high
  notes: SMTP credentials can send as the platform identity and the ingest bearer authorizes transactional requests

rotation:
  owner: railiance-platform + email-connect + user-engine
  expectation: >-
    Rotate overlap-first, wait for ESO refresh, roll email-connect and user-engine
    when the bearer changes, verify health, then revoke the old provider password/bearer.
  ttl: provider-defined

deactivation:
  owner: railiance-platform + email-connect
  expectation: >-
    Disable the front door, detach ESO/native read access, remove materialized
    Secrets, stop email-connect, and revoke the IONOS app password if applicable.

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