Objective:
Define the technical specifications for the OpenBao keystore plugin — a client connector inside OpenKCM's CMK service that integrates with an external OpenBao instance for L1 Customer Master Key operations.
Context:
Per use case 007 (Story 4), OpenKCM needs a plugin that connects to a customer's OpenBao server and uses the Transit secret engine for encrypt/decrypt operations. The L1 key never leaves OpenBao. This plugin must conform to the same standardized Plugin Interface used by the AWS KMS, Fortanix DSM, and Thales Luna plugins.
Key Areas to Investigate:
Plugin Interface Conformance
Define the common keystore plugin interface (encrypt, decrypt, key status, health check) that all 4 plugins share
Determine Go SDK/library to use for OpenBao API calls (github.com/openbao/openbao/api/v2 or similar)
Transit Secret Engine Operations
How to call transit/encrypt/{key_name} and transit/decrypt/{key_name}
Handling vault ciphertext format (vault:v1:...)
Key versioning and rotation support
Supported algorithms (AES-256-GCM as baseline)
Authentication Lifecycle
AppRole authentication: role_id + secret_id flow
Token TTL management (1h default, 4h max per Story 4)
Token renewal and re-authentication on expiry
Kubernetes Auth Method as an alternative for k8s-deployed OpenKCM
OpenBao Policy Requirements
Minimum policy: read on key path, update on encrypt/decrypt paths, read on token lookup
Verify policy from Story 4 is complete and secure
Connection & Performance
Open Questions
Do we need any server-side OpenBao plugin, or does the Transit engine cover all L1 operations out of the box?
How does key rotation in OpenBao propagate to OpenKCM's L2/L3 key derivation?
What's the credential delivery mechanism for secret_id in production (file mount, k8s secret, etc.)?
Reference Materials:
Use case: 007-OpenKCM-CMK-KeyStore-Plugins.md (Story 4)
OpenBao Transit docs: docs
OpenBao API SDK: api
Existing plugin examples: secrets (for patterns)
TenantKeyBinding integration: 012-TenantKeyBinding-Controller-Integration.md
Deliverable:
Technical specification document covering the plugin interface contract, OpenBao API integration details, authentication flow, error handling strategy, and answers to the open questions above.
Objective:
Define the technical specifications for the OpenBao keystore plugin — a client connector inside OpenKCM's CMK service that integrates with an external OpenBao instance for L1 Customer Master Key operations.
Context:
Per use case 007 (Story 4), OpenKCM needs a plugin that connects to a customer's OpenBao server and uses the Transit secret engine for encrypt/decrypt operations. The L1 key never leaves OpenBao. This plugin must conform to the same standardized Plugin Interface used by the AWS KMS, Fortanix DSM, and Thales Luna plugins.
Key Areas to Investigate:
Plugin Interface Conformance
Define the common keystore plugin interface (encrypt, decrypt, key status, health check) that all 4 plugins share
Determine Go SDK/library to use for OpenBao API calls (github.com/openbao/openbao/api/v2 or similar)
Transit Secret Engine Operations
How to call transit/encrypt/{key_name} and transit/decrypt/{key_name}
Handling vault ciphertext format (vault:v1:...)
Key versioning and rotation support
Supported algorithms (AES-256-GCM as baseline)
Authentication Lifecycle
AppRole authentication: role_id + secret_id flow
Token TTL management (1h default, 4h max per Story 4)
Token renewal and re-authentication on expiry
Kubernetes Auth Method as an alternative for k8s-deployed OpenKCM
OpenBao Policy Requirements
Minimum policy: read on key path, update on encrypt/decrypt paths, read on token lookup
Verify policy from Story 4 is complete and secure
Connection & Performance
Open Questions
Do we need any server-side OpenBao plugin, or does the Transit engine cover all L1 operations out of the box?
How does key rotation in OpenBao propagate to OpenKCM's L2/L3 key derivation?
What's the credential delivery mechanism for secret_id in production (file mount, k8s secret, etc.)?
Reference Materials:
Use case: 007-OpenKCM-CMK-KeyStore-Plugins.md (Story 4)
OpenBao Transit docs: docs
OpenBao API SDK: api
Existing plugin examples: secrets (for patterns)
TenantKeyBinding integration: 012-TenantKeyBinding-Controller-Integration.md
Deliverable:
Technical specification document covering the plugin interface contract, OpenBao API integration details, authentication flow, error handling strategy, and answers to the open questions above.