KRM functions are behaving differently for exec and container functions

[xvzf]

What happened?

The -e ENV_VAR=VALUE flag is exposed to container KRM functions as an environment variable, while it is dropped for exec-based functions.

What did you expect to happen?

Container and Exec KRM functions behave the same

How can we reproduce it (as minimally and precisely as possible)?

Here's a repository with the full configuration and example commands to replicate this: https://github.com/xvzf/kustomize-krm-script-example

Expected output

See repo above

Actual output

See repo above

Kustomize version

5.1.1

Operating system

None

[xvzf]

This issue would be addressed by #5316

Ping @koba1t

[koba1t]

Thanks @xvzf!
I'll check the details.

[natasha41575]

/assign @varshaprasad96

[xvzf]

@varshaprasad96 can you consider re-opening my PR? Happy to work on it :)
#5316

[varshaprasad96]

Hello @xvzf, I was investigating this feature to check if there will ever be a scenario where the env var and input argument (through the annotation) be the same. In this case, looks like any argument cannot be passed from the annotation itself because of an implementation detail. To elaborate what I mean:

Consider the scenario where generator looks like:

apiVersion: myDevOpsTeam
kind: SillyConfigMapGenerator
metadata:
  name: whatever
  annotations:
    config.kubernetes.io/function: |
      exec: 
        path: ./plugins/silly-generator.sh --test=<something>
spec:
  altGreeting: Bienvenue
  enableRisky: true

In this case, kustomize build will error with: Error: couldn't execute function: fork/exec ./plugins/silly-generator.sh --test: no such file or directory. Looks like the annotation value is directly passed as is, in the filter path (

kustomize/kyaml/runfn/runfn.go

Line 211 in 0122aa8

identifier = filter.Path

) instead of breaking into args, to be executed here:

kustomize/kyaml/fn/runtime/exec/exec.go

Line 37 in 0122aa8

cmd := exec.Command(c.Path, c.Args...) //nolint:gosec

. Given this, I believe it would be safe to make the behaviour same for containerized and exec based KRM functions.

Thanks for working on the PR. I don't have permissions to re-open it. Probably @natasha41575 / @koba1t can? If not, you can open a new one and reference the issue.

[koba1t]

Thanks @varshaprasad96
I reopened that PR!

[natasha41575]

/triage accepted

[k8s-triage-robot]

This issue has not been updated in over 1 year, and should be re-triaged.

You can:

• Confirm that this issue is still relevant with /triage accepted (org members only)
• Close this issue with /close

For more details on the triage process, see https://www.kubernetes.dev/docs/guide/issue-triage/

/remove-triage accepted

[xvzf]

There's a PR waiting, which fixes this issue