[EPIC](platform-mesh) OpenKCM (Key Chain Manager) integration into the Platform Mesh

[nnicora]

This document defines the requirements for integrating OpenKCM as a "Key Chain Manager" within the Platform Mesh. It encompasses the backend logic (CRDs) and the frontend delivery mechanism (Microfrontend) that allows users to manage these resources.

The integration is hierarchical:

1. Tenant Management: Enabling the provider creates a Tenant CRD.
2. Account Management (L2): Users create Account CRDs to define Roots of Trust.
3. Service Key Management (L3): Users create ServiceEncryptionKey CRDs for application keys.
4. User Experience: All operations are performed via a dedicated Microfrontend (MFE) embedded in the Platform Mesh Console.

---

1. Tenant Management (FR-100)

Goal: Establish the high-level tenancy container when OpenKCM is enabled for a workspace.

• FR-101 (Provider Activation -> Tenant Creation):

  • Trigger: When a user toggles "Enable OpenKCM (Key Chain Manager)" in the Workspace Settings.
  • System Action: The controller must automatically provision a Tenant Custom Resource (CR) in the background.
  • Naming Convention: The Tenant CR name must match the Platform Mesh Workspace ID (e.g., tenant-root-acme).
  • Idempotency: If the provider is disabled and re-enabled, the system must recover the existing Tenant CR rather than creating a duplicate or erroring.

• FR-102 (Tenant Status Reflection):

  • The UI must display a "Provider Status" indicator based on the Tenant CR status.
  • States: Provisioning (Grey), Active (Green), Suspended (Red).

---

2. L2 Key Management: The "Account" CRD (FR-200)

Goal: Manage the Root of Trust (L2) via the Account CRD.

• Mapping: Kind: Account ↔ OpenKCM L2 Key / Root of Trust

• FR-201 (Create Account):

  • The user shall be able to create an Account resource within the scope of the active Tenant.
  • Inputs:
    • Name: Unique identifier (e.g., aws-root-production).
    • ProviderType: Dropdown (AWS KMS, Azure KeyVault, GCP KMS, Thales HSM).
    • KeyReference: The external ARN, URL, or Label of the physical master key.
  • Validation: The controller must verify the external key exists and is accessible before marking the Account as Ready.

• FR-202 (Read Account):

  • The UI must list all Account resources available in the workspace.
  • Visualization: Show the "Trust Chain" visual indicating this Account wraps downstream keys.

• FR-203 (Update Account / Re-Keying):

  • The user shall be able to update the Account spec to rotate the physical Root of Trust (e.g., swapping a compromised AWS ARN for a new one).
  • Safety: The UI must require a "Type Name to Confirm" modal for this operation, as it triggers a massive re-wrapping of the internal Key Hierarchy.

• FR-204 (Delete Account):

  • The user shall be able to delete an Account.
  • Constraint: The system must block deletion if any ServiceEncryptionKey (L3) resources currently reference this Account.

L3 Key Management: The "ServiceEncryptionKey" CRD (FR-300)

Goal: Manage granular Service Keys (L3) derived from an L2 Account.

• Mapping: Kind: ServiceEncryptionKey ↔ OpenKCM L3 Key

• FR-301 (Create ServiceEncryptionKey):

  • The user shall be able to create a ServiceEncryptionKey for a specific application or microservice.
  • Binding: The user must select which parent Account (L2) protects this key.
  • Policies:
    • RotationSchedule: (e.g., "Hourly", "Daily", "30 Days").
    • Algorithm: (e.g., "AES-GCM-256").

• FR-302 (Read ServiceEncryptionKey):

  • The UI shall display the key's lifecycle state.
  • Fields: CurrentVersion (e.g., v54), NextRotation (Time), ActiveClients (Number of pods using this key).

• FR-303 (Update ServiceEncryptionKey):

  • The user shall be able to modify the RotationSchedule on the fly.
  • Effect: The Controller must update the OpenKCM Policy Engine immediately.

• FR-304 (Manual Rotation):

  • The UI shall provide a "Rotate Now" button.
  • Action: Forces an immediate version increment (vX -> vX+1) and pushes the new key to the Crypto Edge.

• FR-305 (Revocation/Disable):

  • The user shall be able to toggle a ServiceEncryptionKey to Disabled.
  • Effect: The OpenKCM Orchestrator must instantly evict this key from all Edge Caches, causing decryption attempts to fail.

4. Microfrontend (MFE) Interface (FR-400)

Goal: Deliver the management capabilities defined above via a seamless, federated plugin within the Platform Mesh Console.

• FR-401 (MFE Module Loading):

  • The Platform Mesh Console (Shell) must dynamically load the openkcm-resource-mfe remote module.
  • The MFE must inherit the Shell's Authentication Context (OIDC Token) and Visual Theme (Dark/Light mode) to appear native.

• FR-402 (Unified Dashboard View):

  • The MFE shall provide a "Key Chain Overview" dashboard tab.
  • Content: It must aggregate data from Tenant, Account, and ServiceEncryptionKey CRDs to show a high-level health summary (e.g., "3 Active Accounts", "12 Keys due for rotation").

• FR-403 (Resource Management Wizards):

  • The MFE must provide guided "Wizards" for the complex creation flows defined in FR-201 and FR-301.
  • Account Wizard: Step-by-step selection of Cloud Provider → Region → Key ARN.
  • Service Key Wizard: Selection of Parent Account → Definition of Rotation Policy.

• FR-404 (Visual Topology / Relationship View):

  • The MFE shall render a graphical representation of the relationship between Account (L2) and ServiceEncryptionKey (L3) resources.
  • Interaction: Clicking on an L2 node in the graph filters the list to show only its dependent L3 keys.