-
Notifications
You must be signed in to change notification settings - Fork 135
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
Query: Use of Secrets Store CSI driver provider #609
Comments
Related to #604 ? |
I don't think we support this today, though it wouldn't be too hard to add (we'd just need to add support for reading a key from a file). Main reason we haven't done this is that configuration would require modifying the deployment spec directly + redeployment of the controller, we we suspect most users don't want to do. For vault in particular, you may want to look into https://github.com/tektoncd/chains/blob/main/docs/signing.md#kms |
Thanks for your response. Are you please aware of any tutorials or step-by-step guides for using Hashicorp Vault with tekton-chains - I can't see any instructions in the documentation? |
Issues go stale after 90d of inactivity. /lifecycle stale Send feedback to tektoncd/plumbing. |
@mtcolman did you have any luck with the configuration |
@cooktheryan I didn't get round to trying it - I can't find any guidance on how to configure it. |
@mtcolman ill keep trying to hack on it. I also opened a documentation RFE |
Stale issues rot after 30d of inactivity. /lifecycle rotten Send feedback to tektoncd/plumbing. |
Rotten issues close after 30d of inactivity. /close Send feedback to tektoncd/plumbing. |
@tekton-robot: Closing this issue. In response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
Hello,
Is it possible to use a Secrets Store CSI driver provider (for example for HashiCorp Vault) to inject the private key for signing, rather than storing it as a Kubernetes secret (as is stated here):
I'm keen to avoid storing any secrets we don't have to as Kubernetes Secrets and so we would like to use Vault + injection into pods where possible.
Thanks!
Matt
The text was updated successfully, but these errors were encountered: