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

You can store credentials for a remote registry in a Secret object. Secrets and configuration maps (ConfigMap) are namespaced objects that enable you to externalize data from your applications in your OpenShift cluster.

You can use the oc create command to create a secret, for example:

[user@host ~]$ oc create secret generic example-secret \
--from-literal=user=developer --namespace=example-ns
secret/example-secret created

The preceding command creates a generic secret, which contains the user key with the developer value. Objects in the example-ns project can refer to that secret.

You can use the OpenShift console to create secrets. In the Developer perspective, click Secrets. Select a project, click Create, and then select the secret type that you want to create.

Figure 3.2: Create secrets in the OpenShift console

Kubernetes provides the docker-registry secret type to store credentials for authentication with the container registry.

[user@host ~]$ oc create secret docker-registry SECRET_NAME \
--docker-server REGISTRY_URL \
--docker-username USER \
--docker-password PASSWORD \
--docker-email=EMAIL
secret/SECRET_NAME created

You can also use the console to create the docker-registry secret.

Figure 3.3: Create docker-registry secrets in the OpenShift console

The docker-registry secret use the following YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: SECRET_NAME
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: DATA

The preceding example uses the URL, user, and password to create the .dockerconfigjson key, with the value similar to the following example:

{
  "auths": {
    "REGISTRY_URL": {
      "username": "USER",
      "password": "PASSWORD",
      "email": "EMAIL",
      "auth": "ebz...eZ2"
    }
  }
}

You can also create the secret from existing credentials. For example, if you logged in to the private registry with Podman, then you have existing credentials in the ${XDG_RUNTIME_DIR}/containers/auth.json file. Because the auth.json file uses the same structure as the .dockerconfigjson file, you can create the secret by using the auth.json file.

[user@host ~]$ oc create secret generic SECRET_NAME \
--from-file .dockerconfigjson=${XDG_RUNTIME_DIR}/containers/auth.json \
--type kubernetes.io/dockerconfigjson

You can also upload the auth.json file in the OpenShift console when creating the secret.

You can configure OpenShift to use custom credentials by using the spec.imagePullSecrets Pod property, for example:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: REGISTRY_URL
  imagePullSecrets:
  - name: SECRET_NAME

Consequently, you can use the property for controllers, such as the Deployment or DeploymentConfig objects:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: example-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: example-container
          image: REGISTRY_URL
      imagePullSecrets:
        - name: SECRET_NAME

Instead of manually assigning the credentials to pods, you can configure OpenShift to assign the credentials to pods automatically by using service accounts. A service account provides an identity for pods. Pods use the default service account unless you configure a different service account.

Use the oc secrets link command to connect a secret with a service account, for example:

[user@host ~]$ oc secrets link --for=pull default SECRET_NAME
no output expected

The preceding command creates a new entry in the service account .spec.imagePullSecrets field:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: default
imagePullSecrets:
- name: SECRET_NAME

When you create a pod that uses the default service account, it inherits the imagePullSecrets field without you explicitly specifying the field in the pod definition.

This means that every pod that uses the default service account is authorized with the registry credentials in your secret.

See the Red Hat OpenShift Administration II: Operating a Production Kubernetes Cluster course for more information about service accounts.