cert-manager for Red Hat OpenShift: using self-signed certs in your cluster

In Red Hat OpenShift, cert-manager is a specialized operator that automates the management of X.509 (SSL/TLS) certificates. It acts as a “Certificates-as-a-Service” tool within your cluster, ensuring that applications have valid, up-to-date certificates without requiring manual intervention from administrators.

This blog shows how to use self-signed certs in your cluster.

Here is a Recipe to use trusted ceritifcates in your cluster:

Install the Red Hat cert-manager Operator on OpenShift 4.20 using only the CLI and the official Red Hat catalog, follow these steps.

This process involves creating a namespace, an OperatorGroup, and a Subscription to the Red Hat operator catalog.

  1. Create the Namespace

First, create a dedicated namespace for the cert-manager operator. Red Hat recommends using cert-manager-operator.

oc create namespace openshift-cert-manager-operator
  1. Create the OperatorGroup

An OperatorGroup defines the multi-tenant configuration for the operator. In most cases for cert-manager, we configure it to watch all namespaces (cluster-wide).

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: openshift-cert-manager-operator
  namespace: openshift-cert-manager-operator
spec:
  upgradeStrategy: Default
EOF
  1. Create the Subscription

The Subscription tells the Operator Lifecycle Manager (OLM) which operator to install, which catalog to use, and which channel to track. For OpenShift 4.20, we use the stable-v1 channel from the redhat-operators catalog.

cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: openshift-cert-manager-operator
  namespace: openshift-cert-manager-operator
spec:
  channel: stable-v1
  installPlanApproval: Automatic
  name: openshift-cert-manager-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
EOF
  1. Verify the Installation

It takes a few moments for OLM to process the subscription and deploy the pods. Run these commands to track the progress:

  • Check the Cluster Service Version (CSV) Status
[root@rct-ocp-pra-fbac-bastion-0 ~]# oc get csv -n openshift-cert-manager-operator -w
NAME                            DISPLAY                                       VERSION   REPLACES                        PHASE
cert-manager-operator.v1.18.0   cert-manager Operator for Red Hat OpenShift   1.18.0    cert-manager-operator.v1.17.0   Installing
cert-manager-operator.v1.18.0   cert-manager Operator for Red Hat OpenShift   1.18.0    cert-manager-operator.v1.17.0   Succeeded

Wait until the Phase changes to Succeeded.

  • Check the Operator Pods
oc get pods -n openshift-cert-manager-operator
  • Check the cert-manager Component Pods: Once the operator is running, it will automatically deploy the actual cert-manager components (controller, webhook, and CA injector) into a new namespace called cert-manager.
[root@rct-ocp-pra-fbac-bastion-0 ~]# oc get pods -n cert-manager
NAME                                      READY   STATUS    RESTARTS   AGE
cert-manager-cainjector-758dbfb96-2qsc4   1/1     Running   0          57s
cert-manager-cc4c8748-6xztc               1/1     Running   0          48s
cert-manager-webhook-7949d5896-dqrfn      1/1     Running   0          57s

To set up a self-signed issuer, you need to define a ClusterIssuer (available across the whole cluster) or an Issuer (restricted to a single namespace).

In the context of cert-manager, a Self-Signed issuer is the simplest type; it doesn’t require an external CA or DNS validation. It is often used to bootstrap a Root CA for internal services.

  1. Create a Cluster-Wide Self-Signed Issuer

Use this if you want any namespace in your OpenShift cluster to be able to request self-signed certificates.

cat <<EOF | oc apply -f -
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: selfsigned-cluster-issuer
spec:
  selfSigned: {}
EOF
  1. Verify the Issuer Status

Once applied, check that the issuer is “Ready.”

[root@rct-ocp-pra-fbac-bastion-0 ~]# oc get clusterissuer selfsigned-cluster-issuer
NAME                        READY   AGE
selfsigned-cluster-issuer   True    38s
  1. Create a Root CA Certificate

This certificate will be signed by the ClusterIssuer and act as your internal CA.

oc apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: internal-root-ca
  namespace: cert-manager
spec:
  isCA: true
  commonName: internal-root-ca
  secretName: internal-root-ca-secret
  issuerRef:
    name: selfsigned-cluster-issuer
    kind: ClusterIssuer
EOF
  1. Create the CA ClusterIssuer Now, create an issuer that uses that secret to sign other certificates (like your Webhook’s).
oc apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: console-ca-issuer
  namespace: cert-manager
spec:
  ca:
    secretName: internal-root-ca-secret
EOF
  1. Create the service Certificate The dnsNames must match the Service name of your webhook.
oc apply -f - <<EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: console-demo-plugin-cert
  namespace: console-demo-plugin
spec:
  dnsNames:
    - console-demo-plugin.console-demo-plugin.svc
    - console-demo-plugin.console-demo-plugin.svc.cluster.local
  secretName: console-serving-cert
  issuerRef:
    name: console-ca-issuer
    kind: ClusterIssuer
EOF
  1. Extract the CA bundle from the secret to a local file
oc get secret internal-root-ca-secret -n cert-manager \
  -o jsonpath='{.data.ca\.crt}' | base64 -d > internal-ca-bundle.crt
  1. Add to Cluster Trust store
oc create configmap custom-ca \
  --from-file=ca-bundle.crt=internal-ca-bundle.crt \
  -n openshift-config
  1. Adding certificate authorities to the clust link
oc patch proxy/cluster --type=merge \
  --patch='{"spec":{"trustedCA":{"name":"custom-ca"}}}'
  1. Delete the console pods and wait until it is restarted
[root@rct-ocp-pra-fbac-bastion-0 ~]# oc delete pods -n openshift-console --all
...
[root@rct-ocp-pra-fbac-bastion-0 ~]# oc get pods -n openshift-console
NAME                         READY   STATUS    RESTARTS   AGE
console-7554bb587c-hkqd4     1/1     Running   0          5m24s
console-7554bb587c-jlxtd     1/1     Running   0          5m24s
downloads-678b99d49c-8n64s   1/1     Running   0          5m24s
downloads-678b99d49c-fgmgp   1/1     Running   0          5m24s

You can now use the Certificates in your cluster to secure communication in your cluster.