Have an optionalFiles field in secretGenerator

[sei-areuter]

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?

Not sure if many other people have faced this issue, but we have a secret that we need to mount into our kustomize deployment if it exists. If not then the deployment can disregard it. I was wondering if there would be any value in setting up something like the following in the kustomization.yaml

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ns.yaml
  - rbac.yaml
  - deployment.yaml
configMapGenerator:
  - name: test-deployment
     files:
    - state-values.yaml
secretGenerator:
  - name: ace-secrets
    files:
    - secret-values.yaml
    optionalFiles:                   # new feature. IF any files under this key do not exist then still deploy
    - LDAP_PASSWORD=./secrets/gitlab/ldap/password
namespace: test-deployment-system

Why is this needed?

If we need optional configs in our deployment depending on where our kustomizes get deployed then this is needed

Example: Gitlab has support for ldap single-sign on. We want to use this in certain environments and need to mount the password. In other environments we don't have LDAP support and don't want to use the password

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

Technically yes. At the moment I am just creating a blank file. It is a hacky solution, but it would work for us

What other solutions have you considered?

if kustomize had env support we could wrap that section so it isn't deployed (don't want to create this file with a bash script)

I know this goes against kustomize so I am not suggesting support for this solution - if there was a way to accomplish this using patching then that is a valid solution

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - ns.yaml
  - rbac.yaml
  - deployment.yaml
configMapGenerator:
  - name: test-deployment
     files:
    - state-values.yaml
secretGenerator:
  - name: ace-secrets
    files:
    - secret-values.yaml
    {{ if $LDAP_ENABLED }}
   - LDAP_PASSWORD=./secrets/gitlab/ldap/password
   {{ end }}
namespace: test-deployment-system

Anything else we should know?

No response

Feature ownership

• I am interested in contributing this feature myself! 🎉

[sda399]

Hi,
I would probably go with an overlay for envs with ldap support

[sei-areuter]

Hi, I would probably go with an overlay for envs with ldap support

Could you elaborate what you mean, since kustomize doesn't have env support (or at least that is what I am told)? Our specific usecase is because we may require a secret/key in a secret to exist in the cluster that is mounted into the pod if we are enabling ldap so it can be mounted into necessary deployments, if we don't then it should still deploy even without file/secret existing.

However, I think having optional keys / cms / secrets makes sense from a feature perspective (and also fits my usecase better).

Could you provide an example of what you are talking about with env support? I would also like the ability to configure the name of the secret / cm on deployment. That isn't a necessarily important detail for us, but would be a nice to have if it is possible with env

[sda399]

your environments with ldap installed can have their own overlay, with the specific configuration for ldap

[sei-areuter]

The LDAP is external to kubernetes so the gitlab-secret won't be pre-existing. Also this is just a specific usecase I was working with (I have desired this in a few other cases, this is just the specifc one I provided). There are scenarios where this is relatively common in k8s. In deployment/sts volumeMounts the following is supported. Basically I would like similar support for this in kustomize.

# inside container
        ...
        envFrom:
        - configMapRef:
                 name: proxy
                 optional: true # optional so that you can disable proxy variables by deleting proxy cm

I assumed having it as a separate key would be less work on a development side

[shapirus]

This is similar to the old controversial issue of enabling wildcard-based file references #119

At some point it was implemented, then rolled back for unclear reasons.

[sei-areuter]

Yea this would resolve my issue. Since if it doesn't match my wild-card then nothing should appear. The comments are a little discouraging and it seems like this feature isn't going to be added... Alas

[koba1t]

Hello.

I feel this use case can be resolved by combining the secretGenerator overlay with behavior: merge.
https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/secretgenerator/
https://kubectl.docs.kubernetes.io/references/kustomize/kustomization/configmapgenerator/#overriding-base-configmap-values

/triage not-an-issue