Eschewed features

• This issue is not requesting templating, unstuctured edits, build-time side-effects from args or env vars, or any other eschewed feature.

What would you like to have added?

The secretGenerator should be able to generate Secret manifest with unencoded stringData.

We understand that kustomize eschews parameterization, but the resulting manifest is valid YAML, and can be processed by various tools (envsubst, flux post-build variable substitution, ...).
Therefore we ask the Kustomize SIG to consider this feature.

Example:

cat<<EOF> secret-values.yaml
# Helm values
---
db:
  auth:
    username: ${DB_USERNAME}
    password: ${DB_PASSWORD}
  host: ${DB_HOST}
EOF
cat<<EOF> kustomization.yaml
---
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
secretGenerator:
- name: secret-values
  files:
  - values.yaml=secret-values.yaml
generatorOptions:
  disableNameSuffixHash: true
  stringData: true
EOF

kustomize build .

apiVersion: v1
kind: Secret
metadata:
  name: secret-secret-values
stringData:
  values.yaml: |-
    db:
      auth:
        username: ${DB_USERNAME}
        password: ${DB_PASSWORD}
      host: ${DB_HOST}

Why is this needed?

We are doing GitOps with Flux's post-build variable substitution which currently requires stringData in the secret.
Base64 encoded values would not be able to be substitued.

Can you accomplish the motivating task without this feature, and if so, how?

Create the Secret by hand with stringData:

---
apiVersion: v1
kind: Secret
metadata:
    name: secret-secret-values
stringData:
  values.yaml: |-
    db:
      auth:
        username: ${DB_USERNAME}
        password: ${DB_PASSWORD}
      host: ${DB_HOST}

But this negate the usefulness of Kustomize generators.

What other solutions have you considered?

Don't use secretGenerator for Helm secret values

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉