Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flux HelmChart cant use cosign with kms #4989

Open
1 task done
simonostendorf opened this issue Sep 17, 2024 · 0 comments
Open
1 task done

Flux HelmChart cant use cosign with kms #4989

simonostendorf opened this issue Sep 17, 2024 · 0 comments

Comments

@simonostendorf
Copy link

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

  1. sign chart with cosign using a key that is stored in a kms
  2. 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
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

No branches or pull requests

1 participant