Skip to content

feat: add openbao:// KMS URI support (SECURESIGN-5076) - #2186

Merged
bouskaJ merged 1 commit into
mainfrom
feat/openbao-kms-uri
Aug 13, 2026
Merged

feat: add openbao:// KMS URI support (SECURESIGN-5076)#2186
bouskaJ merged 1 commit into
mainfrom
feat/openbao-kms-uri

Conversation

@kdacosta0

@kdacosta0 kdacosta0 commented Aug 6, 2026

Copy link
Copy Markdown
Member

What changed

  • Add openbao:// as a valid KMS URI scheme for Rekor and TSA signer configuration
  • Move shared KMS struct from timestampauthority_types.go to common.go — it is used by both TSA and Fulcio

Why

SECURESIGN-5076 — OpenBao (open-source Vault fork) is already supported by sigstore/sigstore as an alternative scheme for the hashivault KMS provider. The operator's CEL validation was rejecting valid openbao:// URIs.

KMS struct lived in TSA types despite being shared across components — moved to common.go alongside Auth, SecretKeySelector, and other shared types for discoverability.

Note

PR #2184 (Fulcio KMS signer) uses the KMS struct — after this merges, #2184 needs a trivial rebase to pick up the new location in common.go. Same package, no import changes.

@qodo-for-securesign

Copy link
Copy Markdown

PR Summary by Qodo

Add openbao:// KMS URI support and centralize shared KMS type

✨ Enhancement 🐞 Bug fix ⚙️ Configuration changes 🕐 20-40 Minutes

Grey Divider

AI Description

• Allow openbao:// KMS URIs in Rekor signer CEL validation.
• Extend TSA/Fulcio KMS keyResource validation to accept openbao://.
• Move the shared KMS config type into api/v1/common.go for reuse.
Diagram

graph TD
  Types["api/v1 API types"] --> Gen["controller-gen"] --> CRD["CRD schema (YAML)"]
  Admin["Cluster admin"] --> CR["Rekor/TSA CR"] --> API["K8s API server"] --> CRD --> CEL{"Validate KMS URI"} --> Result["Accept openbao://"]
Loading
High-Level Assessment

The following are alternative approaches to this PR:

1. Loosen validation to accept any '://...' URI
  • ➕ Avoids future churn when new KMS schemes are added upstream (no CRD change needed).
  • ➕ Reduces risk of drift between runtime-supported schemes and CRD allowlists.
  • ➖ Worse early feedback: invalid/unsupported schemes fail later at runtime.
  • ➖ Potentially allows unexpected schemes that operators didn’t intend to permit.
2. Generate/centralize scheme allowlist to prevent drift
  • ➕ Single source of truth for allowed KMS schemes across Rekor/TSA/Fulcio fields and CRDs.
  • ➕ Reduces the chance of one field’s CEL rule diverging from another.
  • ➖ Kubebuilder marker strings are not easily parameterized; may require templating/codegen changes.
  • ➖ Adds build/pipeline complexity for a small validation list.

Recommendation: The current explicit allowlist approach is appropriate for strong, early UX and predictable operator behavior, and adding openbao:// closes a real validation gap. If future scheme churn is expected, consider a follow-up to reduce drift risk (e.g., documentation/tests that assert the scheme lists across fields/CRDs stay aligned), since marker strings can otherwise diverge over time.

Files changed (6) +19 / -21

Enhancement (1) +9 / -0
common.goAdd shared KMS config type with openbao:// allowlist +9/-0

Add shared KMS config type with openbao:// allowlist

• Introduces a shared 'KMS' struct in common types for reuse by TSA and Fulcio signer backends. Adds a kubebuilder CEL validation rule that allowlists 'gcpkms://', 'azurekms://', 'hashivault://', 'openbao://', and 'awskms://' URIs for 'keyResource'.

api/v1/common.go

Bug fix (1) +2 / -1
rekor_types.goPermit openbao:// in RekorSigner KMS URI validation +2/-1

Permit openbao:// in RekorSigner KMS URI validation

• Updates the Rekor signer KMS field documentation and CEL validation to accept 'openbao://' URIs in addition to existing schemes. This prevents valid OpenBao-backed KMS references from being rejected at admission time.

api/v1/rekor_types.go

Refactor (1) +0 / -8
timestampauthority_types.goRemove TSA-local KMS type in favor of common shared type +0/-8

Remove TSA-local KMS type in favor of common shared type

• Deletes the TSA-specific 'KMS' struct definition now that the shared 'KMS' type lives in 'common.go'. This avoids duplicate definitions for the same concept across API packages.

api/v1/timestampauthority_types.go

Other (3) +8 / -12
rhtas.redhat.com_rekors.yamlRegenerate Rekor CRD to allow openbao:// KMS URIs +2/-1

Regenerate Rekor CRD to allow openbao:// KMS URIs

• Updates the generated Rekor CRD schema to document and validate 'openbao://' as an accepted scheme for the Rekor signer KMS field. Extends the CEL rule accordingly.

config/crd/bases/rhtas.redhat.com_rekors.yaml

rhtas.redhat.com_securesigns.yamlRegenerate SecureSign CRD for openbao:// and shared KMS validation +4/-6

Regenerate SecureSign CRD for openbao:// and shared KMS validation

• Updates generated SecureSign CRD validations to accept 'openbao://' for Rekor signer KMS and for TSA KMS 'keyResource'. Also reflects the shared KMS validation message/regex change in the TSA section.

config/crd/bases/rhtas.redhat.com_securesigns.yaml

rhtas.redhat.com_timestampauthorities.yamlRegenerate TimestampAuthority CRD to allow openbao:// keyResource +2/-5

Regenerate TimestampAuthority CRD to allow openbao:// keyResource

• Updates the generated TimestampAuthority CRD schema so the KMS 'keyResource' CEL validation allowlists 'openbao://' in addition to existing schemes. Keeps the schema aligned with the shared 'KMS' type validation.

config/crd/bases/rhtas.redhat.com_timestampauthorities.yaml

@codecov-commenter

codecov-commenter commented Aug 6, 2026

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 69.09091% with 17 lines in your changes missing coverage. Please review.
✅ Project coverage is 57.60%. Comparing base (f0104b9) to head (a44c399).

Files with missing lines Patch % Lines
...rnal/controller/rekor/actions/server/deployment.go 18.18% 9 Missing ⚠️
api/v1alpha1/zz_generated.conversion.go 0.00% 6 Missing and 2 partials ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2186      +/-   ##
==========================================
- Coverage   57.61%   57.60%   -0.01%     
==========================================
  Files         288      288              
  Lines       16011    16044      +33     
==========================================
+ Hits         9224     9242      +18     
- Misses       5831     5847      +16     
+ Partials      956      955       -1     
Flag Coverage Δ
e2e 67.78% <21.42%> (-0.07%) ⬇️
unit 37.09% <69.09%> (+<0.01%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

@qodo-for-securesign

qodo-for-securesign Bot commented Aug 6, 2026

Copy link
Copy Markdown

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

Grey Divider


Action required

1. v1alpha1 rejects openbao URIs ✓ Resolved 🐞 Bug ≡ Correctness
Description
The PR adds openbao:// support to the v1 Rekor signer KMS allow-list, but the still-served v1alpha1
Rekor/Securesign schemas and v1alpha1 Rekor type validation still omit openbao://, so v1alpha1
resources will continue to fail admission when configured with openbao://.
Code

api/v1/rekor_types.go[R112-113]

+	//   - openbao://keyname
+	// +kubebuilder:validation:XValidation:rule="self == 'secret' || self == 'memory' || self.matches('^awskms://.+$') || self.matches('^gcpkms://.+$') || self.matches('^azurekms://.+$') || self.matches('^hashivault://.+$') || self.matches('^openbao://.+$')",message="KMS must be 'secret', 'memory', or a valid URI with a key path (e.g., awskms:///key-id)"
Relevance

●●● Strong

Team has accepted keeping served versions/CRDs aligned with API validation; likely to update
v1alpha1 too.

PR-#1260
PR-#1089

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
Although v1 Rekor’s validation now includes openbao://, the v1alpha1 RekorSigner validation rule and
the v1alpha1 CRD schemas for both Rekor and Securesign still only allow up to hashivault://. Since
the Rekor CRD explicitly serves v1alpha1, applying v1alpha1 resources with openbao:// will still be
rejected.

api/v1alpha1/rekor_types.go[109-123]
config/crd/bases/rhtas.redhat.com_rekors.yaml[2989-2996]
config/crd/bases/rhtas.redhat.com_rekors.yaml[5572-5592]
config/crd/bases/rhtas.redhat.com_securesigns.yaml[16428-16448]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`openbao://` is now accepted for v1 Rekor signer KMS, but v1alpha1 (still served) continues to reject `openbao://` because its kubebuilder XValidation and generated CRD schemas only allow up to `hashivault://`.

## Issue Context
This creates inconsistent behavior across served API versions: v1 accepts `openbao://` while v1alpha1 rejects it (including Securesign v1alpha1, which embeds RekorSpec).

## Fix Focus Areas
- Update the v1alpha1 RekorSigner KMS XValidation allow-list and docs:
 - api/v1alpha1/rekor_types.go[109-123]
- Update/extend v1alpha1 API validation tests to cover `openbao://`:
 - api/v1alpha1/rekor_types_test.go[351-401]
- Regenerate CRDs (or update generated bases if they are committed) so v1alpha1 schemas include `openbao://` in both Rekor and Securesign CRDs:
 - config/crd/bases/rhtas.redhat.com_rekors.yaml[5572-5592]
 - config/crd/bases/rhtas.redhat.com_securesigns.yaml[16428-16448]
- Ensure v1alpha1 remains consistent with v1 for supported KMS URI schemes (or, if intentionally not supported, consider marking v1alpha1 as not served).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Informational

2. Fulcio KMS comment incorrect ✓ Resolved 🐞 Bug ⚙ Maintainability
Description
The new shared KMS type comment says it is used by Fulcio signer backends, but the v1 Fulcio API
only defines a file-based signer, so this comment is misleading for maintainers.
Code

api/v1/common.go[R235-238]

+// KMS configures a remote key management service for signing operations.
+// Used by TSA and Fulcio signer backends.
+// XValidation is also present on RekorSigner.KMS (string field) in rekor_types.go.
+// +kubebuilder:validation:XValidation:rule="self.keyResource.matches('^(gcpkms|azurekms|hashivault|openbao|awskms)://.+$')",message="keyResource must be a valid KMS URI (gcpkms://, azurekms://, hashivault://, openbao://, or awskms://)"
Relevance

●●● Strong

Misleading/incorrect comment is a low-risk maintainability fix; teams usually accept clarifying
docs.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence
The newly added comment claims Fulcio uses the shared KMS type, but the FulcioSigner in v1 is
restricted to file and only contains File *FulcioFile, with no KMS signer fields.

api/v1/common.go[235-242]
api/v1/fulcio_types.go[42-55]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `api/v1/common.go` comment on `type KMS` states it is used by “TSA and Fulcio signer backends,” but the current v1 Fulcio API does not expose any KMS signer configuration.

## Issue Context
This is a documentation/maintainability issue: it can mislead readers into assuming Fulcio supports KMS signers today or that changes to this struct affect Fulcio.

## Fix Focus Areas
- Update the comment to reflect actual consumers (e.g., TSA only), or reword to be generic/forward-looking:
 - api/v1/common.go[235-238]
- Verify Fulcio signer configuration does not reference KMS in v1 (for accurate wording):
 - api/v1/fulcio_types.go[42-55]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Tip of the day
💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Grey Divider

Qodo Logo

Comment thread api/v1/rekor_types.go Outdated
@kdacosta0

Copy link
Copy Markdown
Member Author

/retest

1 similar comment
@kdacosta0

Copy link
Copy Markdown
Member Author

/retest

@bouskaJ bouskaJ left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kdacosta0 is it tested?

Comment thread api/v1/common.go Outdated
Comment on lines +236 to +237
// Used by TSA and Fulcio signer backends.
// XValidation is also present on RekorSigner.KMS (string field) in rekor_types.go.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do not comment where it is used and where it is validated - the comment is propagated into API desc.

Comment thread api/v1/rekor_types.go Outdated
// +kubebuilder:validation:XValidation:rule="self == 'secret' || self == 'memory' || self.matches('^awskms://.+$') || self.matches('^gcpkms://.+$') || self.matches('^azurekms://.+$') || self.matches('^hashivault://.+$')",message="KMS must be 'secret', 'memory', or a valid URI with a key path (e.g., awskms:///key-id)"
// - openbao://keyname
// +kubebuilder:validation:XValidation:rule="self == 'secret' || self == 'memory' || self.matches('^awskms://.+$') || self.matches('^gcpkms://.+$') || self.matches('^azurekms://.+$') || self.matches('^hashivault://.+$') || self.matches('^openbao://.+$')",message="KMS must be 'secret', 'memory', or a valid URI with a key path (e.g., awskms:///key-id)"
KMS string `json:"kms,omitempty"`

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we reuse the KMS struct instead of the plain string?

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It will be good to migrate Rekor to use same structures like TSA, CTlog and Fulcio for signer config

@kdacosta0

Copy link
Copy Markdown
Member Author

@kdacosta0 is it tested?

@bouskaJ Yes, tested on ocp - signing and verification was successful

Comment thread api/v1/rekor_types.go Outdated
Comment thread api/v1/common.go
Comment thread api/v1/rekor_types.go
…ESIGN-5076)

Add openbao:// as a valid KMS URI scheme alongside gcpkms://, azurekms://,
hashivault://, and awskms:// in the shared KMS struct validation.

Refactor Rekor signer from a flat KMS string to a struct-based pattern
matching TSA/CTLog/Fulcio: Type enum (secret/memory/kms) + *KMS struct
+ *Auth, with CEL XValidation for mutual exclusion.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
@bouskaJ
bouskaJ merged commit 3c3c039 into main Aug 13, 2026
32 of 34 checks passed
@bouskaJ
bouskaJ deleted the feat/openbao-kms-uri branch August 13, 2026 08:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants