Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 9. cert-manager Operator for Red Hat OpenShift
9.1. cert-manager Operator for Red Hat OpenShift overview
The cert-manager Operator for Red Hat OpenShift is a cluster-wide service that provides application certificate lifecycle management. The cert-manager Operator for Red Hat OpenShift allows you to integrate with external certificate authorities and provides certificate provisioning, renewal, and retirement.
9.1.1. About the cert-manager Operator for Red Hat OpenShift
The cert-manager project introduces certificate authorities and certificates as resource types in the Kubernetes API, which makes it possible to provide certificates on demand to developers working within your cluster. The cert-manager Operator for Red Hat OpenShift provides a supported way to integrate cert-manager into your OpenShift Container Platform cluster.
The cert-manager Operator for Red Hat OpenShift provides the following features:
- Support for integrating with external certificate authorities
- Tools to manage certificates
- Ability for developers to self-serve certificates
- Automatic certificate renewal
Do not attempt to use both cert-manager Operator for Red Hat OpenShift for OpenShift Container Platform and the community cert-manager Operator at the same time in your cluster.
Also, you should not install cert-manager Operator for Red Hat OpenShift for OpenShift Container Platform in multiple namespaces within a single OpenShift cluster.
9.1.2. Supported issuer types
The cert-manager Operator for Red Hat OpenShift supports the following issuer types:
- Automated Certificate Management Environment (ACME)
- Certificate authority (CA)
- Self-signed
- Vault
- Venafi
- Nokia NetGuard Certificate Manager (NCM)
9.1.3. Certificate request methods
There are two ways to request a certificate using the cert-manager Operator for Red Hat OpenShift:
- Using the
cert-manager.io/CertificateRequest
object -
With this method a service developer creates a
CertificateRequest
object with a validissuerRef
pointing to a configured issuer (configured by a service infrastructure administrator). A service infrastructure administrator then accepts or denies the certificate request. Only accepted certificate requests create a corresponding certificate. - Using the
cert-manager.io/Certificate
object -
With this method, a service developer creates a
Certificate
object with a validissuerRef
and obtains a certificate from a secret that they pointed to theCertificate
object.
9.1.4. Supported cert-manager Operator for Red Hat OpenShift versions
OpenShift Container Platform 4.17 supports the following versions of cert-manager Operator for Red Hat OpenShift:
- cert-manager Operator for Red Hat OpenShift 1.13
9.1.5. About FIPS compliance for cert-manager Operator for Red Hat OpenShift
Starting with version 1.14.0, cert-manager Operator for Red Hat OpenShift is designed for FIPS compliance. When running on OpenShift Container Platform in FIPS mode, it uses the RHEL cryptographic libraries submitted to NIST for FIPS validation on the x86_64, ppc64le, and s390X architectures. For more information about the NIST validation program, see Cryptographic module validation program. For the latest NIST status for the individual versions of the RHEL cryptographic libraries submitted for validation, see Compliance activities and government standards.
To enable FIPS mode, you must install cert-manager Operator for Red Hat OpenShift on an OpenShift Container Platform cluster configured to operate in FIPS mode. For more information, see "Do you need extra security for your cluster?"
9.1.6. Additional resources
9.2. cert-manager Operator for Red Hat OpenShift release notes
The cert-manager Operator for Red Hat OpenShift is a cluster-wide service that provides application certificate lifecycle management.
These release notes track the development of cert-manager Operator for Red Hat OpenShift.
For more information, see About the cert-manager Operator for Red Hat OpenShift.
9.2.1. cert-manager Operator for Red Hat OpenShift 1.14.1
Issued: 2024-11-04
The following advisory is available for the cert-manager Operator for Red Hat OpenShift 1.14.1:
Version 1.14.1
of the cert-manager Operator for Red Hat OpenShift is based on the upstream cert-manager version v1.14.7
. For more information, see the cert-manager project release notes for v1.14.7.
9.2.1.1. CVEs
9.2.2. cert-manager Operator for Red Hat OpenShift 1.14.0
Issued: 2024-07-08
The following advisory is available for the cert-manager Operator for Red Hat OpenShift 1.14.0:
Version 1.14.0
of the cert-manager Operator for Red Hat OpenShift is based on the upstream cert-manager version v1.14.5
. For more information, see the cert-manager project release notes for v1.14.5.
9.2.2.1. New features and enhancements
FIPS compliance support
With this release, FIPS mode is now automatically enabled for cert-manager Operator for Red Hat OpenShift. When installed on an OpenShift Container Platform cluster in FIPS mode, cert-manager Operator for Red Hat OpenShift ensures compatibility without affecting the cluster’s FIPS support status.
Securing routes with cert-manager managed certificates (Technology Preview)
With this release, you can manage certificates referenced in Route
resources by using the cert-manager Operator for Red Hat OpenShift. For more information, see Securing routes with the cert-manager Operator for Red Hat OpenShift.
NCM issuer
The cert-manager Operator for Red Hat OpenShift now supports the Nokia NetGuard Certificate Manager (NCM) issuer. The ncm-issuer
is a cert-manager external issuer that integrates with the NCM PKI system using a Kubernetes controller to sign certificate requests. This integration streamlines the process of obtaining non-self-signed certificates for applications, ensuring their validity and keeping them updated.
The NCM issuer is validated only with version 1.1.1 and the cert-manager Operator for Red Hat OpenShift version 1.14.0. This version handles tasks such as issuance, renewal, and managing certificates for the API server and ingress controller of OpenShift Container Platform clusters.
9.2.2.2. CVEs
9.2.3. cert-manager Operator for Red Hat OpenShift 1.13.1
Issued: 2024-05-15
The following advisory is available for the cert-manager Operator for Red Hat OpenShift 1.13.1:
Version 1.13.1
of the cert-manager Operator for Red Hat OpenShift is based on the upstream cert-manager version v1.13.6
. For more information, see the cert-manager project release notes for v1.13.6.
9.2.3.1. CVEs
9.2.4. cert-manager Operator for Red Hat OpenShift 1.13.0
Issued: 2024-01-16
The following advisory is available for the cert-manager Operator for Red Hat OpenShift 1.13.0:
Version 1.13.0
of the cert-manager Operator for Red Hat OpenShift is based on the upstream cert-manager version v1.13.3
. For more information, see the cert-manager project release notes for v1.13.0.
9.2.4.1. New features and enhancements
- You can now manage certificates for API Server and Ingress Controller by using the cert-manager Operator for Red Hat OpenShift. For more information, see Configuring certificates with an issuer.
-
With this release, the scope of the cert-manager Operator for Red Hat OpenShift, which was previously limited to the OpenShift Container Platform on AMD64 architecture, has now been expanded to include support for managing certificates on OpenShift Container Platform running on IBM Z® (
s390x
), IBM Power® (ppc64le
) and ARM64 architectures. -
With this release, you can use DNS over HTTPS (DoH) for performing the self-checks during the ACME DNS-01 challenge verification. The DNS self-check method can be controlled by using the command line flags,
--dns01-recursive-nameservers-only
and--dns01-recursive-nameservers
. For more information, see Customizing cert-manager by overriding arguments from the cert-manager Operator API.
9.2.4.2. CVEs
9.3. Installing the cert-manager Operator for Red Hat OpenShift
The cert-manager Operator for Red Hat OpenShift is not installed in OpenShift Container Platform by default. You can install the cert-manager Operator for Red Hat OpenShift by using the web console.
9.3.1. Installing the cert-manager Operator for Red Hat OpenShift
9.3.1.1. Installing the cert-manager Operator for Red Hat OpenShift by using the web console
You can use the web console to install the cert-manager Operator for Red Hat OpenShift.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have access to the OpenShift Container Platform web console.
Procedure
- Log in to the OpenShift Container Platform web console.
-
Navigate to Operators
OperatorHub. - Enter cert-manager Operator for Red Hat OpenShift into the filter box.
- Select the cert-manager Operator for Red Hat OpenShift
Select the cert-manager Operator for Red Hat OpenShift version from Version drop-down list, and click Install.
NoteSee supported cert-manager Operator for Red Hat OpenShift versions in the following "Additional resources" section.
On the Install Operator page:
- Update the Update channel, if necessary. The channel defaults to stable-v1, which installs the latest stable release of the cert-manager Operator for Red Hat OpenShift.
Choose the Installed Namespace for the Operator. The default Operator namespace is
cert-manager-operator
.If the
cert-manager-operator
namespace does not exist, it is created for you.Select an Update approval strategy.
- The Automatic strategy allows Operator Lifecycle Manager (OLM) to automatically update the Operator when a new version is available.
- The Manual strategy requires a user with appropriate credentials to approve the Operator update.
- Click Install.
Verification
-
Navigate to Operators
Installed Operators. -
Verify that cert-manager Operator for Red Hat OpenShift is listed with a Status of Succeeded in the
cert-manager-operator
namespace. Verify that cert-manager pods are up and running by entering the following command:
$ oc get pods -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 3m39s cert-manager-cainjector-56cc5f9868-7g9z7 1/1 Running 0 4m5s cert-manager-webhook-d4f79d7f7-9dg9w 1/1 Running 0 4m9s
You can use the cert-manager Operator for Red Hat OpenShift only after cert-manager pods are up and running.
9.3.1.2. Installing the cert-manager Operator for Red Hat OpenShift by using the CLI
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges.
Procedure
Create a new project named
cert-manager-operator
by running the following command:$ oc new-project cert-manager-operator
Create an
OperatorGroup
object:Create a YAML file, for example,
operatorGroup.yaml
, with the following content:apiVersion: operators.coreos.com/v1 kind: OperatorGroup metadata: name: openshift-cert-manager-operator namespace: cert-manager-operator spec: targetNamespaces: - "cert-manager-operator"
Create the
OperatorGroup
object by running the following command:$ oc create -f operatorGroup.yaml
Create a
Subscription
object:Create a YAML file, for example,
subscription.yaml
, that defines theSubscription
object:apiVersion: operators.coreos.com/v1alpha1 kind: Subscription metadata: name: openshift-cert-manager-operator namespace: cert-manager-operator spec: channel: stable-v1 name: openshift-cert-manager-operator source: redhat-operators sourceNamespace: openshift-marketplace installPlanApproval: Automatic startingCSV: cert-manager-operator.v1.13.0
Create the
Subscription
object by running the following command:$ oc create -f subscription.yaml
Verification
Verify that the OLM subscription is created by running the following command:
$ oc get subscription -n cert-manager-operator
Example output
NAME PACKAGE SOURCE CHANNEL openshift-cert-manager-operator openshift-cert-manager-operator redhat-operators stable-v1
Verify whether the Operator is successfully installed by running the following command:
$ oc get csv -n cert-manager-operator
Example output
NAME DISPLAY VERSION REPLACES PHASE cert-manager-operator.v1.13.0 cert-manager Operator for Red Hat OpenShift 1.13.0 cert-manager-operator.v1.12.1 Succeeded
Verify that the status cert-manager Operator for Red Hat OpenShift is
Running
by running the following command:$ oc get pods -n cert-manager-operator
Example output
NAME READY STATUS RESTARTS AGE cert-manager-operator-controller-manager-695b4d46cb-r4hld 2/2 Running 0 7m4s
Verify that the status of cert-manager pods is
Running
by running the following command:$ oc get pods -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-58b7f649c4-dp6l4 1/1 Running 0 7m1s cert-manager-cainjector-5565b8f897-gx25h 1/1 Running 0 7m37s cert-manager-webhook-9bc98cbdd-f972x 1/1 Running 0 7m40s
Additional resources
9.3.2. Understanding update channels of the cert-manager Operator for Red Hat OpenShift
Update channels are the mechanism by which you can declare the version of your cert-manager Operator for Red Hat OpenShift in your cluster. The cert-manager Operator for Red Hat OpenShift offers the following update channels:
-
stable-v1
-
stable-v1.y
9.3.2.1. stable-v1 channel
The stable-v1
channel is the default and suggested channel while installing the cert-manager Operator for Red Hat OpenShift. The stable-v1
channel installs and updates the latest release version of the cert-manager Operator for Red Hat OpenShift. Select the stable-v1
channel if you want to use the latest stable release of the cert-manager Operator for Red Hat OpenShift.
The stable-v1
channel offers the following update approval strategies:
- Automatic
-
If you choose automatic updates for an installed cert-manager Operator for Red Hat OpenShift, a new version of the cert-manager Operator for Red Hat OpenShift is available in the
stable-v1
channel. The Operator Lifecycle Manager (OLM) automatically upgrades the running instance of your Operator without human intervention. - Manual
- If you select manual updates, when a newer version of the cert-manager Operator for Red Hat OpenShift is available, OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the cert-manager Operator for Red Hat OpenShift updated to the new version.
9.3.2.2. stable-v1.y channel
The y-stream version of the cert-manager Operator for Red Hat OpenShift installs updates from the stable-v1.y
channels such as stable-v1.10
, stable-v1.11
, and stable-v1.12
. Select the stable-v1.y
channel if you want to use the y-stream version and stay updated to the z-stream version of the cert-manager Operator for Red Hat OpenShift.
The stable-v1.y
channel offers the following update approval strategies:
- Automatic
-
If you choose automatic updates for an installed cert-manager Operator for Red Hat OpenShift, a new z-stream version of the cert-manager Operator for Red Hat OpenShift is available in the
stable-v1.y
channel. OLM automatically upgrades the running instance of your Operator without human intervention. - Manual
- If you select manual updates, when a newer version of the cert-manager Operator for Red Hat OpenShift is available, OLM creates an update request. As a cluster administrator, you must then manually approve that update request to have the cert-manager Operator for Red Hat OpenShift updated to the new version of the z-stream releases.
9.3.3. Additional resources
9.4. Configuring the egress proxy for the cert-manager Operator for Red Hat OpenShift
If a cluster-wide egress proxy is configured in OpenShift Container Platform, Operator Lifecycle Manager (OLM) automatically configures Operators that it manages with the cluster-wide proxy. OLM automatically updates all of the Operator’s deployments with the HTTP_PROXY
, HTTPS_PROXY
, NO_PROXY
environment variables.
You can inject any CA certificates that are required for proxying HTTPS connections into the cert-manager Operator for Red Hat OpenShift.
9.4.1. Injecting a custom CA certificate for the cert-manager Operator for Red Hat OpenShift
If your OpenShift Container Platform cluster has the cluster-wide proxy enabled, you can inject any CA certificates that are required for proxying HTTPS connections into the cert-manager Operator for Red Hat OpenShift.
Prerequisites
-
You have access to the cluster as a user with the
cluster-admin
role. - You have enabled the cluster-wide proxy for OpenShift Container Platform.
Procedure
Create a config map in the
cert-manager
namespace by running the following command:$ oc create configmap trusted-ca -n cert-manager
Inject the CA bundle that is trusted by OpenShift Container Platform into the config map by running the following command:
$ oc label cm trusted-ca config.openshift.io/inject-trusted-cabundle=true -n cert-manager
Update the deployment for the cert-manager Operator for Red Hat OpenShift to use the config map by running the following command:
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"TRUSTED_CA_CONFIGMAP_NAME","value":"trusted-ca"}]}}}'
Verification
Verify that the deployments have finished rolling out by running the following command:
$ oc rollout status deployment/cert-manager-operator-controller-manager -n cert-manager-operator && \ oc rollout status deployment/cert-manager -n cert-manager && \ oc rollout status deployment/cert-manager-webhook -n cert-manager && \ oc rollout status deployment/cert-manager-cainjector -n cert-manager
Example output
deployment "cert-manager-operator-controller-manager" successfully rolled out deployment "cert-manager" successfully rolled out deployment "cert-manager-webhook" successfully rolled out deployment "cert-manager-cainjector" successfully rolled out
Verify that the CA bundle was mounted as a volume by running the following command:
$ oc get deployment cert-manager -n cert-manager -o=jsonpath={.spec.template.spec.'containers[0].volumeMounts'}
Example output
[{"mountPath":"/etc/pki/tls/certs/cert-manager-tls-ca-bundle.crt","name":"trusted-ca","subPath":"ca-bundle.crt"}]
Verify that the source of the CA bundle is the
trusted-ca
config map by running the following command:$ oc get deployment cert-manager -n cert-manager -o=jsonpath={.spec.template.spec.volumes}
Example output
[{"configMap":{"defaultMode":420,"name":"trusted-ca"},"name":"trusted-ca"}]
9.4.2. Additional resources
9.5. Customizing cert-manager Operator API fields
You can customize the cert-manager Operator for Red Hat OpenShift API fields by overriding environment variables and arguments.
To override unsupported arguments, you can add spec.unsupportedConfigOverrides
section in the CertManager
resource, but using spec.unsupportedConfigOverrides
is unsupported.
9.5.1. Customizing cert-manager by overriding environment variables from the cert-manager Operator API
You can override the supported environment variables for the cert-manager Operator for Red Hat OpenShift by adding a spec.controllerConfig
section in the CertManager
resource.
Prerequisites
-
You have access to the OpenShift Container Platform cluster as a user with the
cluster-admin
role.
Procedure
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: overrideEnv: - name: HTTP_PROXY value: http://<proxy_url> 1 - name: HTTPS_PROXY value: https://<proxy_url> 2 - name: NO_PROXY value: <ignore_proxy_domains> 3
- Save your changes and quit the text editor to apply your changes.
Verification
Verify that the cert-manager controller pod is redeployed by running the following command:
$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 39s
Verify that environment variables are updated for the cert-manager pod by running the following command:
$ oc get pod <redeployed_cert-manager_controller_pod> -n cert-manager -o yaml
Example output
env: ... - name: HTTP_PROXY value: http://<PROXY_URL> - name: HTTPS_PROXY value: https://<PROXY_URL> - name: NO_PROXY value: <IGNORE_PROXY_DOMAINS>
9.5.2. Customizing cert-manager by overriding arguments from the cert-manager Operator API
You can override the supported arguments for the cert-manager Operator for Red Hat OpenShift by adding a spec.controllerConfig
section in the CertManager
resource.
Prerequisites
-
You have access to the OpenShift Container Platform cluster as a user with the
cluster-admin
role.
Procedure
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: overrideArgs: - '--dns01-recursive-nameservers=<server_address>' 1 - '--dns01-recursive-nameservers-only' 2 - '--acme-http01-solver-nameservers=<host>:<port>' 3 - '--v=<verbosity_level>' 4 - '--metrics-listen-address=<host>:<port>' 5 - '--issuer-ambient-credentials' 6 webhookConfig: overrideArgs: - '--v=4' 7 cainjectorConfig: overrideArgs: - '--v=2' 8
- 1
- Provide a comma-separated list of nameservers to query for the DNS-01 self check. The nameservers can be specified either as
<host>:<port>
, for example,1.1.1.1:53
, or use DNS over HTTPS (DoH), for example,https://1.1.1.1/dns-query
. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the Automated Certificate Management Environment (ACME) HTTP01 self check. For example,--acme-http01-solver-nameservers=1.1.1.1:53
. - 4 7 8
- Specify to set the log level verbosity to determine the verbosity of log messages.
- 5
- Specify the host and port for the metrics endpoint. The default value is
--metrics-listen-address=0.0.0.0:9402
. - 6
- You must use the
--issuer-ambient-credentials
argument when configuring an ACME Issuer to solve DNS-01 challenges by using ambient credentials.
NoteDNS over HTTPS (DoH) is supported starting only from cert-manager Operator for Red Hat OpenShift version 1.13.0 and later.
- Save your changes and quit the text editor to apply your changes.
Verification
Verify that arguments are updated for cert-manager pods by running the following command:
$ oc get pods -n cert-manager -o yaml
Example output
... metadata: name: cert-manager-6d4b5d4c97-kldwl namespace: cert-manager ... spec: containers: - args: - --acme-http01-solver-nameservers=1.1.1.1:53 - --cluster-resource-namespace=$(POD_NAMESPACE) - --dns01-recursive-nameservers=1.1.1.1:53 - --dns01-recursive-nameservers-only - --leader-election-namespace=kube-system - --max-concurrent-challenges=60 - --metrics-listen-address=0.0.0.0:9042 - --v=6 ... metadata: name: cert-manager-cainjector-866c4fd758-ltxxj namespace: cert-manager ... spec: containers: - args: - --leader-election-namespace=kube-system - --v=2 ... metadata: name: cert-manager-webhook-6d48f88495-c88gd namespace: cert-manager ... spec: containers: - args: ... - --v=4
9.5.3. Deleting a TLS secret automatically upon Certificate removal
You can enable the --enable-certificate-owner-ref
flag for the cert-manager Operator for Red Hat OpenShift by adding a spec.controllerConfig
section in the CertManager
resource. The --enable-certificate-owner-ref
flag sets the certificate resource as an owner of the secret where the TLS certificate is stored.
If you uninstall the cert-manager Operator for Red Hat OpenShift or delete certificate resources from the cluster, the secret is deleted automatically. This might cause network connectivity issues depending upon where the certificate TLS secret is being used.
Prerequisites
-
You have access to the OpenShift Container Platform cluster as a user with the
cluster-admin
role. - You have installed version 1.12.0 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
Check that the
Certificate
object and its secret are available by running the following command:$ oc get certificate
Example output
NAME READY SECRET AGE certificate-from-clusterissuer-route53-ambient True certificate-from-clusterissuer-route53-ambient 8h
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster # ... spec: # ... controllerConfig: overrideArgs: - '--enable-certificate-owner-ref'
- Save your changes and quit the text editor to apply your changes.
Verification
Verify that the
--enable-certificate-owner-ref
flag is updated for cert-manager controller pod by running the following command:$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager -o yaml
Example output
# ... metadata: name: cert-manager-6e4b4d7d97-zmdnb namespace: cert-manager # ... spec: containers: - args: - --enable-certificate-owner-ref
9.5.4. Overriding CPU and memory limits for the cert-manager components
After installing the cert-manager Operator for Red Hat OpenShift, you can configure the CPU and memory limits from the cert-manager Operator for Red Hat OpenShift API for the cert-manager components such as cert-manager controller, CA injector, and Webhook.
Prerequisites
-
You have access to the OpenShift Container Platform cluster as a user with the
cluster-admin
role. - You have installed version 1.12.0 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
Check that the deployments of the cert-manager controller, CA injector, and Webhook are available by entering the following command:
$ oc get deployment -n cert-manager
Example output
NAME READY UP-TO-DATE AVAILABLE AGE cert-manager 1/1 1 1 53m cert-manager-cainjector 1/1 1 1 53m cert-manager-webhook 1/1 1 1 53m
Before setting the CPU and memory limit, check the existing configuration for the cert-manager controller, CA injector, and Webhook by entering the following command:
$ oc get deployment -n cert-manager -o yaml
Example output
# ... metadata: name: cert-manager namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-controller resources: {} 1 # ... metadata: name: cert-manager-cainjector namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-cainjector resources: {} 2 # ... metadata: name: cert-manager-webhook namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-webhook resources: {} 3 # ...
To configure the CPU and memory limits for the cert-manager controller, CA injector, and Webhook, enter the following command:
$ oc patch certmanager.operator cluster --type=merge -p=" spec: controllerConfig: overrideResources: limits: 1 cpu: 200m 2 memory: 64Mi 3 requests: 4 cpu: 10m 5 memory: 16Mi 6 webhookConfig: overrideResources: limits: 7 cpu: 200m 8 memory: 64Mi 9 requests: 10 cpu: 10m 11 memory: 16Mi 12 cainjectorConfig: overrideResources: limits: 13 cpu: 200m 14 memory: 64Mi 15 requests: 16 cpu: 10m 17 memory: 16Mi 18 "
- 1
- Defines the maximum amount of CPU and memory that a single container in a cert-manager controller pod can request.
- 2 5
- You can specify the CPU limit that a cert-manager controller pod can request. The default value is
10m
. - 3 6
- You can specify the memory limit that a cert-manager controller pod can request. The default value is
32Mi
. - 4
- Defines the amount of CPU and memory set by scheduler for the cert-manager controller pod.
- 7
- Defines the maximum amount of CPU and memory that a single container in a CA injector pod can request.
- 8 11
- You can specify the CPU limit that a CA injector pod can request. The default value is
10m
. - 9 12
- You can specify the memory limit that a CA injector pod can request. The default value is
32Mi
. - 10
- Defines the amount of CPU and memory set by scheduler for the CA injector pod.
- 13
- Defines the maximum amount of CPU and memory Defines the maximum amount of CPU and memory that a single container in a Webhook pod can request.
- 14 17
- You can specify the CPU limit that a Webhook pod can request. The default value is
10m
. - 15 18
- You can specify the memory limit that a Webhook pod can request. The default value is
32Mi
. - 16
- Defines the amount of CPU and memory set by scheduler for the Webhook pod.
Example output
certmanager.operator.openshift.io/cluster patched
Verification
Verify that the CPU and memory limits are updated for the cert-manager components:
$ oc get deployment -n cert-manager -o yaml
Example output
# ... metadata: name: cert-manager namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-controller resources: limits: cpu: 200m memory: 64Mi requests: cpu: 10m memory: 16Mi # ... metadata: name: cert-manager-cainjector namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-cainjector resources: limits: cpu: 200m memory: 64Mi requests: cpu: 10m memory: 16Mi # ... metadata: name: cert-manager-webhook namespace: cert-manager # ... spec: template: spec: containers: - name: cert-manager-webhook resources: limits: cpu: 200m memory: 64Mi requests: cpu: 10m memory: 16Mi # ...
9.6. Authenticating the cert-manager Operator for Red Hat OpenShift
You can authenticate the cert-manager Operator for Red Hat OpenShift on the cluster by configuring the cloud credentials.
9.6.1. Authenticating on AWS
Prerequisites
- You have installed version 1.11.1 or later of the cert-manager Operator for Red Hat OpenShift.
- You have configured the Cloud Credential Operator to operate in mint or passthrough mode.
Procedure
Create a
CredentialsRequest
resource YAML file, for example,sample-credential-request.yaml
, as follows:apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cert-manager namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - action: - "route53:GetChange" effect: Allow resource: "arn:aws:route53:::change/*" - action: - "route53:ChangeResourceRecordSets" - "route53:ListResourceRecordSets" effect: Allow resource: "arn:aws:route53:::hostedzone/*" - action: - "route53:ListHostedZonesByName" effect: Allow resource: "*" secretRef: name: aws-creds namespace: cert-manager serviceAccountNames: - cert-manager
Create a
CredentialsRequest
resource by running the following command:$ oc create -f sample-credential-request.yaml
Update the subscription object for cert-manager Operator for Red Hat OpenShift by running the following command:
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type=merge -p '{"spec":{"config":{"env":[{"name":"CLOUD_CREDENTIALS_SECRET_NAME","value":"aws-creds"}]}}}'
Verification
Get the name of the redeployed cert-manager controller pod by running the following command:
$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 15m39s
Verify that the cert-manager controller pod is updated with AWS credential volumes that are mounted under the path specified in
mountPath
by running the following command:$ oc get -n cert-manager pod/<cert-manager_controller_pod_name> -o yaml
Example output
... spec: containers: - args: ... - mountPath: /.aws name: cloud-credentials ... volumes: ... - name: cloud-credentials secret: ... secretName: aws-creds
9.6.2. Authenticating with AWS Security Token Service
Prerequisites
-
You have extracted and prepared the
ccoctl
binary. - You have configured an OpenShift Container Platform cluster with AWS STS by using the Cloud Credential Operator in manual mode.
Procedure
Create a directory to store a
CredentialsRequest
resource YAML file by running the following command:$ mkdir credentials-request
Create a
CredentialsRequest
resource YAML file under thecredentials-request
directory, such as,sample-credential-request.yaml
, by applying the following yaml:apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cert-manager namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: AWSProviderSpec statementEntries: - action: - "route53:GetChange" effect: Allow resource: "arn:aws:route53:::change/*" - action: - "route53:ChangeResourceRecordSets" - "route53:ListResourceRecordSets" effect: Allow resource: "arn:aws:route53:::hostedzone/*" - action: - "route53:ListHostedZonesByName" effect: Allow resource: "*" secretRef: name: aws-creds namespace: cert-manager serviceAccountNames: - cert-manager
Use the
ccoctl
tool to processCredentialsRequest
objects by running the following command:$ ccoctl aws create-iam-roles \ --name <user_defined_name> --region=<aws_region> \ --credentials-requests-dir=<path_to_credrequests_dir> \ --identity-provider-arn <oidc_provider_arn> --output-dir=<path_to_output_dir>
Example output
2023/05/15 18:10:34 Role arn:aws:iam::XXXXXXXXXXXX:role/<user_defined_name>-cert-manager-aws-creds created 2023/05/15 18:10:34 Saved credentials configuration to: <path_to_output_dir>/manifests/cert-manager-aws-creds-credentials.yaml 2023/05/15 18:10:35 Updated Role policy for Role <user_defined_name>-cert-manager-aws-creds
Copy the
<aws_role_arn>
from the output to use in the next step. For example,"arn:aws:iam::XXXXXXXXXXXX:role/<user_defined_name>-cert-manager-aws-creds"
Add the
eks.amazonaws.com/role-arn="<aws_role_arn>"
annotation to the service account by running the following command:$ oc -n cert-manager annotate serviceaccount cert-manager eks.amazonaws.com/role-arn="<aws_role_arn>"
To create a new pod, delete the existing cert-manager controller pod by running the following command:
$ oc delete pods -l app.kubernetes.io/name=cert-manager -n cert-manager
The AWS credentials are applied to a new cert-manager controller pod within a minute.
Verification
Get the name of the updated cert-manager controller pod by running the following command:
$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 39s
Verify that AWS credentials are updated by running the following command:
$ oc set env -n cert-manager po/<cert_manager_controller_pod_name> --list
Example output
# pods/cert-manager-57f9555c54-vbcpg, container cert-manager-controller # POD_NAMESPACE from field path metadata.namespace AWS_ROLE_ARN=XXXXXXXXXXXX AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
Additional resources
9.6.3. Authenticating on GCP
Prerequisites
- You have installed version 1.11.1 or later of the cert-manager Operator for Red Hat OpenShift.
- You have configured the Cloud Credential Operator to operate in mint or passthrough mode.
Procedure
Create a
CredentialsRequest
resource YAML file, such as,sample-credential-request.yaml
by applying the following yaml:apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cert-manager namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/dns.admin secretRef: name: gcp-credentials namespace: cert-manager serviceAccountNames: - cert-manager
NoteThe
dns.admin
role provides admin privileges to the service account for managing Google Cloud DNS resources. To ensure that the cert-manager runs with the service account that has the least privilege, you can create a custom role with the following permissions:-
dns.resourceRecordSets.*
-
dns.changes.*
-
dns.managedZones.list
-
Create a
CredentialsRequest
resource by running the following command:$ oc create -f sample-credential-request.yaml
Update the subscription object for cert-manager Operator for Red Hat OpenShift by running the following command:
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type=merge -p '{"spec":{"config":{"env":[{"name":"CLOUD_CREDENTIALS_SECRET_NAME","value":"gcp-credentials"}]}}}'
Verification
Get the name of the redeployed cert-manager controller pod by running the following command:
$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 15m39s
Verify that the cert-manager controller pod is updated with GCP credential volumes that are mounted under the path specified in
mountPath
by running the following command:$ oc get -n cert-manager pod/<cert-manager_controller_pod_name> -o yaml
Example output
spec: containers: - args: ... volumeMounts: ... - mountPath: /.config/gcloud name: cloud-credentials .... volumes: ... - name: cloud-credentials secret: ... items: - key: service_account.json path: application_default_credentials.json secretName: gcp-credentials
9.6.4. Authenticating with GCP Workload Identity
Prerequisites
-
You extracted and prepared the
ccoctl
binary. - You have installed version 1.11.1 or later of the cert-manager Operator for Red Hat OpenShift.
- You have configured an OpenShift Container Platform cluster with GCP Workload Identity by using the Cloud Credential Operator in a manual mode.
Procedure
Create a directory to store a
CredentialsRequest
resource YAML file by running the following command:$ mkdir credentials-request
In the
credentials-request
directory, create a YAML file that contains the followingCredentialsRequest
manifest:apiVersion: cloudcredential.openshift.io/v1 kind: CredentialsRequest metadata: name: cert-manager namespace: openshift-cloud-credential-operator spec: providerSpec: apiVersion: cloudcredential.openshift.io/v1 kind: GCPProviderSpec predefinedRoles: - roles/dns.admin secretRef: name: gcp-credentials namespace: cert-manager serviceAccountNames: - cert-manager
NoteThe
dns.admin
role provides admin privileges to the service account for managing Google Cloud DNS resources. To ensure that the cert-manager runs with the service account that has the least privilege, you can create a custom role with the following permissions:-
dns.resourceRecordSets.*
-
dns.changes.*
-
dns.managedZones.list
-
Use the
ccoctl
tool to processCredentialsRequest
objects by running the following command:$ ccoctl gcp create-service-accounts \ --name <user_defined_name> --output-dir=<path_to_output_dir> \ --credentials-requests-dir=<path_to_credrequests_dir> \ --workload-identity-pool <workload_identity_pool> \ --workload-identity-provider <workload_identity_provider> \ --project <gcp_project_id>
Example command
$ ccoctl gcp create-service-accounts \ --name abcde-20230525-4bac2781 --output-dir=/home/outputdir \ --credentials-requests-dir=/home/credentials-requests \ --workload-identity-pool abcde-20230525-4bac2781 \ --workload-identity-provider abcde-20230525-4bac2781 \ --project openshift-gcp-devel
Apply the secrets generated in the manifests directory of your cluster by running the following command:
$ ls <path_to_output_dir>/manifests/*-credentials.yaml | xargs -I{} oc apply -f {}
Update the subscription object for cert-manager Operator for Red Hat OpenShift by running the following command:
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type=merge -p '{"spec":{"config":{"env":[{"name":"CLOUD_CREDENTIALS_SECRET_NAME","value":"gcp-credentials"}]}}}'
Verification
Get the name of the redeployed cert-manager controller pod by running the following command:
$ oc get pods -l app.kubernetes.io/name=cert-manager -n cert-manager
Example output
NAME READY STATUS RESTARTS AGE cert-manager-bd7fbb9fc-wvbbt 1/1 Running 0 15m39s
Verify that the cert-manager controller pod is updated with GCP workload identity credential volumes that are mounted under the path specified in
mountPath
by running the following command:$ oc get -n cert-manager pod/<cert-manager_controller_pod_name> -o yaml
Example output
spec: containers: - args: ... volumeMounts: - mountPath: /var/run/secrets/openshift/serviceaccount name: bound-sa-token ... - mountPath: /.config/gcloud name: cloud-credentials ... volumes: - name: bound-sa-token projected: ... sources: - serviceAccountToken: audience: openshift ... path: token - name: cloud-credentials secret: ... items: - key: service_account.json path: application_default_credentials.json secretName: gcp-credentials
9.7. Configuring an ACME issuer
The cert-manager Operator for Red Hat OpenShift supports using Automated Certificate Management Environment (ACME) CA servers, such as Let’s Encrypt, to issue certificates. Explicit credentials are configured by specifying the secret details in the Issuer
API object. Ambient credentials are extracted from the environment, metadata services, or local files which are not explicitly configured in the Issuer
API object.
The Issuer
object is namespace scoped. It can only issue certificates from the same namespace. You can also use the ClusterIssuer
object to issue certificates across all namespaces in the cluster.
Example YAML file that defines the ClusterIssuer
object
apiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: acme-cluster-issuer spec: acme: ...
By default, you can use the ClusterIssuer
object with ambient credentials. To use the Issuer
object with ambient credentials, you must enable the --issuer-ambient-credentials
setting for the cert-manager controller.
9.7.1. About ACME issuers
The ACME issuer type for the cert-manager Operator for Red Hat OpenShift represents an Automated Certificate Management Environment (ACME) certificate authority (CA) server. ACME CA servers rely on a challenge to verify that a client owns the domain names that the certificate is being requested for. If the challenge is successful, the cert-manager Operator for Red Hat OpenShift can issue the certificate. If the challenge fails, the cert-manager Operator for Red Hat OpenShift does not issue the certificate.
Private DNS zones are not supported with Let’s Encrypt and internet ACME servers.
9.7.1.1. Supported ACME challenges types
The cert-manager Operator for Red Hat OpenShift supports the following challenge types for ACME issuers:
- HTTP-01
With the HTTP-01 challenge type, you provide a computed key at an HTTP URL endpoint in your domain. If the ACME CA server can get the key from the URL, it can validate you as the owner of the domain.
For more information, see HTTP01 in the upstream cert-manager documentation.
HTTP-01 requires that the Let’s Encrypt servers can access the route of the cluster. If an internal or private cluster is behind a proxy, the HTTP-01 validations for certificate issuance fail.
The HTTP-01 challenge is restricted to port 80. For more information, see HTTP-01 challenge (Let’s Encrypt).
- DNS-01
With the DNS-01 challenge type, you provide a computed key at a DNS TXT record. If the ACME CA server can get the key by DNS lookup, it can validate you as the owner of the domain.
For more information, see DNS01 in the upstream cert-manager documentation.
9.7.1.2. Supported DNS-01 providers
The cert-manager Operator for Red Hat OpenShift supports the following DNS-01 providers for ACME issuers:
- Amazon Route 53
Azure DNS
NoteThe cert-manager Operator for Red Hat OpenShift does not support using Microsoft Entra ID pod identities to assign a managed identity to a pod.
- Google Cloud DNS
Webhook
Red Hat tests and supports DNS providers using an external webhook with cert-manager on OpenShift Container Platform. The following DNS providers are tested and supported with OpenShift Container Platform:
NoteUsing a DNS provider that is not listed might work with OpenShift Container Platform, but the provider was not tested by Red Hat and therefore is not supported by Red Hat.
9.7.2. Configuring an ACME issuer to solve HTTP-01 challenges
You can use cert-manager Operator for Red Hat OpenShift to set up an ACME issuer to solve HTTP-01 challenges. This procedure uses Let’s Encrypt as the ACME CA server.
Prerequisites
-
You have access to the cluster as a user with the
cluster-admin
role. -
You have a service that you want to expose. In this procedure, the service is named
sample-workload
.
Procedure
Create an ACME cluster issuer.
Create a YAML file that defines the
ClusterIssuer
object:Example
acme-cluster-issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: ClusterIssuer metadata: name: letsencrypt-staging 1 spec: acme: preferredChain: "" privateKeySecretRef: name: <secret_for_private_key> 2 server: https://acme-staging-v02.api.letsencrypt.org/directory 3 solvers: - http01: ingress: ingressClassName: openshift-default 4
Optional: If you create the object without specifying
ingressClassName
, use the following command to patch the existing ingress:$ oc patch ingress/<ingress-name> --type=merge --patch '{"spec":{"ingressClassName":"openshift-default"}}' -n <namespace>
Create the
ClusterIssuer
object by running the following command:$ oc create -f acme-cluster-issuer.yaml
Create an Ingress to expose the service of the user workload.
Create a YAML file that defines a
Namespace
object:Example
namespace.yaml
fileapiVersion: v1 kind: Namespace metadata: name: my-ingress-namespace 1
- 1
- Specify the namespace for the Ingress.
Create the
Namespace
object by running the following command:$ oc create -f namespace.yaml
Create a YAML file that defines the
Ingress
object:Example
ingress.yaml
fileapiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: sample-ingress 1 namespace: my-ingress-namespace 2 annotations: cert-manager.io/cluster-issuer: letsencrypt-staging 3 acme.cert-manager.io/http01-ingress-class: openshift-default 4 spec: ingressClassName: openshift-default 5 tls: - hosts: - <hostname> 6 secretName: sample-tls 7 rules: - host: <hostname> 8 http: paths: - path: / pathType: Prefix backend: service: name: sample-workload 9 port: number: 80
- 1
- Specify the name of the Ingress.
- 2
- Specify the namespace that you created for the Ingress.
- 3
- Specify the cluster issuer that you created.
- 4
- Specify the Ingress class.
- 5
- Specify the Ingress class.
- 6
- Replace
<hostname>
with the Subject Alternative Name to be associated with the certificate. This name is used to add DNS names to the certificate. - 7
- Specify the secret to store the created certificate in.
- 8
- Replace
<hostname>
with the hostname. You can use the<host_name>.<cluster_ingress_domain>
syntax to take advantage of the*.<cluster_ingress_domain>
wildcard DNS record and serving certificate for the cluster. For example, you might useapps.<cluster_base_domain>
. Otherwise, you must ensure that a DNS record exists for the chosen hostname. - 9
- Specify the name of the service to expose. This example uses a service named
sample-workload
.
Create the
Ingress
object by running the following command:$ oc create -f ingress.yaml
9.7.3. Configuring an ACME issuer by using explicit credentials for AWS Route53
You can use cert-manager Operator for Red Hat OpenShift to set up an Automated Certificate Management Environment (ACME) issuer to solve DNS-01 challenges by using explicit credentials on AWS. This procedure uses Let’s Encrypt as the ACME certificate authority (CA) server and shows how to solve DNS-01 challenges with Amazon Route 53.
Prerequisites
You must provide the explicit
accessKeyID
andsecretAccessKey
credentials. For more information, see Route53 in the upstream cert-manager documentation.NoteYou can use Amazon Route 53 with explicit credentials in an OpenShift Container Platform cluster that is not running on AWS.
Procedure
Optional: Override the nameserver settings for the DNS-01 self check.
This step is required only when the target public-hosted zone overlaps with the cluster’s default private-hosted zone.
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: 1 overrideArgs: - '--dns01-recursive-nameservers-only' 2 - '--dns01-recursive-nameservers=1.1.1.1:53' 3
- 1
- Add the
spec.controllerConfig
section. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the DNS-01 self check. You must use a1.1.1.1:53
value to avoid the public and private zones overlapping.
- Save the file to apply the changes.
Optional: Create a namespace for the issuer:
$ oc new-project <issuer_namespace>
Create a secret to store your AWS credentials in by running the following command:
$ oc create secret generic aws-secret --from-literal=awsSecretAccessKey=<aws_secret_access_key> \ 1 -n my-issuer-namespace
- 1
- Replace
<aws_secret_access_key>
with your AWS secret access key.
Create an issuer:
Create a YAML file that defines the
Issuer
object:Example
issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: Issuer metadata: name: <letsencrypt_staging> 1 namespace: <issuer_namespace> 2 spec: acme: server: https://acme-staging-v02.api.letsencrypt.org/directory 3 email: "<email_address>" 4 privateKeySecretRef: name: <secret_private_key> 5 solvers: - dns01: route53: accessKeyID: <aws_key_id> 6 hostedZoneID: <hosted_zone_id> 7 region: <region_name> 8 secretAccessKeySecretRef: name: "aws-secret" 9 key: "awsSecretAccessKey" 10
- 1
- Provide a name for the issuer.
- 2
- Specify the namespace that you created for the issuer.
- 3
- Specify the URL to access the ACME server’s
directory
endpoint. This example uses the Let’s Encrypt staging environment. - 4
- Replace
<email_address>
with your email address. - 5
- Replace
<secret_private_key>
with the name of the secret to store the ACME account private key in. - 6
- Replace
<aws_key_id>
with your AWS key ID. - 7
- Replace
<hosted_zone_id>
with your hosted zone ID. - 8
- Replace
<region_name>
with the AWS region name. For example,us-east-1
. - 9
- Specify the name of the secret you created.
- 10
- Specify the key in the secret you created that stores your AWS secret access key.
Create the
Issuer
object by running the following command:$ oc create -f issuer.yaml
9.7.4. Configuring an ACME issuer by using ambient credentials on AWS
You can use cert-manager Operator for Red Hat OpenShift to set up an ACME issuer to solve DNS-01 challenges by using ambient credentials on AWS. This procedure uses Let’s Encrypt as the ACME CA server and shows how to solve DNS-01 challenges with Amazon Route 53.
Prerequisites
- If your cluster is configured to use the AWS Security Token Service (STS), you followed the instructions from the Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift for the AWS Security Token Service cluster section.
- If your cluster does not use the AWS STS, you followed the instructions from the Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift on AWS section.
Procedure
Optional: Override the nameserver settings for the DNS-01 self check.
This step is required only when the target public-hosted zone overlaps with the cluster’s default private-hosted zone.
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: 1 overrideArgs: - '--dns01-recursive-nameservers-only' 2 - '--dns01-recursive-nameservers=1.1.1.1:53' 3
- 1
- Add the
spec.controllerConfig
section. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the DNS-01 self check. You must use a1.1.1.1:53
value to avoid the public and private zones overlapping.
- Save the file to apply the changes.
Optional: Create a namespace for the issuer:
$ oc new-project <issuer_namespace>
Modify the
CertManager
resource to add the--issuer-ambient-credentials
argument:$ oc patch certmanager/cluster \ --type=merge \ -p='{"spec":{"controllerConfig":{"overrideArgs":["--issuer-ambient-credentials"]}}}'
Create an issuer:
Create a YAML file that defines the
Issuer
object:Example
issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: Issuer metadata: name: <letsencrypt_staging> 1 namespace: <issuer_namespace> 2 spec: acme: server: https://acme-staging-v02.api.letsencrypt.org/directory 3 email: "<email_address>" 4 privateKeySecretRef: name: <secret_private_key> 5 solvers: - dns01: route53: hostedZoneID: <hosted_zone_id> 6 region: us-east-1
- 1
- Provide a name for the issuer.
- 2
- Specify the namespace that you created for the issuer.
- 3
- Specify the URL to access the ACME server’s
directory
endpoint. This example uses the Let’s Encrypt staging environment. - 4
- Replace
<email_address>
with your email address. - 5
- Replace
<secret_private_key>
with the name of the secret to store the ACME account private key in. - 6
- Replace
<hosted_zone_id>
with your hosted zone ID.
Create the
Issuer
object by running the following command:$ oc create -f issuer.yaml
9.7.5. Configuring an ACME issuer by using explicit credentials for GCP Cloud DNS
You can use the cert-manager Operator for Red Hat OpenShift to set up an ACME issuer to solve DNS-01 challenges by using explicit credentials on GCP. This procedure uses Let’s Encrypt as the ACME CA server and shows how to solve DNS-01 challenges with Google CloudDNS.
Prerequisites
You have set up Google Cloud service account with a desired role for Google CloudDNS. For more information, see Google CloudDNS in the upstream cert-manager documentation.
NoteYou can use Google CloudDNS with explicit credentials in an OpenShift Container Platform cluster that is not running on GCP.
Procedure
Optional: Override the nameserver settings for the DNS-01 self check.
This step is required only when the target public-hosted zone overlaps with the cluster’s default private-hosted zone.
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: 1 overrideArgs: - '--dns01-recursive-nameservers-only' 2 - '--dns01-recursive-nameservers=1.1.1.1:53' 3
- 1
- Add the
spec.controllerConfig
section. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the DNS-01 self check. You must use a1.1.1.1:53
value to avoid the public and private zones overlapping.
- Save the file to apply the changes.
Optional: Create a namespace for the issuer:
$ oc new-project my-issuer-namespace
Create a secret to store your GCP credentials by running the following command:
$ oc create secret generic clouddns-dns01-solver-svc-acct --from-file=service_account.json=<path/to/gcp_service_account.json> -n my-issuer-namespace
Create an issuer:
Create a YAML file that defines the
Issuer
object:Example
issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: Issuer metadata: name: <acme_dns01_clouddns_issuer> 1 namespace: <issuer_namespace> 2 spec: acme: preferredChain: "" privateKeySecretRef: name: <secret_private_key> 3 server: https://acme-staging-v02.api.letsencrypt.org/directory 4 solvers: - dns01: cloudDNS: project: <project_id> 5 serviceAccountSecretRef: name: clouddns-dns01-solver-svc-acct 6 key: service_account.json 7
- 1
- Provide a name for the issuer.
- 2
- Replace
<issuer_namespace>
with your issuer namespace. - 3
- Replace
<secret_private_key>
with the name of the secret to store the ACME account private key in. - 4
- Specify the URL to access the ACME server’s
directory
endpoint. This example uses the Let’s Encrypt staging environment. - 5
- Replace
<project_id>
with the name of the GCP project that contains the Cloud DNS zone. - 6
- Specify the name of the secret you created.
- 7
- Specify the key in the secret you created that stores your GCP secret access key.
Create the
Issuer
object by running the following command:$ oc create -f issuer.yaml
9.7.6. Configuring an ACME issuer by using ambient credentials on GCP
You can use the cert-manager Operator for Red Hat OpenShift to set up an ACME issuer to solve DNS-01 challenges by using ambient credentials on GCP. This procedure uses Let’s Encrypt as the ACME CA server and shows how to solve DNS-01 challenges with Google CloudDNS.
Prerequisites
- If your cluster is configured to use GCP Workload Identity, you followed the instructions from the Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift with GCP Workload Identity section.
- If your cluster does not use GCP Workload Identity, you followed the instructions from the Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift on GCP section.
Procedure
Optional: Override the nameserver settings for the DNS-01 self check.
This step is required only when the target public-hosted zone overlaps with the cluster’s default private-hosted zone.
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: 1 overrideArgs: - '--dns01-recursive-nameservers-only' 2 - '--dns01-recursive-nameservers=1.1.1.1:53' 3
- 1
- Add the
spec.controllerConfig
section. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the DNS-01 self check. You must use a1.1.1.1:53
value to avoid the public and private zones overlapping.
- Save the file to apply the changes.
Optional: Create a namespace for the issuer:
$ oc new-project <issuer_namespace>
Modify the
CertManager
resource to add the--issuer-ambient-credentials
argument:$ oc patch certmanager/cluster \ --type=merge \ -p='{"spec":{"controllerConfig":{"overrideArgs":["--issuer-ambient-credentials"]}}}'
Create an issuer:
Create a YAML file that defines the
Issuer
object:Example
issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: Issuer metadata: name: <acme_dns01_clouddns_issuer> 1 namespace: <issuer_namespace> spec: acme: preferredChain: "" privateKeySecretRef: name: <secret_private_key> 2 server: https://acme-staging-v02.api.letsencrypt.org/directory 3 solvers: - dns01: cloudDNS: project: <gcp_project_id> 4
- 1
- Provide a name for the issuer.
- 2
- Replace
<secret_private_key>
with the name of the secret to store the ACME account private key in. - 3
- Specify the URL to access the ACME server’s
directory
endpoint. This example uses the Let’s Encrypt staging environment. - 4
- Replace
<gcp_project_id>
with the name of the GCP project that contains the Cloud DNS zone.
Create the
Issuer
object by running the following command:$ oc create -f issuer.yaml
9.7.7. Configuring an ACME issuer by using explicit credentials for Microsoft Azure DNS
You can use cert-manager Operator for Red Hat OpenShift to set up an ACME issuer to solve DNS-01 challenges by using explicit credentials on Microsoft Azure. This procedure uses Let’s Encrypt as the ACME CA server and shows how to solve DNS-01 challenges with Azure DNS.
Prerequisites
You have set up a service principal with desired role for Azure DNS. For more information, see Azure DNS in the upstream cert-manager documentation.
NoteYou can follow this procedure for an OpenShift Container Platform cluster that is not running on Microsoft Azure.
Procedure
Optional: Override the nameserver settings for the DNS-01 self check.
This step is required only when the target public-hosted zone overlaps with the cluster’s default private-hosted zone.
Edit the
CertManager
resource by running the following command:$ oc edit certmanager cluster
Add a
spec.controllerConfig
section with the following override arguments:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager metadata: name: cluster ... spec: ... controllerConfig: 1 overrideArgs: - '--dns01-recursive-nameservers-only' 2 - '--dns01-recursive-nameservers=1.1.1.1:53' 3
- 1
- Add the
spec.controllerConfig
section. - 2
- Specify to only use recursive nameservers instead of checking the authoritative nameservers associated with that domain.
- 3
- Provide a comma-separated list of
<host>:<port>
nameservers to query for the DNS-01 self check. You must use a1.1.1.1:53
value to avoid the public and private zones overlapping.
- Save the file to apply the changes.
Optional: Create a namespace for the issuer:
$ oc new-project my-issuer-namespace
Create a secret to store your Azure credentials in by running the following command:
$ oc create secret generic <secret_name> --from-literal=<azure_secret_access_key_name>=<azure_secret_access_key_value> \ 1 2 3 -n my-issuer-namespace
Create an issuer:
Create a YAML file that defines the
Issuer
object:Example
issuer.yaml
fileapiVersion: cert-manager.io/v1 kind: Issuer metadata: name: <acme-dns01-azuredns-issuer> 1 namespace: <issuer_namespace> 2 spec: acme: preferredChain: "" privateKeySecretRef: name: <secret_private_key> 3 server: https://acme-staging-v02.api.letsencrypt.org/directory 4 solvers: - dns01: azureDNS: clientID: <azure_client_id> 5 clientSecretSecretRef: name: <secret_name> 6 key: <azure_secret_access_key_name> 7 subscriptionID: <azure_subscription_id> 8 tenantID: <azure_tenant_id> 9 resourceGroupName: <azure_dns_zone_resource_group> 10 hostedZoneName: <azure_dns_zone> 11 environment: AzurePublicCloud
- 1
- Provide a name for the issuer.
- 2
- Replace
<issuer_namespace>
with your issuer namespace. - 3
- Replace
<secret_private_key>
with the name of the secret to store the ACME account private key in. - 4
- Specify the URL to access the ACME server’s
directory
endpoint. This example uses the Let’s Encrypt staging environment. - 5
- Replace
<azure_client_id>
with your Azure client ID. - 6
- Replace
<secret_name>
with a name of the client secret. - 7
- Replace
<azure_secret_access_key_name>
with the client secret key name. - 8
- Replace
<azure_subscription_id>
with your Azure subscription ID. - 9
- Replace
<azure_tenant_id>
with your Azure tenant ID. - 10
- Replace
<azure_dns_zone_resource_group>
with the name of the Azure DNS zone resource group. - 11
- Replace
<azure_dns_zone>
with the name of Azure DNS zone.
Create the
Issuer
object by running the following command:$ oc create -f issuer.yaml
9.7.8. Additional resources
- Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift for the AWS Security Token Service cluster
- Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift on AWS
- Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift with GCP Workload Identity
- Configuring cloud credentials for the cert-manager Operator for Red Hat OpenShift on GCP
9.8. Configuring certificates with an issuer
By using the cert-manager Operator for Red Hat OpenShift, you can manage certificates, handling tasks such as renewal and issuance, for workloads within the cluster, as well as components interacting externally to the cluster.
9.8.1. Creating certificates for user workloads
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have installed the cert-manager Operator for Red Hat OpenShift.
Procedure
- Create an issuer. For more information, see "Configuring an issuer" in the "Additional resources" section.
Create a certificate:
Create a YAML file, for example,
certificate.yaml
, that defines theCertificate
object:Example
certificate.yaml
fileapiVersion: cert-manager.io/v1 kind: Certificate metadata: name: <tls_cert> 1 namespace: <issuer_namespace> 2 spec: isCA: false commonName: '<common_name>' 3 secretName: <secret_name> 4 dnsNames: - "<domain_name>" 5 issuerRef: name: <issuer_name> 6 kind: Issuer
Create the
Certificate
object by running the following command:$ oc create -f certificate.yaml
Verification
Verify that the certificate is created and ready to use by running the following command:
$ oc get certificate -w -n <issuer_namespace>
Once certificate is in
Ready
status, workloads on your cluster can start using the generated certificate secret.
9.8.2. Creating certificates for the API server
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have installed version 1.13.0 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
- Create an issuer. For more information, see "Configuring an issuer" in the "Additional resources" section.
Create a certificate:
Create a YAML file, for example,
certificate.yaml
, that defines theCertificate
object:Example
certificate.yaml
fileapiVersion: cert-manager.io/v1 kind: Certificate metadata: name: <tls_cert> 1 namespace: openshift-config spec: isCA: false commonName: "api.<cluster_base_domain>" 2 secretName: <secret_name> 3 dnsNames: - "api.<cluster_base_domain>" 4 issuerRef: name: <issuer_name> 5 kind: Issuer
Create the
Certificate
object by running the following command:$ oc create -f certificate.yaml
- Add the API server named certificate. For more information, see "Adding an API server named certificate" section in the "Additional resources" section.
To ensure the certificates are updated, run the oc login
command again after the certificate is created.
Verification
Verify that the certificate is created and ready to use by running the following command:
$ oc get certificate -w -n openshift-config
Once certificate is in
Ready
status, API server on your cluster can start using the generated certificate secret.
9.8.3. Creating certificates for the Ingress Controller
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have installed version 1.13.0 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
- Create an issuer. For more information, see "Configuring an issuer" in the "Additional resources" section.
Create a certificate:
Create a YAML file, for example,
certificate.yaml
, that defines theCertificate
object:Example
certificate.yaml
fileapiVersion: cert-manager.io/v1 kind: Certificate metadata: name: <tls_cert> 1 namespace: openshift-ingress spec: isCA: false commonName: "apps.<cluster_base_domain>" 2 secretName: <secret_name> 3 dnsNames: - "apps.<cluster_base_domain>" 4 - "*.apps.<cluster_base_domain>" 5 issuerRef: name: <issuer_name> 6 kind: Issuer
Create the
Certificate
object by running the following command:$ oc create -f certificate.yaml
- Replace the default ingress certificate. For more information, see "Replacing the default ingress certificate" section in the "Additional resources" section.
Verification
Verify that the certificate is created and ready to use by running the following command:
$ oc get certificate -w -n openshift-ingress
Once certificate is in
Ready
status, Ingress Controller on your cluster can start using the generated certificate secret.
9.8.4. Additional resources
9.9. Securing routes with the cert-manager Operator for Red Hat OpenShift
In the OpenShift Container Platform, the route API is extended to provide a configurable option to reference TLS certificates via secrets. With the Creating a route with externally managed certificate Technology Preview feature enabled, you can minimize errors from manual intervention, streamline the certificate management process, and enable the OpenShift Container Platform router to promptly serve the referenced certificate.
Securing routes with the cert-manager Operator for Red Hat OpenShift is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information about the support scope of Red Hat Technology Preview features, see Technology Preview Features Support Scope.
9.9.1. Configuring certificates to secure routes in your cluster
The following steps demonstrate the process of utilizing the cert-manager Operator for Red Hat OpenShift with the Let’s Encrypt ACME HTTP-01 challenge type to secure the route resources in your OpenShift Container Platform cluster.
Prerequisites
- You have installed version 1.14.0 or later of the cert-manager Operator for Red Hat OpenShift.
-
You have enabled the
RouteExternalCertificate
feature gate. -
You have the
create
andupdate
permissions on theroutes/custom-host
sub-resource. -
You have a
Service
resource that you want to expose.
Procedure
Create a
Route
resource for yourService
resource using edge TLS termination and a custom hostname by running the following command. The hostname will be used while creating aCertificate
resource in the following steps.$ oc create route edge <route_name> \ 1 --service=<service_name> \ 2 --hostname=<hostname> \ 3 --namespace=<namespace> 4
Create an
Issuer
to configure the HTTP-01 solver by running the following command. For other ACME issuer types, see "Configuring ACME an issuer".Example
Issuer.yaml
file$ oc create -f - << EOF apiVersion: cert-manager.io/v1 kind: Issuer metadata: name: letsencrypt-acme namespace: <namespace> 1 spec: acme: server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: letsencrypt-acme-account-key solvers: - http01: ingress: ingressClassName: openshift-default EOF
- 1
- Specify the namespace where the
Issuer
is located. It should be the same as your route’s namespace.
Create a
Certificate
object for the route by running the following command. ThesecretName
specifies the TLS secret that is going to be issued and managed by cert-manager and will also be referenced in your route in the following steps.$ oc create -f - << EOF apiVersion: cert-manager.io/v1 kind: Certificate metadata: name: example-route-cert namespace: <namespace> 1 spec: commonName: <hostname> 2 dnsNames: - <hostname> 3 usages: - server auth issuerRef: kind: Issuer name: letsencrypt-acme secretName: <secret_name> 4 EOF
- 1
- Specify the
namespace
where theCertificate
resource is located. It should be the same as your route’s namespace. - 2
- Specify the certificate’s common name using the hostname of the route.
- 3
- Add the hostname of your route to the certificate’s DNS names.
- 4
- Specify the name of the secret that contains the certificate.
Create a
Role
to provide the router service account permissions to read the referenced secret by using the following command:$ oc create role secret-reader \ --verb=get,list,watch \ --resource=secrets \ --resource-name=<secret_name> \ 1 --namespace=<namespace> 2
Create a
RoleBinding
resource to bind the router service account with the newly createdRole
resource by using the following command:$ oc create rolebinding secret-reader-binding \ --role=secret-reader \ --serviceaccount=openshift-ingress:router \ --namespace=<namespace> 1
- 1
- Specify the namespace where both your secret and route are located.
Update your route’s
.spec.tls.externalCertificate
field to reference the previously created secret and use the certificate issued by cert-manager by using the following command:$ oc patch route <route_name> \ 1 -n <namespace> \ 2 --type=merge \ -p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}' 3
Verification
Verify that the certificate is created and ready to use by running the following command:
$ oc get certificate -n <namespace> 1 $ oc get secret -n <namespace> 2
Verify that the router is using the referenced external certificate by running the following command. The command should return with the status code
200 OK
.$ curl -IsS https://<hostname> 1
- 1
- Specify the hostname of your route.
Verify the server certificate’s
subject
,subjectAltName
andissuer
are all as expected from the curl verbose outputs by running the following command:$ curl -v https://<hostname> 1
- 1
- Specify the hostname of your route.
The route is now successfully secured by the certificate from the referenced secret issued by cert-manager. cert-manager will automatically manage the certificate’s lifecycle.
9.9.2. Additional resources
9.10. Monitoring cert-manager Operator for Red Hat OpenShift
You can expose controller metrics for the cert-manager Operator for Red Hat OpenShift in the format provided by the Prometheus Operator.
9.10.1. Enabling monitoring by using a service monitor for the cert-manager Operator for Red Hat OpenShift
You can enable monitoring and metrics collection for the cert-manager Operator for Red Hat OpenShift by using a service monitor to perform the custom metrics scraping.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - The cert-manager Operator for Red Hat OpenShift is installed.
Procedure
Add the label to enable cluster monitoring by running the following command:
$ oc label namespace cert-manager openshift.io/cluster-monitoring=true
Create a service monitor:
Create a YAML file that defines the
Role
,RoleBinding
, andServiceMonitor
objects:Example
monitoring.yaml
fileapiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: prometheus-k8s namespace: cert-manager rules: - apiGroups: - "" resources: - services - endpoints - pods verbs: - get - list - watch --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: prometheus-k8s namespace: cert-manager roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: prometheus-k8s subjects: - kind: ServiceAccount name: prometheus-k8s namespace: openshift-monitoring --- apiVersion: monitoring.coreos.com/v1 kind: ServiceMonitor metadata: labels: app: cert-manager app.kubernetes.io/component: controller app.kubernetes.io/instance: cert-manager app.kubernetes.io/name: cert-manager name: cert-manager namespace: cert-manager spec: endpoints: - interval: 30s port: tcp-prometheus-servicemonitor scheme: http selector: matchLabels: app.kubernetes.io/component: controller app.kubernetes.io/instance: cert-manager app.kubernetes.io/name: cert-manager
Create the
Role
,RoleBinding
, andServiceMonitor
objects by running the following command:$ oc create -f monitoring.yaml
Additional resources
9.10.2. Querying metrics for the cert-manager Operator for Red Hat OpenShift
After you have enabled monitoring for the cert-manager Operator for Red Hat OpenShift, you can query its metrics by using the OpenShift Container Platform web console.
Prerequisites
-
You have access to the cluster as a user with the
cluster-admin
role. - You have installed the cert-manager Operator for Red Hat OpenShift.
- You have enabled monitoring and metrics collection for the cert-manager Operator for Red Hat OpenShift.
Procedure
-
From the OpenShift Container Platform web console, navigate to Observe
Metrics. Add a query by using one of the following formats:
Specify the endpoints:
{instance="<endpoint>"} 1
- 1
- Replace
<endpoint>
with the value of the endpoint for thecert-manager
service. You can find the endpoint value by running the following command:oc describe service cert-manager -n cert-manager
.
Specify the
tcp-prometheus-servicemonitor
port:{endpoint="tcp-prometheus-servicemonitor"}
9.11. Configuring log levels for cert-manager and the cert-manager Operator for Red Hat OpenShift
To troubleshoot issues with the cert-manager components and the cert-manager Operator for Red Hat OpenShift, you can configure the log level verbosity.
To use different log levels for different cert-manager components, see Customizing cert-manager Operator API fields.
9.11.1. Setting a log level for cert-manager
You can set a log level for cert-manager to determine the verbosity of log messages.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have installed version 1.11.1 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
Edit the
CertManager
resource by running the following command:$ oc edit certmanager.operator cluster
Set the log level value by editing the
spec.logLevel
section:apiVersion: operator.openshift.io/v1alpha1 kind: CertManager ... spec: logLevel: <log_level> 1
- 1
- The valid log level values for the
CertManager
resource areNormal
,Debug
,Trace
, andTraceAll
. To audit logs and perform common operations when there are no issues, setlogLevel
toNormal
. To troubleshoot a minor issue by viewing verbose logs, setlogLevel
toDebug
. To troubleshoot a major issue by viewing more verbose logs, you can setlogLevel
toTrace
. To troubleshoot serious issues, setlogLevel
toTraceAll
. The defaultlogLevel
isNormal
.
NoteTraceAll
generates huge amount of logs. After settinglogLevel
toTraceAll
, you might experience performance issues.Save your changes and quit the text editor to apply your changes.
After applying the changes, the verbosity level for the cert-manager components controller, CA injector, and webhook is updated.
9.11.2. Setting a log level for the cert-manager Operator for Red Hat OpenShift
You can set a log level for the cert-manager Operator for Red Hat OpenShift to determine the verbosity of the operator log messages.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have installed version 1.11.1 or later of the cert-manager Operator for Red Hat OpenShift.
Procedure
Update the subscription object for cert-manager Operator for Red Hat OpenShift to provide the verbosity level for the operator logs by running the following command:
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"OPERATOR_LOG_LEVEL","value":"v"}]}}}' 1
- 1
- Replace
v
with the desired log level number. The valid values forv
can range from1`to `10
. The default value is2
.
Verification
The cert-manager Operator pod is redeployed. Verify that the log level of the cert-manager Operator for Red Hat OpenShift is updated by running the following command:
$ oc set env deploy/cert-manager-operator-controller-manager -n cert-manager-operator --list | grep -e OPERATOR_LOG_LEVEL -e container
Example output
# deployments/cert-manager-operator-controller-manager, container kube-rbac-proxy OPERATOR_LOG_LEVEL=9 # deployments/cert-manager-operator-controller-manager, container cert-manager-operator OPERATOR_LOG_LEVEL=9
Verify that the log level of the cert-manager Operator for Red Hat OpenShift is updated by running the
oc logs
command:$ oc logs deploy/cert-manager-operator-controller-manager -n cert-manager-operator
9.11.3. Additional resources
9.12. Uninstalling the cert-manager Operator for Red Hat OpenShift
You can remove the cert-manager Operator for Red Hat OpenShift from OpenShift Container Platform by uninstalling the Operator and removing its related resources.
9.12.1. Uninstalling the cert-manager Operator for Red Hat OpenShift
You can uninstall the cert-manager Operator for Red Hat OpenShift by using the web console.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have access to the OpenShift Container Platform web console.
- The cert-manager Operator for Red Hat OpenShift is installed.
Procedure
- Log in to the OpenShift Container Platform web console.
Uninstall the cert-manager Operator for Red Hat OpenShift Operator.
-
Navigate to Operators
Installed Operators. - Click the Options menu next to the cert-manager Operator for Red Hat OpenShift entry and click Uninstall Operator.
- In the confirmation dialog, click Uninstall.
-
Navigate to Operators
9.12.2. Removing cert-manager Operator for Red Hat OpenShift resources
Once you have uninstalled the cert-manager Operator for Red Hat OpenShift, you have the option to eliminate its associated resources from your cluster.
Prerequisites
-
You have access to the cluster with
cluster-admin
privileges. - You have access to the OpenShift Container Platform web console.
Procedure
- Log in to the OpenShift Container Platform web console.
Remove the deployments of the cert-manager components, such as
cert-manager
,cainjector
, andwebhook
, present in thecert-manager
namespace.- Click the Project drop-down menu to see a list of all available projects, and select the cert-manager project.
-
Navigate to Workloads
Deployments. - Select the deployment that you want to delete.
- Click the Actions drop-down menu, and select Delete Deployment to see a confirmation dialog box.
- Click Delete to delete the deployment.
Alternatively, delete deployments of the cert-manager components such as
cert-manager
,cainjector
andwebhook
present in thecert-manager
namespace by using the command-line interface (CLI).$ oc delete deployment -n cert-manager -l app.kubernetes.io/instance=cert-manager
Optional: Remove the custom resource definitions (CRDs) that were installed by the cert-manager Operator for Red Hat OpenShift:
-
Navigate to Administration
CustomResourceDefinitions. -
Enter
certmanager
in the Name field to filter the CRDs. Click the Options menu next to each of the following CRDs, and select Delete Custom Resource Definition:
-
Certificate
-
CertificateRequest
-
CertManager
(operator.openshift.io
) -
Challenge
-
ClusterIssuer
-
Issuer
-
Order
-
-
Navigate to Administration
Optional: Remove the
cert-manager-operator
namespace.-
Navigate to Administration
Namespaces. - Click the Options menu next to the cert-manager-operator and select Delete Namespace.
-
In the confirmation dialog, enter
cert-manager-operator
in the field and click Delete.
-
Navigate to Administration