This old issue #1444 was simply closed without being commented, or addressed.

We are doing GitOps with Flux's post-build variable substitution which currently requires stringData in the secret.

To clarify, post-build substitution does not require use of the "stringData" field in a candidate manifest, but you want to use that field to sidestep the Base64 encoding, which masks the content you wish to replace.

Flux doesn't pay any attention to field names in the manifests. It serializes them as YAML, and runs envsubst over the bytes.

The Flux's post-build variable substitution documentation clearly states:

Note: For substituting variables in a secret, .spec.stringData field must be used i.e:

---
apiVersion: v1
kind: Secret
metadata:
  name: secret
  namespace: flux-system
type: Opaque
stringData:
  token: ${token}

Yes, that's the documentation clarifying a common situation in which post-build substitution cannot see the content you'd like it to act upon. You have the same problem editing comments in PEM-encoded X.509 certificate bundles that occur in a (Valida|Muta)tingWebhookConfiguration's "webhooks[*].clientConfig.caBundle" field, which is also Base64-encoded.

The Flux documentation is correct, but not complete. I was explaining why you need to use the Secret "stringData" field here.

We also need this, we're using envsubst and it does not work on Secret/data. We need stringData option :D

I could see implementing this, accepting an option in the "secretGenerator[*].options" field, though that field is of type api/types/GeneratorOptions, which means that it's shared with other generators. Alternately, we could lift such an option up into api/types/SecretArgs which already bears the Secret-specific "type" field.

The api/internal/generators.MakeSecret function appears to be the place to handle such a change.

Hi @valerytschopp, thank you for explaining your use case and providing an example in your description. Thanks @seh for investigating.

Yes, we believe it is a reasonable use case to specify the secretGenerator add the data under a stringData field. This may also apply to the binaryData field for ConfigMaps. Can whoever wants to contribute to this feature write a mini-KEP aka kustomize proposal? We will start PR reviews for this feature once that KEP has been approved.

/triage accepted

Edit: Doesn't work - secretGenerator base64 encodes the values, but stringData expects plaintext.

This also works in the meantime:

secretGenerator:
  - name: my-secret
    ...details...

patches:
  # Patch the above secret `data` -> `stringData` because secretGenerator doesn't support `stringData`
  - patch: |-
      - op: move
        from: /data
        path: /stringData
    target:
      kind: Secret
      name: my-secret

This also works in the meantime:

What about the Base64 encoding of the "data" field's value?

You're right, it still gets Base64 encoded. No dice.

Thanks to @filedeploy I found an ugly workaround which works at least for environment variables for pods, which we use with generators so that deployments get restarted once the values change (although this probably doesn't work as well for files):

secretGenerator:
  - name: my-secret
    namespace: my-namespace
    literals: []

patches:
  - patch: |-
      - op: move
        from: /data
        path: /stringData
      - op: add
        path: /stringData
        value:
          API_KEY: ${API_KEY}
          SECRET: ${SECRET_KEY}
    target:
      kind: Secret
      name: my-secret

EDIT: Just found out that the secret suffix does not change anymore with this approach, so this is not really a solution either.

Hi, it would be really useful also with using vals for managing secrets. I hope it will land soon inside the options of secretGenerator or generatorOptions. Something like useStringData: true.
Usage : kustomize build . | vals eval | kubectl apply -f -

I'm so glad you filed this issue.
This has annoyed me in the past.
Seeing Flux users in this discussion motivated me to write a patch.
I succeeded in adding a stringData bool to api/types/SecretArgs like @seh suggested.