-
Notifications
You must be signed in to change notification settings - Fork 197
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
Support for extracting JSON paths from a secret #885
Comments
Hi @Garbett1, Thanks for opening issue. Could you describe your approach? Also, PR is always welcome. We can review implementation there as well. |
Hi @nilekhc , Given a secret of:
and a
If I mounted the secret at |
Hey @Garbett1 We are going to discuss this in next community call on May 26th, 2022. I have added it in Agenda. Please feel free to join. Details are here: https://docs.google.com/document/d/1q74nboAg0GSPcom3kLWCIoWg43Qg3mr306KNL58f2hg/edit?usp=sharing |
I'll try to make it! I have another meeting around that time, so might not be possible to join. |
I wasn't able to make it to the office hours. Do you know when the recording of the office hours will be uploaded? |
It is usually available after the meeting. The link of it will be posted in |
I'm also interested on this feature, I need it for a project so I have two questions
|
I can't see this issue in the Roadmap so I just wanted to check if there are any plans to add this? It would be very valuable for our workflows as we tend to store many secrets for an application in a JSON blob. Some of the secrets should be env vars so it would be very useful if I could extract those variables from the JSON and create a secret from them automatically. |
@jesusalvb @dhirschfeld Let's discuss this requirement in the next community call. Could you attend the next one on 12/08? https://docs.google.com/document/d/1q74nboAg0GSPcom3kLWCIoWg43Qg3mr306KNL58f2hg/edit# |
Hi @nilekhc, I'm happy to answer any questions here, or in a discussion if that works? |
I'll discuss this in the community call and update you here. |
If this feature was implemented, shouldn't it be completely generic and not at the driver level? Also, this sounds like a good use case for CEL since that is what Kubernetes uses for CRD validation and admission policy (and plans to use for JWT claim extraction/validation). |
Hello, happy New Year! I'm just circling back to check if there was any discussion of this issue on the community call? I'm currently wanting to specify both the Since you can't specify the name as static value it forces you to create two separate secrets in your Key Vault - one for the name of the account to use and one for the key. Having to create two separate secrets is a bit cumbersome/awkward and also introduces the possibility for bugs. The secrets are associated and don't make sense individually - if someone changes the storage account but forgets to update the storage account name secret it won't work. It's less likely that someone will forget to update an associated secret if all related information is stored in a single Key Vault secret which is a JSON blob. |
Hi @dhirschfeld We did discuss this in the community call. There is a PR out for this - kubernetes-sigs/secrets-store-csi-driver#963 Keep an eye on this. |
Thanks for the update and the link @nilekhc - I'll follow that PR! |
Any update of this change, I am thinking to use azure key vault which has json format secret and I am using azure csi to read it on pod using volume and mount including secrets which will expose as env on pod. |
Hey there :) It's hard to manage hundred of secrets |
Extracting JSON paths from secrets
We use JSON strings in our secret and would like to be able to configure the
SecretProviderClass
to extract the value for a specific key.There is prior art in both HashiCorp Vault and AWS Secret Manager (see
jmesPath
).I'm happy to raise a PR to add this functionality, but want to confirm what approach to extract the key would be ideal.
HashiCorp Vault only allows specifying a key, while AWS allows an arbitrary path to extract. If I was to raise a PR adding this, which approach would be preferred? Specifying only the key is simpler but less flexible.
Environment:
kubectl version
): 1.21.0+The text was updated successfully, but these errors were encountered: