PMCMK Use Cases — Product Discussion

[isanmaz]

Purpose

Define the customer use cases for Platform Mesh CMK (PMCMK). These use cases will drive the product requirements, UI decisions, and CRD design for the OpenKCM microfrontend on Platform Mesh.

This issue is a discussion placeholder — not an implementation ticket.

---

What Needs to Be Defined

1. L1 Key Management

• Can a customer have multiple L1 keys per account?
• How does a customer bind an L1 key to a specific namespace?
• What happens to a namespace that has no L1 bound — does it use a platform-managed key?
• Can a customer upgrade from platform-managed to customer-managed L1 at any time?

2. Namespace ↔ L1 Binding

• Is the binding 1:1 (one L1 per namespace) or can multiple namespaces share one L1?
• Who initiates the binding — the customer explicitly, or is it automatic?
• What does the customer see when a namespace has no L1 bound yet?

3. Kill Switch Scope

• Kill switch at L1 level — locks entire account. Confirmed.
• Kill switch at L2 level — locks one namespace. Is this a customer use case?
• Kill switch at L3 level — locks one workload. Is this a customer use case?
• Who can trigger each level — account admin only, or namespace admin too?

4. Key Visibility

• Does the customer need to see L2 and L3 keys, or just workload encryption status?
• Is L2/L3 visibility a compliance/audit requirement or just noise?

5. Platform-Managed vs Customer-Managed

• When is platform-managed L1 acceptable to a customer?
• What is the upgrade path from platform-managed to BYOK?
• Can a customer downgrade back to platform-managed — and what are the implications?

---

Context

• L2 Domain Key is always auto-provisioned by the platform when a namespace is created
• Krypton detects the L1 binding and wraps L2 under L1 automatically
• L3 Service Key is auto-provisioned by Krypton when a workload is deployed
• The customer only actively manages L1 — everything below is automatic

---

Goal

Come out of the discussion with clear answers to the questions above, so that:

• The microfrontend team knows exactly what screens to build
• The CRD design reflects real customer use cases
• The Platform Mesh requirements doc can be finalized