Kustomize: Feature: add values from commands in configMapGenerator

[laupow]

I'd like the abiltiy to load ConfigMap values from a command, like the functionality found in secretGenerator.

A specific example:

1. Terraform provisions a new CloudFront distribution
2. Terraform exposes the new hostname as a Terraform output value: CLOUDFRONT_HOSTNAME
3. The secretGenerator executes a command to load the hostname value from the Terraform output

Example kustomization.yaml I have today:

configMapGenerator:
  - name: app-config
    behavior: merge
    literals:
      - HOSTNAME=www.example.com
      - S3_BUCKET=my-s3-bucket
      - S3_REGION=us-east-2
      - S3_ACCESS_KEY=my-access-key

secretGenerator:
  - name: app-secrets
    commands:
      # Get a named variable from a Terraform output
      CLOUDFRONT_HOSTNAME: "get_terraform_output.sh  CLOUDFRONT_HOSTNAME"
      # Get a named env var from an Ansible Vault encrypted .env file
      S3_SECRET_KEY: "get_vaulted_secret.sh  S3_SECRET_KEY"

The current workaround is to put certain values inside of secrets, rather than configmaps, which is a little confusing.

Ideally we'd have the ability to write a configMapGenerator similar to:

configMapGenerator:
  - name: app-config
    behavior: merge
    literals:
      - HOSTNAME=www.example.com
      - S3_BUCKET=my-s3-bucket
      - S3_REGION=us-east-2
      - S3_ACCESS_KEY=my-access-key
    commands:
      CLOUDFRONT_HOSTNAME: "get_terraform_output.sh  CLOUDFRONT_HOSTNAME"

PS: _Thank you_ for developing kustomize! 👏

[Liujingfang1]

@laupow In my opinion, a Secret suits your use cases better than a ConfigMap. The data you presented contained hostname and access key. They are sensitive or confidential data. Even you don't think they are, it is good to have some protection on them. Secret uses 64 based encoding.

[laupow]

@Liujingfang1 Thanks! Yeah, the use case I presented may be entirely reasonable as is.

I entirely agree that mapping to values to Secrets is the predominant use case, but if a non-sensitive configuration also comes from an external source, my team wonders why I store it as Secret rather than a ConfigMap.

In my mind, loading values with the command method represent a valuable way to map values from an external source into Kubernetes ConfigMaps and Secrets. I'm trying to think of a more appropriate example, but haven't pinpointed one quite yet. My general idea is around an infrastructure provisioning tool like Ansible/Terraform making new resources and exporting public endpoints to Kubernetes. Endpoints aren't often sensitive, but the value would need to be stored as a Secret.

But, I suspect I'm defining a problem that isn't, as storing the values in Secrets works. Please close if you concur!

[KarstenSiemer]

I'd also like to request such functionality for configmaps since one could use command and reference a script to cat * from a directory with all pieces of a splitted config to create a configmap with a single file inside from many files. Then one could tread configfiles like modules which is nice. The information wouldn't have to in a secret since it could only be label maps to get targets for prometheus for example

[Liujingfang1]

Close this request since commands was dropped due to security concern.