Overview
This issue captures the user journey for managing a key on the OpenKCM UI (Platform Mesh microfrontend). It serves as input for the showroom demo scope and as a gap analysis baseline.
Current State
✅ Fixed: OpenKCM is now accessible at the account level:
Home / Accounts / isun / OpenKCM
The Platform Mesh team has moved OpenKCM from namespace level to account level. The navigation gap is resolved.
Current navigation path (correct):
Home → Accounts → isun → OpenKCM
User Journeys — OpenKCM on Platform Mesh
Journey 1 — Enable OpenKCM and Register a Root Key
Step 1 — Enable OpenKCM at account level
The security admin navigates to their account and enables OpenKCM. OpenKCM appears in the account-level navigation. The admin lands on the OpenKCM dashboard.
Step 2 — View provisioned L2 Domain Keys
The admin sees the OpenKCM dashboard. Platform Mesh has already provisioned one L2 Domain Key per namespace — these are visible on the dashboard in read-only state. No action needed from the admin to create them.
Step 3 — Register an L1 Root Key
The admin clicks "Register Root Key" and provides:
- Provider (OpenBao, AWS KMS, Azure Key Vault, etc.)
- Name and connection details
- Key reference (no key material is uploaded — HYOK)
On submit, OpenKCM registers the L1 key reference and Krypton validates that the key is reachable.
Step 4 — Bind L1 to L2
The admin binds the registered L1 key to one or more of the L2 Domain Keys provisioned by Platform Mesh. Each namespace can be bound to a different L1 key. Once bound, all workloads in that namespace are encrypted under the L1→L2 key chain.
Journey 2 — View the Full Key Chain
Step 1 — Open OpenKCM dashboard
The security admin navigates to the account-level OpenKCM section.
Step 2 — See key hierarchy
The dashboard shows the full key chain per namespace:
- L1 Root Key — registered by the admin, backed by external keystore
- L2 Domain Key — provisioned by Platform Mesh (read-only)
- L3 Service Keys — generated by Krypton per deployed service (read-only)
The admin can verify that each service in each namespace is encrypted and which L1 key governs it.
Journey 3 — Trigger the Kill Switch
Step 1 — Navigate to the L1 Root Key
The admin opens the L1 key detail view from the OpenKCM dashboard.
Step 2 — Trigger revocation
The admin clicks the kill switch (Red Button). A full-page confirmation is shown — the admin must confirm the action explicitly.
Step 3 — Approval (if multi-party approval is enabled)
The revocation request is submitted for a second approver. The kill switch does not execute until approved.
Step 4 — Revocation cascades
Once approved, the L1 key is revoked. All L2, L3, and L4 keys derived from it are invalidated. All workloads in all namespaces bound to this L1 key become inaccessible within the propagation window.
Journey 4 — Register a Second L1 Key and Bind to a Different Namespace
Step 1 — Register a second L1 key
The admin registers a second L1 key backed by a different external keystore (e.g. a second OpenBao instance or AWS KMS).
Step 2 — Bind to a specific namespace
The admin binds the second L1 key to a specific namespace L2 Domain Key. That namespace is now governed by a different root key than the others.
Step 3 — Selective revocation
If the admin revokes the second L1 key, only the namespaces bound to it are affected. Namespaces bound to the first L1 key remain accessible.
Architecture Gap Summary
| Issue |
Current |
Required |
| CMK navigation level |
✅ Account level (/Accounts/isun/OpenKCM) |
— |
| L2 Domain Key scope |
🔲 To confirm — namespace or workspace level |
Per workspace |
| Key binding UI |
🔲 Not yet present |
Admin binds L1 → L2 per namespace |
| Kill switch UI |
🔲 Not yet implemented |
Required |
| Audit trail |
🔲 Not visible |
Required |
| L3 selective revocation |
🔲 Unowned |
Needs decision: CMK or Krypton |
| Approval workflow |
🔲 Not visible |
Required for multi-party governance |
Open Questions
- L2 scope: Has L2 Domain Key scope been moved from namespace to workspace level?
- L3 visibility: Should L3 Service Keys be visible on the dashboard (read-only) or fully internal?
- Selective revocation: Who owns L3-level kill switch — OpenKCM or Krypton?
- Multi-party approval: Does Platform Mesh provide a native four-eyes mechanism OpenKCM can integrate with?
Overview
This issue captures the user journey for managing a key on the OpenKCM UI (Platform Mesh microfrontend). It serves as input for the showroom demo scope and as a gap analysis baseline.
Current State
✅ Fixed: OpenKCM is now accessible at the account level:
The Platform Mesh team has moved OpenKCM from namespace level to account level. The navigation gap is resolved.
Current navigation path (correct):
User Journeys — OpenKCM on Platform Mesh
Journey 1 — Enable OpenKCM and Register a Root Key
Step 1 — Enable OpenKCM at account level
The security admin navigates to their account and enables OpenKCM. OpenKCM appears in the account-level navigation. The admin lands on the OpenKCM dashboard.
Step 2 — View provisioned L2 Domain Keys
The admin sees the OpenKCM dashboard. Platform Mesh has already provisioned one L2 Domain Key per namespace — these are visible on the dashboard in read-only state. No action needed from the admin to create them.
Step 3 — Register an L1 Root Key
The admin clicks "Register Root Key" and provides:
On submit, OpenKCM registers the L1 key reference and Krypton validates that the key is reachable.
Step 4 — Bind L1 to L2
The admin binds the registered L1 key to one or more of the L2 Domain Keys provisioned by Platform Mesh. Each namespace can be bound to a different L1 key. Once bound, all workloads in that namespace are encrypted under the L1→L2 key chain.
Journey 2 — View the Full Key Chain
Step 1 — Open OpenKCM dashboard
The security admin navigates to the account-level OpenKCM section.
Step 2 — See key hierarchy
The dashboard shows the full key chain per namespace:
The admin can verify that each service in each namespace is encrypted and which L1 key governs it.
Journey 3 — Trigger the Kill Switch
Step 1 — Navigate to the L1 Root Key
The admin opens the L1 key detail view from the OpenKCM dashboard.
Step 2 — Trigger revocation
The admin clicks the kill switch (Red Button). A full-page confirmation is shown — the admin must confirm the action explicitly.
Step 3 — Approval (if multi-party approval is enabled)
The revocation request is submitted for a second approver. The kill switch does not execute until approved.
Step 4 — Revocation cascades
Once approved, the L1 key is revoked. All L2, L3, and L4 keys derived from it are invalidated. All workloads in all namespaces bound to this L1 key become inaccessible within the propagation window.
Journey 4 — Register a Second L1 Key and Bind to a Different Namespace
Step 1 — Register a second L1 key
The admin registers a second L1 key backed by a different external keystore (e.g. a second OpenBao instance or AWS KMS).
Step 2 — Bind to a specific namespace
The admin binds the second L1 key to a specific namespace L2 Domain Key. That namespace is now governed by a different root key than the others.
Step 3 — Selective revocation
If the admin revokes the second L1 key, only the namespaces bound to it are affected. Namespaces bound to the first L1 key remain accessible.
Architecture Gap Summary
/Accounts/isun/OpenKCM)Open Questions