If you are not familiar with the oc command, refer to OpenShift - Getting Started with the oc command.

There are different ways to configure a container with environment variables.

• In a deployment YAML file
• Using Config Map
• Using Secrets (this article)

Config Maps are used to:

• mount configuration files in a container
• create environment variables in a container
• create command line option arguments in a container

Secrets are similar, used to create variables that contain encoded data (e.g. passwords). In this way, if a change is needed to a configuration file, variable, or command line option argument, you just need to update the config map or secret as opposed to having to make the change to your applications or deployments.

Let's say you create a secret named "mysecret" that contains the key "foo" and value "bar".

oc create secret generic mysecret --from-literal=foo="bar"

The oc get secrets command should show that the secret exists.

~]$ oc get secrets
NAME                        TYPE                                  DATA   AGE
mysecret                    Opaque                                1      3m11s

The --output yaml or --output json options can be used to display the YAML or JSON details of the secret. Notice that the "foo" key contains "YmFy" instead of "bar". This is normal, because the secret value is base64 encoded.

~]$ oc get secrets mysecret --output yaml
apiVersion: v1
data:
  foo: YmFy
kind: Secret
metadata:
  creationTimestamp: "2021-11-18T07:12:09Z"
  name: mysecret
  namespace: default
  resourceVersion: "448072461"
  uid: 4104a646-84e2-46c3-bd59-408e2f7ee807
type: Opaque

On a Linux system, the base64 command can be used to decode the value.

~]# echo YmFy | base64 --decode
bar

The oc create secret command with the --dry-run=client and --output yaml option can be used to display the YAML that would have been used to create the secret.

~]$ oc create secret generic mysecret --from-literal=foo="Hello World" --dry-run=client --output yaml
apiVersion: v1
data:
  foo: SGVsbG8gV29ybGQ=
kind: Secret
metadata:
  creationTimestamp: null
  name: mysecret

You could then create a file that contains the YAML and use the oc replace command with the -f or --filename option to replace secret.

oc replace --filename secret.yml

However, more commonly, the oc create secret is piped to the oc replace command as a one liner.

oc create secret generic mysecret --from-literal=foo="Hello World" --dry-run=client --output yaml | oc replace -f -

Now the --output yaml or --output json options can be used to see that the "foo" key contains a new value, "SGVsbG8gV29ybGQ=".

~]$ oc get secrets mysecret --output yaml
apiVersion: v1
data:
  foo: SGVsbG8gV29ybGQ=
kind: Secret
metadata:
  creationTimestamp: "2022-07-30T04:24:02Z"
  name: mysecret
  namespace: default
  resourceVersion: "448072461"
  uid: 4104a646-84e2-46c3-bd59-408e2f7ee807
type: Opaque

And the base64 command can be used to decode the value, which should now return Hello World.

~]# echo SGVsbG8gV29ybGQ= | base64 --decode
Hello World

In this scenario, there is probably already a deployment configured to use my-secret. Here is an example of what the deployment YAML might have to use the value in the "foo" key in the secret named "my-secret".

AVOID TROUBLE

After you update the secret, you will need to delete the pod(s) so that are using the secret so that new pod(s) gets created with the updated secret.

If you update the deployment YAML, new pod(s) will automatically be created.

containers:
- env:
  - name: my_secret
    valueFrom:
      secretKeyRef:
        key: foo
        name: my-secret

The oc exec command and the env or printenv command can be used to see if the "my_secret" variable contains a value of "Hello" in the container.

~]$ oc exec <name of the pod> -- env
my_secret=Hello