Certificate Lifecycle Service  ·  View 21 of 21  ·  Assurance

Identity and Authorisation

Who may ask for what, and the request the platform exists to refuse.

Editable source SVG draw.io All views
Workload in ns-a Issuance API Attestation verifier Policy engine Issuing CA Issuance ledger PKI administrator 1. CSR for ns-a/payments 2. projected SA token 3. cluster · ns-a · payments 4. may this identity ask? 5. allow, profile mesh-leaf 6. sign under constraints 7. append issuance event 8. leaf + chain, 24 h 9. CSR for ns-b/treasury 10. cross-namespace subject 11. deny — not this identity's 12. append denial 13. relax a constraint 14. second approver required Identity and Authorisation — And the Request That Must Be Refused Messages 9 to 12 are the request the platform exists to refuse, and message 12 matters as much as message 11: a denial that is not recorded cannot be investigated. The administrator path shows that changing the rule is itself a two-person operation. v 1.0 · owner Security Architecture · date 2026-09

The refusal

  • Messages 9 to 12 are the whole point: a workload in one namespace asking for another namespace's identity is denied on policy, not on a name check at the CA.
  • Message 12 matters as much as message 11. A denial that is not recorded cannot be investigated, and the denial rate is a standing security signal.

Decisions

  • Identity is derived from an attested platform credential and never from a self-asserted subject in the CSR.
  • Identity is encoded in a structured SAN — trust domain, namespace, service — so that authorization policy can be written against a parseable identity rather than a string convention in a common name.
  • Changing the rule is itself a two-person operation: an administrator relaxing a constraint needs a second approver, and the change is audited immutably.

Assumption

  • Customer domain control is re-proved on a declared cadence rather than trusted indefinitely, which is the equivalent control on the public-trust side.