K
Q

Combining multiple k8s secrets into an env variable

1/13/2019

My k8s namespace contains a Secret which is created at deployment time (by svcat), so the values are not known in advance.

apiVersion: v1
kind: Secret
type: Opaque
metadata:
  name: my-database-credentials
data:
  hostname: ...
  port: ...
  database: ...
  username: ...
  password: ...

A Deployment needs to inject these values in a slightly different format:

...

containers:
  env:
  - name: DATABASE_URL
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: jdbc:postgresql:<hostname>:<port>/<database> // ??

  - name: DATABASE_USERNAME
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: username

  - name: DATABASE_PASSWORD
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: password

The DATABASE_URL needs to be composed out of the hostname, port, 'database` from the previously defined secret.

Is there any way to do this composition?

-- metacubed
kubernetes
kubernetes-helm

Similar Questions

Jenkins - sshagent plugin doesn't work with Kubernetes plugin
Why don't two Kubernetes ReplicaSets with same selector conflict with each other?
Not able to connect to a container(Created via Rest API) in Kubernetes
CockroachDB on Single Cluster Kube PODs fail with CrashLoopBackOff
Install fails with error create: failed to create: Secret &quot;sh.helm.release.v1.&lt;release&gt;.v1&quot; is invalid:data:Too long:must have at most 1048576 bytes
Prometheus-server: Appending scrape report failed&quot; err=&quot;write to WAL: log samples: write /data/wal/00007153: read-only file system&quot;

4 Answers

1/15/2019

Kubernetes allows you to use previously defined environment variables as part of subsequent environment variables. From the Kubernetes API reference docs:

Variable references $(VAR_NAME) are expanded using the previous defined environment variables in the container and any service environment variables.

So, you can first extract the required secret values into environment variables, and then compose the DATABASE_URL with those variables.

...

containers:
  env:
  - name: DB_URL_HOSTNAME               // part 1
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: hostname

  - name: DB_URL_PORT                   // part 2
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: port

  - name: DB_URL_DBNAME                 // part 3
    valueFrom:
      secretKeyRef:
        name: my-database-credentials
        key: database

  - name: DATABASE_URL                  // combine
    value: jdbc:postgresql:$(DB_URL_HOSTNAME):$(DB_URL_PORT)/$(DB_URL_DBNAME)

...

Note the round brackets $(...) used for variable expansion.

-- metacubed
Source: StackOverflow
1/14/2019

You can do a couple of things I can think of:

  1. Use a secrets volume and make a startup script that reads the secrets from the volume and then starts your application with the DATABASE_URL environment variable.

    apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: your_db_container
    command: [ "yourscript.sh" ]
    volumeMounts:
    - name: mycreds
      mountPath: "/etc/credentials"
  volumes:
  - name: mycreds
    secret:
      secretName: my-database-credentials
      defaultMode: 256

  2. Pass the env variable in the command key of your container spec:

    apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: your_db_container
    command: [ "/bin/sh", "-c", "DATABASE_URL=jdbc:postgresql:<hostname>:<port>/<database>/$(DATABASE_USERNAME):$(DATABASE_PASSWORD) /start/yourdb" ]

    env:
    - name: DATABASE_USERNAME
      valueFrom:
        secretKeyRef:
          name: my-database-credentials
          key: username
    - name: DATABASE_PASSWORD
      valueFrom:
        secretKeyRef:
        name: my-database-credentials
        key: password
-- Rico
Source: StackOverflow
4/15/2020

If all the pre-variables are defined as env variables:

-  { name: DATABASE_URL, value: '{{ printf "jdbc:postgresql:$(DATABASE_HOST):$(DATABASE_PORT)/$(DB_URL_DBNAME)" }}'}

With this statement you may also bring in vlaues from the values.yaml file as well:

For Example:

If you may have defined DB_URL_DBNAME in the values file:

-  { name: DATABASE_URL, value: '{{ printf "jdbc:postgresql:$(DATABASE_HOST):$(DATABASE_PORT)/%s" .Values.database.DB_URL_DBNAME }}'}
-- suresh Palemoni
Source: StackOverflow
1/14/2019

There are several ways to go (in increasing complexity order):

  1. Mangle the parameter before putting it into the Secret (extend whatever you use to insert the info there).

  2. Add a script into your Pod/Container to mangle the incoming parameters (environmental variables or command arguments) into what is needed. If you cannot or don't want to have your own container image, you can add your extra script as a Volume to the container, and set the Container's command field to override the container image start command.

  3. Add a facility to your Kubernetes to do an automatic mangling "behind the scenes": you can add a Dynamic Admission Controller to do your mangling, or you can create a Kubernetes Operator and add a Custom Resource Definition (the operator would be told by the CRD which Secrets to watch for changes, and the operator would read the values and generate whatever other entries you want).

-- Laszlo Valko
Source: StackOverflow