secrets-store-csi-driver
secrets-store-csi-driver copied to clipboard
kubernetes-sigs
Leverage secret store csi driver in a new CRD
Describe the solution you'd like Hi, I would like to understand how to leverage the functionality of the secret store csi driver using my own CRD. I would like customer to specify information like keyvault location/ clientId/ object name in a new CRD instead of the SecretProviderClass. Could I then create a secret provider class internally, is that recommended?
For context: I m working on a open source project Ratify which provides integration for various image validation scenarios. We are planning to create a "Verifier" CRD that allows customers to specify the tool and the certificate to validate the signature container image. A sample verifier would be the notary verifier which customer will be specifying the location of their key vault provider. We would like to keep all configuration in one CRD for a better user experience.
Please let us know if you have any suggestions for our use case. thanks!
Environment:
- Secrets Store CSI Driver version: v1.2.3
- Kubernetes version: Kubernetes v1.20
Hi,
A follow up question, if the customer define a new SecretProviderClass CR at runtime to specify a new keyvault cert, if this new cert needs to be mounted to a different path, will a pod restart be required? our deployment file for context. thanks!
Hello 👋🏻
I would like to understand how to leverage the functionality of the secret store csi driver using my own CRD. I would like customer to specify information like keyvault location/ clientId/ object name in a new CRD instead of the SecretProviderClass. Could I then create a secret provider class internally, is that recommended?
The Secrets Store CSI Driver needs SecretProviderClass to be able to call the provider, get the contents and mount the secrets. "who" creates the SecretProviderClass is up to the workload creator which in this case would be your client in Ratify. The CRD you would create for ratify would be the only CRD that users might need to configure and based on all the info, you can then create the SecretProviderClass required for mounting volumes with the driver.
A follow up question, if the customer define a new SecretProviderClass CR at runtime to specify a new keyvault cert, if this new cert needs to be mounted to a different path, will a pod restart be required? our deployment file for context. thanks!
Change in volumeMount and volume path will trigger a pod restart because that's change to a pod spec. So a restart will happen if you modify the mount path.
Closing this issue with https://github.com/kubernetes-sigs/secrets-store-csi-driver/issues/1035#issuecomment-1238509267. Please feel free to reopen if you have any additional questions.
/close
@aramase: Closing this issue.
In response to this:
Closing this issue with https://github.com/kubernetes-sigs/secrets-store-csi-driver/issues/1035#issuecomment-1238509267. Please feel free to reopen if you have any additional questions.
/close
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.
