[Question] Environment Variables for Containerized KRM Functions

[devstein]

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

[k8s-ci-robot]

@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 triage/accepted label.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[devstein]

One option seems to be to pursue KRM exec functions and rely on the fix proposed in this PR. Would this approach make sense?

[natasha41575]

From the plugin graduation KEP (which we are currently working towards):

The env field for container plugins will be deprecated. In line with Kustomize's principles, plugin configuration should be passed in the KRM object and should not be affected by the execution environment. The network and storage mount options will be retained, as they are needed to support some common generator plugin use cases. Guidance on their appropriate use will be added to the plugin developer documentation.

To answer your question, storage mounts are currently supported (via the mount option) and we plan to keep them around. Let me know if you'd like an example of how to do this, I can dig one up.

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?

One option seems to be to pursue KRM exec functions and rely on the fix proposed in this PR. Would this approach make sense?

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.

[devstein]

Hi @natasha41575 thanks for getting back to me!

Is the example in this issue a valid example of the mount option?

Environment variables are preferable, but for the KSOPS use-case, we could also mount the credentials as volume (i.e ~/.aws/credentials in the KMS case).

KRM exec function is appealing because it will be the simplest migration for KSOPS users.

[natasha41575]

@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
/triage not-an-issue

/unlabel needs-kind
/unlabel needs-triage

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

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:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten