You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am signing my helm charts with cosign. The key is stored in a kms as described in the cosign docs.
Currently Flux only accepts a Secret with the public keys or the OIDC Identity that should be matched.
Steps to reproduce
sign chart with cosign using a key that is stored in a kms
try to verify chart using Flux which is not possible because the kms cant be used to get the public key
Expected behavior
I would like to use the key stored in the kms provider to sign my charts and verify the chart signature.
Is it possible to introduce a new spec.verify.keypath field (or something else) that can be used to specify the key path (e.g. hashivault://my-key-in-transit-engine)?
Screenshots and recordings
No response
OS / Distro
N/A
Flux version
v2.3.0
Flux check
N/A
Git provider
No response
Container Registry provider
No response
Additional context
Authentication for the source controller to the kms provider also needs to be solved, but I think this is another issue that needs to be handled differently for each user/kms.
The current "hacky" solution is: export the public key from the kms provider into a secret and use this secret with the Flux HelmChart verification.
Code of Conduct
I agree to follow this project's Code of Conduct
The text was updated successfully, but these errors were encountered:
Describe the bug
I am signing my helm charts with cosign. The key is stored in a kms as described in the cosign docs.
Currently Flux only accepts a Secret with the public keys or the OIDC Identity that should be matched.
Steps to reproduce
Expected behavior
I would like to use the key stored in the kms provider to sign my charts and verify the chart signature.
Is it possible to introduce a new
spec.verify.keypath
field (or something else) that can be used to specify the key path (e.g.hashivault://my-key-in-transit-engine
)?Screenshots and recordings
No response
OS / Distro
N/A
Flux version
v2.3.0
Flux check
N/A
Git provider
No response
Container Registry provider
No response
Additional context
Authentication for the source controller to the kms provider also needs to be solved, but I think this is another issue that needs to be handled differently for each user/kms.
The current "hacky" solution is: export the public key from the kms provider into a secret and use this secret with the Flux HelmChart verification.
Code of Conduct
The text was updated successfully, but these errors were encountered: