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

Allow supersetNode in Helm chart to have its own ENV variables. #16625

Closed
dd-willgan opened this issue Sep 7, 2021 · 5 comments
Closed

Allow supersetNode in Helm chart to have its own ENV variables. #16625

dd-willgan opened this issue Sep 7, 2021 · 5 comments
Labels
#bug Bug report inactive Inactive for >= 30 days

Comments

@dd-willgan
Copy link
Contributor

I'm using Vault env variable injection for passing secrets for my Superset k8s cluster. How this works is that a web-hook looks at the env variables and if they're of the form vault: it'll pull the secret. The pod, however, needs to have the proper annotations for this. My issue is that extraEnv adds the variables to supersetNode, supersetWorker, and the init job but the init job doesn't support podAnnotations through the chart. Since only supersetNode needs the secret I want, as a solution, to have a separate env section under supersetNode in values.yaml that only creates env variables for it.

@wiktor2200
Copy link
Contributor

@dd-willgan Hi! Have you managed to use vault injected variables in form: vault:PATH#SECRET?
I need to pass credential for OAuth (#13915 (comment))
But it fails. I'm asking because maybe you were able to use it some way?

@dd-willgan
Copy link
Contributor Author

@wiktor2200 Hi yes I've been able to. Based on the error message in the comment it seems like client_secret is being set but is just incorrect? When I was having issues with Vault the Kubernetes pod would Error before running.

@wiktor2200
Copy link
Contributor

Thanks for answer! Sorry, I've not noticed notification earlier. You were right the problem was caused by wrong vault policies setting.

@stale
Copy link

stale bot commented Apr 17, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. For admin, please label this issue .pinned to prevent stale bot from closing the issue.

@stale stale bot added the inactive Inactive for >= 30 days label Apr 17, 2022
@rusackas
Copy link
Member

rusackas commented Feb 2, 2023

Sounds from the discussion here that this was effectively resolved over a year ago. Holler if I'm misinterpreting, and we can revisit/reopen.

@rusackas rusackas closed this as completed Feb 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
#bug Bug report inactive Inactive for >= 30 days
Projects
None yet
Development

No branches or pull requests

3 participants