CAMEL-22538: Camel-PQC - Add Azure Key Vault Lifecycle Manager#24953
Conversation
Add AzureKeyVaultKeyLifecycleManager storing PQC keys in Azure Key Vault as
secrets (Key Vault key objects do not support post-quantum key material).
Private key (PKCS#8), public key (X.509) and metadata (JSON via
KeyMetadataCodec, no Java serialization) are stored as three distinct
secrets so different access policies can apply. Azure secret names only
allow alphanumerics and dashes, so secrets are named
{keyPrefix}-{keyId}-{type} with validation of key ids and prefix.
Constructors support an injected SecretClient, client secret credentials,
and the Default Azure Credential chain.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
gnodet
left a comment
There was a problem hiding this comment.
Well-structured Azure Key Vault implementation — consistent with the AWS Secrets Manager backend and a natural addition to the PQC key lifecycle manager lineup.
What works well:
- Clean separation of private key, public key, and metadata into distinct Key Vault secrets, enabling fine-grained Azure RBAC / access policies.
- Industry-standard key formats (PKCS#8 / X.509) with Base64 JSON envelopes — consistent with the AWS implementation.
- Input validation via
validateNameenforces Azure Key Vault naming constraints upfront (fail-fast over silent mangling). - Three constructor options (injected
SecretClient, client-secret credential, Default Azure Credential) cover the common deployment scenarios. - JSON metadata via
KeyMetadataCodec— no Java serialization, consistent with CAMEL-23726 hardening. - Good test coverage: 9 tests against a mocked
SecretClientcovering the full lifecycle (generate, round-trip through a fresh manager, list, delete, rotate/deprecate, expire, revoke, missing key, invalid name). - Thorough documentation with security notes, naming conventions, soft-delete behavior, three usage examples, and updated comparison table.
- Azure SDK deps properly marked
<optional>true</optional>.
Minor observations (non-blocking):
updateKeyMetadatacallsgetKey()+storeKey(), re-writing all three secrets when only metadata changed. Not incorrect — it's consistent with the AWS pattern — but could be optimized to update only the metadata secret if vault write costs matter.metadata.setDescription("Generated on " + new Date())uses locale-dependentDate.toString()— considerInstant.now().toString()for ISO-8601 consistency, but this matches the existing implementations.
LGTM ✅
Claude Code on behalf of gnodet — AI-generated review
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 9 tested, 29 compile-only — current: 9 all testedMaveniverse Scalpel detected 38 affected modules (current approach: 9).
|
…tern
AsciiDoc read {keyPrefix}/{keyId} as attribute references, which the strict
documentation-validation build rejects. Escape them so the naming pattern
renders literally.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Signed-off-by: Andrea Cosentino <ancosen@gmail.com>
Motivation
CAMEL-22538 (sub-task of CAMEL-22512): camel-pqc has key lifecycle managers for in-memory, file, HashiCorp Vault and AWS Secrets Manager backends — this adds the missing Azure Key Vault implementation.
Changes
AzureKeyVaultKeyLifecycleManager, mirroring the AWS Secrets Manager implementation: private key (PKCS#8), public key (X.509/SubjectPublicKeyInfo) and metadata are stored as three distinct Key Vault secrets, enabling different access policies / Azure RBAC for private vs public material. PQC keys are stored as Key Vault secrets because Key Vault key objects do not support post-quantum key material.KeyMetadataCodec— no Java serialization anywhere (consistent with the CAMEL-23726 hardening; no legacy-deserialization path since this is a new store).[0-9a-zA-Z-], so secrets are named{keyPrefix}-{keyId}-{type}(default prefixpqc-keys), with explicit validation of key ids/prefix (fail fast instead of silent mangling).KeyAlgorithmSupport/KeyFormatConverterinstead of duplicating them.SecretClient(recommended), client-secret credential, and Default Azure Credential chain (managed identity).azure-sdk-bomimport +azure-security-keyvault-secrets/azure-identityas optional deps (same pattern as the optional AWS/spring-vault deps);mockito-core(test).pqc-key-lifecycle.adoc(security notes, naming, soft-delete behavior, three usage examples) + updated comparison table and component-page mention.Testing
SecretClientsimulating the vault store (store/round-trip through a fresh manager instance, listing, deletion, rotation/deprecation, expire/revoke, missing-key handling, invalid-name rejection) — all pass. Note: the AWS/Hashicorp managers currently have no unit tests, so this also raises the bar slightly.mvn clean installincomponents/camel-pqc: BUILD SUCCESS.mvn clean install -DskipTestsfrom root: success, no stale generated files.No backport: new feature, main/4.22.0 only.
Claude Code on behalf of Andrea Cosentino (@oscerd).
🤖 Generated with Claude Code