secrets-engine/catalog/email-connect-transactional.yaml
tegwick 784be978bf
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 2s
feat: admit existing OpenBao catalog lanes
2026-08-21 08:20:33 +02:00

78 lines
2.6 KiB
YAML

# 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