flex-auth/docs/evidence/security-zone-admission-2026-08-22.md
tegwick e521e7b715
All checks were successful
CI Smoke / host-smoke (push) Successful in 0s
CI Smoke / container-smoke (push) Successful in 1s
Build and Publish Container Image / build-and-push (push) Successful in 33s
feat(policy): adopt security zone stances
Assistant: codex
Assistant-Model: gpt-5.6-sol
Assistant-Session: 01a0291a-1e87-7151-9934-fcbfe3f65eb1
2026-08-22 15:17:13 +02:00

19 lines
1,001 B
Markdown

# flex-auth security-zone admission — 2026-08-22
The `flex-auth` workload qualifies for `z1-operational` and does not claim a
higher zone.
- Scope is limited to three separately configured platform consumers. Each pin
has an explicit policy, registry, and authenticated caller binding.
- The basic service objective is 95% successful `/healthz` and policy checks
during each consumer's operating window. Decision ids and the existing
ops-warden registry-sync runbook provide the measurement path. No SLO history
is claimed; that is one reason M2 is not admitted.
- Requests contain internal identity, authorization, and resource metadata.
The service stores no tenant data or secret values and production policy and
registry inputs are read-only.
- The zone-aware ops-warden package is total across every v0.1 zone plus
`unknown`; flex-auth owns stance while the calling PEP owns failure behavior.
Owner: `team:platform-security`. Re-review with the zone declaration by
2026-11-22.