Skip to content
This repository has been archived by the owner on Jan 19, 2024. It is now read-only.

Allow renaming of environment variables imported from kubernetes secrets #68

Open
botchk opened this issue Aug 18, 2021 · 0 comments
Open
Labels
type:improvement Improves/enhances an existing feature

Comments

@botchk
Copy link
Collaborator

botchk commented Aug 18, 2021

Suppose the following kubernetes secret exists:

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  username: YWRtaW4=
  password: aGRibm9laGZibw==

Currently the whole secret (all key/value pairs) can be imported as environment variables in the following way:

env:
  - name: mysecret
    valueFrom: secret

For easier reuse of secrets in different jobs it might be useful to be able to rename secrets. I propose to rework the env feature to work more like kubernetes. For the above example the new configuration would look like this:

env:
  - name: USERNAME_ALPHA
    valueFrom:
      secretKeyRef:
        name: mysecret
        key: username

This allows to import one specific key username of the secret mysecret and make it available under the environment variable USERNAME_ALPHA in the container.

To still allow the import of all key/value pairs in a secret a envFrom syntax can be used (https://kubernetes.io/docs/concepts/configuration/secret/#use-case-as-container-environment-variables):

envFrom:
  - secretRef:
      name: mysecret

Similar, referencing the event goes from this:

env:
  - name: HOST
    value: '$.data.deployment.deploymentURIsLocal[0]'
    valueFrom: event

to this:

env:
  - name: HOST
    valueFrom:
      eventKeyRef:
        // no name needed since there is only one event to reference anyway
        key: '$.data.deployment.deploymentURIsLocal[0]'

And for simple string values this:

env:
  - name: DATA_DIR
    valueFrom: string
    value: /tmp/data

simplifies to:

env:
  - name: DATA_DIR
    value: /tmp/data

Overall the rework would make env work like in kubernetes and prevent confusion on why the job-executor-service works slightly different. This would also introduce breaking changes and the supported apiVersion of the configuration must be increased.

@christian-kreuzberger-dtx christian-kreuzberger-dtx added the type:improvement Improves/enhances an existing feature label May 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type:improvement Improves/enhances an existing feature
Projects
None yet
Development

No branches or pull requests

2 participants