Red Hat OpenShift Developer II: Building and Deploying Cloud-native Applications

Depending on the sensitivity of the data, you can use the configuration map (ConfigMap) or secret (Secret) OpenShift objects to externalize the data.

Use secrets to store sensitive information, such as passwords, keys, and tokens. OpenShift provides a number of secret types:

You can use the secret types to validate the key and data in the secret. The opaque secret type does not provide any validation, and is considered a general puprpose secret type.

Secrets encode the data by using base64 encoding. When OpenShift injects secret data into a container, the data is decoded and either mounted as a file, or injected as environment variables inside the container.

Configuration maps store nonsensitive data. You can store individual properties as well as entire configuration files and JSON data in configuration maps.

The the section called “Configuring OpenShift to Use the Registry Credentials” section describes creating secrets by using the oc command-line interface (CLI) and the OpenShift web console.

Similarly to secrets, you can create configuration maps by using the oc create command:

[user@host ~]$ oc create configmap example-cm \
--from-literal key1=value1 \
--from-literal key2=value2
configmap/example-cm created

The previous command creates the following YAML object:

kind: ConfigMap
metadata:
    name: example-cm
apiVersion: v1
data:
    key1: value1
    key2: value2

You can also create configuration maps from a file, or a directory:

[user@host ~]$ oc create configmap example-cm \
--from-file=redis.conf
configmap/example-cm created

The preceding example creates a configuration map with the redis.conf key and the contents of the file as its value. Developers might also rename the key, such as:

[user@host ~]$ oc create configmap example-cm \
--from-file=primary=/etc/redis/redis.conf \
--from-file=replica=replica-redis.conf
configmap/example-cm created

The preceding example creates a configuration map with the following keys:

Finally, similarly to secrets, you can use the OpenShift web console to create configuration maps. In the developer perspective, click ConfigMaps, select your project, and click Create ConfigMap.

Figure 5.1: Create configuration maps in the OpenShift console

The following commands are common to the secret and configuration maps. You can use either secret or configmap as the resource type.

The preceding commands work on any OpenShift resource. However, to edit secrets, you must use values in base64 encoding. You can encode any string by using the base64 command, for example:

[user@host ~]$ echo -n 'hunter3' | base64
aHVudGVyMw==

The preceding echo command uses the -n parameter to remove a new line from the text. You can use the encoded value to edit secrets.

[user@host ~]$ echo -n 'aHVudGVyMw==' | base64 --decode
hunter3

Finally, you can use the oc extract command to extract the contents of a configuration map or a secret to a directory:

[user@host ~]$ oc extract secret/my-secret --to=/tmp/secret
/tmp/secret/user
/tmp/secret/pass

This means that you can edit the file contents, and use the oc set data command to edit the secret:

[user@host ~]$ oc set data secret/my-secret --from-file=/tmp/secret
secret/my-secret data updated

You can mount configuration maps and secrets as data volumes, or expose the data as environment variables, inside an application container.

To inject all values stored in a configuration map or secret into environment variables for pods created from a deployment, use the oc set env command:

[user@host ~]$ oc set env deployment my-deployment \
--from configmap/my-cm
deployment.apps/my-deployment updated

The preceding command configures the spec.containers.env pod property. For each key in the configuration map, the command creates an uppercase key with the value that refers to the configuration map:

...deployment omitted...
      spec:
        containers:
        - command:
          - sleep
          - infinity
          env:
          - name: KEY1
            valueFrom:
              configMapKeyRef:
                key: key1
                name: my-cm
          image: registry.access.redhat.com/ubi8/ubi:8.0
          imagePullPolicy: IfNotPresent
...deployment omitted...

To mount all keys from a configuration map or secret as files, use the oc set volume command:

[user@host ~]$ oc set volume deployment my-deployment --add \
-t secret -m /path/to/mount/volume \
--name myvol --secret-name my-secret
deployment.apps/my-deployment volume updated

The preceding command defines a new volume in a deployment, and mounts it to the specified path:

...deployment omitted...
    spec:
      containers:
      - command:
        - sleep
        - infinity
        image: registry.access.redhat.com/ubi8/ubi:8.0
        imagePullPolicy: IfNotPresent
        name: ubi
        volumeMounts:
        - mountPath: /mnt/secret
          name: myvol
      volumes:
      - name: myvol
        secret:
          defaultMode: 420
          secretName: my-secret

OpenShift injects the contents ot the secret or configuration map resources during the pod creation.

You can create a service account by using the oc create command:

[user@host ~]$ oc create serviceaccount my-sa
serviceaccount/my-sa created

The previous command creates the following YAML object:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-sa
  namespace: my-ns
imagePullSecrets:
- name: my-sa-dockercfg-rxbhw
secrets:
- name: my-sa-dockercfg-rxbhw

You can assign a custom service account to a deployment or a pod by using the oc set serviceaccount command:

[user@host ~]$ oc set serviceaccount \
deployment nginx-deployment my-sa
deployment.apps/nginx-deployment serviceaccount updated

When you create a pod, OpenShift mounts the token, together with other data, in the /var/run/secrets/kubernetes.io/serviceaccount directory.

For example, consider a test pod in the example-ns namespace:

[user@host ~]$ oc exec test -- \
ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
service-ca.crt
token

You can use the token to communicate with the OpenShift API. This is useful for when pods must communicate with the OpenShift API, for example in CI/CD pipelines. Refer to the Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster course for more details about configuring role-based access control (RBAC) and using service accounts.