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鈥檒l occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Question] Environment Variables for Containerized KRM Functions #4394
Comments
@devstein: This issue is currently awaiting triage. SIG CLI takes a lead on issue triage for this repo, but any Kubernetes member can accept issues by applying the The 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. |
One option seems to be to pursue KRM exec functions and rely on the fix proposed in this PR. Would this approach make sense? |
From the plugin graduation KEP (which we are currently working towards):
To answer your question, storage mounts are currently supported (via the Env vars however are somewhat misaligned with kustomize principles. In general we believe that everything should be available declaratively in the plugin configuration file, and checked into version control. However, I do empathize with the case of wanting to pass in credentials - that's not something you would want to put directly into your config files. @mengqiy @KnVerey WDYT?
Yes, using KRM exec functions will allow you to use env vars and files on your filesystem without needing to pass them along into a container. |
Hi @natasha41575 thanks for getting back to me! Is the example in this issue a valid example of the Environment variables are preferable, but for the KSOPS use-case, we could also mount the credentials as volume (i.e KRM exec function is appealing because it will be the simplest migration for KSOPS users. |
@devstein Yes, that is an example of how to use mounts for containerized functions. If mounting the credentials as a volume works for you then that would be the way to go. Evidently mounting does not always work as detailed in the issue you linked, but we will fix it when we can. That issue would be a good place to look for updates. I confirmed that we are planning to deprecate and remove passing along environment variables into functions. This aligns with our principles of maintaining all configuration explicitly in files that can be checked into version control. /kind support /unlabel needs-kind |
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten |
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules:
You can:
Please send feedback to sig-contributor-experience at kubernetes/community. /close |
@k8s-triage-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. |
Hi 馃憢 I maintain KSOPS a popular kustomize plugin. I'd like to migrate it to the new KRM style plugins, ideally as a containerized KRM function. In order to do so, the container needs access to credentials to decrypt the SOPS encrypted resources.
Is it possible to configure environment variable or volume mounts for Containerized KRM functions?
Related Issue: #4290
The text was updated successfully, but these errors were encountered: