Initiative: Kill Switch Dry Run (Blast Radius Simulation)

[isanmaz]

Problem Statement

Before triggering a kill switch, customers need to know exactly what would be affected — which namespaces, which services, how many data encryption keys — without actually triggering it. Today there is no way to simulate a revocation.

Business Context

Explicitly required in the OpenKCM business case: customers must be able to test the kill switch in their test environment and confirm the blast radius before relying on it in production. Without this, the kill switch is a feature customers cannot safely validate. For regulated industries, the ability to test and document the kill switch is itself a compliance requirement.

Scope

In scope:

• Read-only traversal of the key chain from a given key ID
• Report of: affected L2/L3/L4 keys, services currently connected via KMIP, estimated number of active data encryption keys
• No key state changes during dry run
• Dry run logged in audit trail as a read-only operation

Out of scope:

• UI presentation of the report (owned by CMK)
• Actual kill switch execution

Acceptance Criteria

• Dry run API accepts a key ID and level and returns a complete impact report: affected keys by level, active KMIP connections per service, total DEK count
• No key state changes occur during dry run — the operation is purely read-only
• Dry run result is recorded in the audit trail with actor identity and timestamp
• Dry run completes within 2 seconds for a typical account with up to 50 services

Success Metrics

• 100% of kill switch executions are preceded by a dry run in test environments
• Zero unintended data losses attributable to untested kill switches