openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Code Issues Releases Activity

Merge pull request #105190 from openshift-cherrypick-robot/cherry-pick-104809-to-enterprise-4.21

Browse Source 
[enterprise-4.21] OSDOCS#17173: CQA 2.0 cert-manager Operator
This commit is contained in:
Servesha Dudhgaonkar
2026-01-22 14:27:49 +05:30
committed by GitHub
parent 80242a4343 84120d60ea
commit f4e0abf1a5
65 changed files with 542 additions and 396 deletions
Download Patch File Download Diff File Expand all files Collapse all files

3
modules/cert-manager-about.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-about_{context}"]
= About the {cert-manager-operator}
The link:https://cert-manager.io/[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} provides a supported way to integrate cert-manager into your {product-title} cluster.
[role="_abstract"]
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} provides a supported way to integrate cert-manager into your {product-title} cluster.
The {cert-manager-operator} provides the following features:

3
modules/cert-manager-acme-about.adoc
View File

@@ -6,9 +6,10 @@
[id="cert-manager-acme-about_{context}"]
= About ACME issuers
[role="_abstract"]
The ACME issuer type for the {cert-manager-operator} 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} can issue the certificate. If the challenge fails, the {cert-manager-operator} does not issue the certificate.
[NOTE]
====
Private DNS zones are not supported with _Let’s Encrypt_ and internet ACME servers.
====
====

3
modules/cert-manager-acme-challenges-types.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-acme-challenges-types_{context}"]
= Supported ACME challenges types
[role="_abstract"]
To validate domain ownership with ACME issuers, you can use the challenge types supported by the {cert-manager-operator}.
The {cert-manager-operator} 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.

5
modules/cert-manager-acme-dns-providers.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-acme-dns-providers_{context}"]
= Supported DNS-01 providers
[role="_abstract"]
To configure DNS-01 challenges for ACME issuers, you can validate domain ownership by integrating with supported services, such as Amazon Route 53, Azure DNS, and Google Cloud DNS, or by using Webhooks.
The {cert-manager-operator} supports the following DNS-01 providers for ACME issuers:
* Amazon Route 53
@@ -27,4 +30,4 @@ Red Hat tests and supports DNS providers using an external webhook with cert-man
====
Using a DNS provider that is not listed might work with {product-title}, but the provider was not tested by Red Hat and therefore is not supported by Red Hat.
====
--
--

46
modules/cert-manager-acme-dns01-ambient-aws.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-dns01-ambient-aws_{context}"]
= Configuring an ACME issuer by using ambient credentials on AWS
[role="_abstract"]
You can use {cert-manager-operator} 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
@@ -15,7 +16,7 @@ You can use {cert-manager-operator} to set up an ACME issuer to solve DNS-01 cha
.Procedure
. Optional: Override the nameserver settings for the DNS-01 self check.
. Optional: Override the name server 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.
@@ -37,14 +38,16 @@ metadata:
...
spec:
...
controllerConfig: <1>
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers-only' <2>
- '--dns01-recursive-nameservers=1.1.1.1:53' <3>
- '--dns01-recursive-nameservers-only'
- '--dns01-recursive-nameservers=1.1.1.1:53'
----
<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 a `1.1.1.1:53` value to avoid the public and private zones overlapping.
+
where:
+
`--dns01-recursive-nameservers-only`:: Specifies recursive name servers instead of checking the authoritative name servers associated with that domain.
`--dns01-recursive-nameservers=1.1.1.1:53`:: Specifies a comma-separated list of `<host>:<port>` name servers to query for the DNS-01 self check. You must use a `1.1.1.1:53` value to avoid the public and private zones overlapping.
.. Save the file to apply the changes.
@@ -74,30 +77,33 @@ $ oc patch certmanager/cluster \
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: <letsencrypt_staging> <1>
namespace: <issuer_namespace> <2>
name: <issuer_name>
namespace: <issuer_namespace>
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory <3>
email: "<email_address>" <4>
server: <server>
email: "<email_address>"
privateKeySecretRef:
name: <secret_private_key> <5>
name: <secret_private_key>
solvers:
- dns01:
route53:
hostedZoneID: <hosted_zone_id> <6>
hostedZoneID: <hosted_zone_id>
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.
+
where:
+
`<issuer_name>`:: Specifies a name for the issuer.
`<issuer_namespace>`:: Specifies the namespace that you created for the issuer.
`<server>`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<email_address>`:: Specifies your email address.
`<secret_private_key>`:: Specifies the name of the secret to store the ACME account private key in.
`<hosted_zone_id>`:: Specifies your hosted zone ID.
.. Create the `Issuer` object by running the following command:
+
[source,terminal]
----
$ oc create -f issuer.yaml
----
----

38
modules/cert-manager-acme-dns01-ambient-gcp.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-dns01-ambient-gcp_{context}"]
= Configuring an ACME issuer by using ambient credentials on {gcp-short}
[role="_abstract"]
You can use the {cert-manager-operator} to set up an ACME issuer to solve DNS-01 challenges by using ambient credentials on {gcp-short}. This procedure uses _Let's Encrypt_ as the ACME CA server and shows how to solve DNS-01 challenges with {gcp-full} DNS.
.Prerequisites
@@ -15,7 +16,7 @@ You can use the {cert-manager-operator} to set up an ACME issuer to solve DNS-01
.Procedure
. Optional: Override the nameserver settings for the DNS-01 self check.
. Optional: Override the name server 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.
@@ -37,14 +38,16 @@ metadata:
...
spec:
...
controllerConfig: <1>
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers-only' <2>
- '--dns01-recursive-nameservers=1.1.1.1:53' <3>
- '--dns01-recursive-nameservers-only'
- '--dns01-recursive-nameservers=1.1.1.1:53'
----
<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 a `1.1.1.1:53` value to avoid the public and private zones overlapping.
+
where:
+
`--dns01-recursive-nameservers-only`:: Specifies recursive name servers instead of checking the authoritative name servers associated with that domain.
`--dns01-recursive-nameservers=1.1.1.1:53`:: Specifies a comma-separated list of `<host>:<port>` name servers to query for the DNS-01 self check. You must use a `1.1.1.1:53` value to avoid the public and private zones overlapping.
.. Save the file to apply the changes.
@@ -74,27 +77,30 @@ $ oc patch certmanager/cluster \
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: <acme_dns01_clouddns_issuer> <1>
name: <issuer_name>
namespace: <issuer_namespace>
spec:
acme:
preferredChain: ""
privateKeySecretRef:
name: <secret_private_key> <2>
server: https://acme-staging-v02.api.letsencrypt.org/directory <3>
name: <secret_private_key>
server: <server>
solvers:
- dns01:
cloudDNS:
project: <gcp_project_id> <4>
project: <gcp_project_id>
----
<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-short} project that contains the Cloud DNS zone.
+
where:
+
`<issuer_name>`:: Specifies a name for the issuer.
`<secret_private_key>`:: Specifies the name of the secret to store the ACME account private key in.
`<server>`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<gcp_project_id>`:: Specifies the name of the {gcp-short} project that contains the Cloud DNS zone.
.. Create the `Issuer` object by running the following command:
+
[source,terminal]
----
$ oc create -f issuer.yaml
----
----

69
modules/cert-manager-acme-dns01-explicit-aws.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-dns01-explicit-aws_{context}"]
= Configuring an ACME issuer by using explicit credentials for AWS Route53
[role="_abstract"]
You can use {cert-manager-operator} 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
@@ -19,7 +20,7 @@ You can use Amazon Route 53 with explicit credentials in an {product-title} clus
.Procedure
. Optional: Override the nameserver settings for the DNS-01 self check.
. Optional: Override the name server 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.
@@ -41,14 +42,16 @@ metadata:
...
spec:
...
controllerConfig: <1>
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers-only' <2>
- '--dns01-recursive-nameservers=1.1.1.1:53' <3>
- '--dns01-recursive-nameservers-only'
- '--dns01-recursive-nameservers=1.1.1.1:53'
----
<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 a `1.1.1.1:53` value to avoid the public and private zones overlapping.
+
where:
+
`--dns01-recursive-nameservers-only`:: Specifies recursive name servers instead of checking the authoritative name servers associated with that domain.
`--dns01-recursive-nameservers=1.1.1.1:53`:: Specifies a comma-separated list of `<host>:<port>` names servers to query for the DNS-01 self check. You must use a `1.1.1.1:53` value to avoid the public and private zones overlapping.
.. Save the file to apply the changes.
@@ -63,10 +66,11 @@ $ oc new-project <issuer_namespace>
+
[source,terminal]
----
$ oc create secret generic aws-secret --from-literal=awsSecretAccessKey=<aws_secret_access_key> \ <1>
-n my-issuer-namespace
$ oc create secret -n my-issuer-namespace generic aws-secret \
--from-literal=awsSecretAccessKey=<aws_secret_access_key>
----
<1> Replace `<aws_secret_access_key>` with your AWS secret access key.
+
Replace `<aws_secret_access_key>` with your AWS secret access key.
. Create an issuer:
@@ -78,38 +82,41 @@ $ oc create secret generic aws-secret --from-literal=awsSecretAccessKey=<aws_sec
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: <letsencrypt_staging> <1>
namespace: <issuer_namespace> <2>
name: <issuer_name>
namespace: <issuer_namespace>
spec:
acme:
server: https://acme-staging-v02.api.letsencrypt.org/directory <3>
email: "<email_address>" <4>
server: <server>
email: "<email_address>"
privateKeySecretRef:
name: <secret_private_key> <5>
name: <secret_private_key>
solvers:
- dns01:
route53:
accessKeyID: <aws_key_id> <6>
hostedZoneID: <hosted_zone_id> <7>
region: <region_name> <8>
accessKeyID: <aws_key_id>
hostedZoneID: <hosted_zone_id>
region: <region_name>
secretAccessKeySecretRef:
name: "aws-secret" <9>
key: "awsSecretAccessKey" <10>
name: "<aws_secret>"
key: "<aws_secret_access_key>"
----
<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.
+
where:
+
`<issuer_name>`:: Specifies a name for the issuer.
`<issuer_namespace>`:: Specifies the namespace that you created for the issuer.
`server`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<email_address>`:: Specifies your email address.
`<secret_private_key>`:: Specifies the name of the secret to store the ACME account private key in.
`<aws_key_id>`:: Specifies your AWS key ID.
`<hosted_zone_id>`:: Specifies your hosted zone ID.
`<region_name>`:: Specifies the AWS region name. For example, `us-east-1`.
`<aws_secret>`:: Specifies the name of the secret you created.
`<aws_secret_access_key>`:: Specifies the key in the secret you created that stores your AWS secret access key.
.. Create the `Issuer` object by running the following command:
+
[source,terminal]
----
$ oc create -f issuer.yaml
----
----

76
modules/cert-manager-acme-dns01-explicit-azure.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-dns01-explicit-azure_{context}"]
= Configuring an ACME issuer by using explicit credentials for Microsoft Azure DNS
[role="_abstract"]
You can use {cert-manager-operator} 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
@@ -41,14 +42,16 @@ metadata:
...
spec:
...
controllerConfig: <1>
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers-only' <2>
- '--dns01-recursive-nameservers=1.1.1.1:53' <3>
- '--dns01-recursive-nameservers-only'
- '--dns01-recursive-nameservers=1.1.1.1:53'
----
<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 a `1.1.1.1:53` value to avoid the public and private zones overlapping.
+
where:
+
`--dns01-recursive-nameservers-only`:: Specifies recursive name servers instead of checking the authoritative name servers associated with that domain.
`--dns01-recursive-nameservers=1.1.1.1:53`:: Specifies a comma-separated list of `<host>:<port>` name servers to query for the DNS-01 self check. You must use a `1.1.1.1:53` value to avoid the public and private zones overlapping.
.. Save the file to apply the changes.
@@ -63,59 +66,62 @@ $ oc new-project my-issuer-namespace
+
[source,terminal]
----
$ oc create secret generic <secret_name> --from-literal=<azure_secret_access_key_name>=<azure_secret_access_key_value> \ <1> <2> <3>
$ oc create secret generic <secret_name> --from-literal=<azure_secret_access_key_name>=<azure_secret_access_key_value> \
-n my-issuer-namespace
----
<1> Replace `<secret_name>` with your secret name.
<2> Replace `<azure_secret_access_key_name>` with your Azure secret access key name.
<3> Replace `<azure_secret_access_key_value>` with your Azure secret key.
+
* Replace `<secret_name>` with your secret name.
* Replace `<azure_secret_access_key_name>` with your Azure secret access key name.
* Replace `<azure_secret_access_key_value>` with your Azure secret key.
. Create an issuer:
.. Create a YAML file that defines the `Issuer` object:
.. Create a YAML file, for example, `issuer.yaml`, that defines the `Issuer` object:
+
.Example `issuer.yaml` file
[source,yaml]
----
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: <acme-dns01-azuredns-issuer> <1>
namespace: <issuer_namespace> <2>
name: <acme-dns01-azuredns-issuer>
namespace: <issuer_namespace>
spec:
acme:
preferredChain: ""
privateKeySecretRef:
name: <secret_private_key> <3>
server: https://acme-staging-v02.api.letsencrypt.org/directory <4>
name: <secret_private_key>
server: <server>
solvers:
- dns01:
azureDNS:
clientID: <azure_client_id> <5>
clientID: <azure_client_id>
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>
name: <secret_name>
key: <azure_secret_access_key_name>
subscriptionID: <azure_subscription_id>
tenantID: <azure_tenant_id>
resourceGroupName: <azure_dns_zone_resource_group>
hostedZoneName: <azure_dns_zone>
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.
+
where:
+
`<acme-dns01-azuredns-issuer>`:: Specifies a name for the issuer.
`<issuer_namespace>`:: Specifies your issuer namespace.
`<secret_private_key>`:: Specifies the name of the secret to store the ACME account private key in.
`<server>`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<azure_client_id>`:: Specifies your Azure client ID.
`<secret_name>`:: Specifies a name of the client secret.
`<azure_secret_access_key_name>`:: Specifies the client secret key name.
`<azure_subscription_id>`:: Specifies your Azure subscription ID.
`<azure_tenant_id>`:: Specifies your Azure tenant ID.
`<azure_dns_zone_resource_group>`:: Specifies the name of the Azure DNS zone resource group.
`<azure_dns_zone>`:: Specifies the name of Azure DNS zone.
.. Create the `Issuer` object by running the following command:
+
[source,terminal]
----
$ oc create -f issuer.yaml
----
----

53
modules/cert-manager-acme-dns01-explicit-gcp.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-dns01-explicit-gcp_{context}"]
= Configuring an ACME issuer by using explicit credentials for {gcp-full} DNS
[role="_abstract"]
You can use the {cert-manager-operator} to set up an ACME issuer to solve DNS-01 challenges by using explicit credentials on {gcp-short}. This procedure uses _Let's Encrypt_ as the ACME CA server and shows how to solve DNS-01 challenges with {gcp-full} DNS.
.Prerequisites
@@ -19,7 +20,7 @@ You can use {gcp-full} DNS with explicit credentials in an {product-title} clust
.Procedure
. Optional: Override the nameserver settings for the DNS-01 self check.
. Optional: Override the name server 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.
@@ -41,14 +42,16 @@ metadata:
...
spec:
...
controllerConfig: <1>
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers-only' <2>
- '--dns01-recursive-nameservers=1.1.1.1:53' <3>
- '--dns01-recursive-nameservers-only'
- '--dns01-recursive-nameservers=1.1.1.1:53'
----
<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 a `1.1.1.1:53` value to avoid the public and private zones overlapping.
+
where:
+
`--dns01-recursive-nameservers-only`:: Specifies recursive name servers instead of checking the authoritative name servers associated with that domain.
`--dns01-recursive-nameservers=1.1.1.1:53`:: Specifies a comma-separated list of `<host>:<port>` name servers to query for the DNS-01 self check. You must use a `1.1.1.1:53` value to avoid the public and private zones overlapping.
.. Save the file to apply the changes.
@@ -68,41 +71,43 @@ $ oc create secret generic clouddns-dns01-solver-svc-acct --from-file=service_ac
. Create an issuer:
.. Create a YAML file that defines the `Issuer` object:
.. Create a YAML file, for example, `issuer.yaml`, that defines the `Issuer` object:
+
.Example `issuer.yaml` file
[source,yaml]
----
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: <acme_dns01_clouddns_issuer> <1>
namespace: <issuer_namespace> <2>
name: <acme_dns01_clouddns_issuer>
namespace: <issuer_namespace>
spec:
acme:
preferredChain: ""
privateKeySecretRef:
name: <secret_private_key> <3>
server: https://acme-staging-v02.api.letsencrypt.org/directory <4>
name: <secret_private_key>
server: <server>
solvers:
- dns01:
cloudDNS:
project: <project_id> <5>
project: <project_id>
serviceAccountSecretRef:
name: clouddns-dns01-solver-svc-acct <6>
key: service_account.json <7>
name: <secret>
key: <service_account.json>
----
<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-short} 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-short} secret access key.
+
where:
+
`<acme_dns01_clouddns_issuer>`:: Specifies a name for the issuer.
`<issuer_namespace>`:: Specifies your issuer namespace.
`<secret_private_key>`:: Specifies the name of the secret to store the ACME account private key in.
`<server>`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<project_id>`:: Specifies the name of the {gcp-short} project that contains the Cloud DNS zone.
`<secret>`:: Specifies the name of the secret you created.
`<service_account.json>`:: Specifies the key in the secret you created that stores your {gcp-short} secret access key.
.. Create the `Issuer` object by running the following command:
+
[source,terminal]
----
$ oc create -f issuer.yaml
----
----

69
modules/cert-manager-acme-http01.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-acme-http01_{context}"]
= Configuring an ACME issuer to solve HTTP-01 challenges
[role="_abstract"]
You can use {cert-manager-operator} to set up an ACME issuer to solve HTTP-01 challenges. This procedure uses _Let's Encrypt_ as the ACME CA server.
.Prerequisites
@@ -17,30 +18,32 @@ You can use {cert-manager-operator} to set up an ACME issuer to solve HTTP-01 ch
. Create an ACME cluster issuer.
.. Create a YAML file that defines the `ClusterIssuer` object:
.. Create a YAML file, `acme-cluster-issuer.yaml`, that defines the `ClusterIssuer` object:
+
.Example `acme-cluster-issuer.yaml` file
[source,yaml]
----
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-staging <1>
name: <cluster_issuer_name>
spec:
acme:
preferredChain: ""
privateKeySecretRef:
name: <secret_for_private_key> <2>
server: https://acme-staging-v02.api.letsencrypt.org/directory <3>
name: <secret_for_private_key>
server: <url>
solvers:
- http01:
ingress:
ingressClassName: openshift-default <4>
ingressClassName: <ingress_class_name>
----
<1> Provide a name for the cluster issuer.
<2> Replace `<secret_private_key>` with the name of 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> Specify the Ingress class.
+
where:
+
`<cluster_issuer_name>`:: Specifies a name for the cluster issuer.
`<secret_for_private_key>`:: Specifies the name of secret to store the ACME account private key in.
`<url>`:: Specifies the URL to access the ACME server's `directory` endpoint. This example uses the _Let's Encrypt_ staging environment.
`<ingress_class_name>`:: Specifies the Ingress class, for example, `openshift-default`.
.. Optional: If you create the object without specifying `ingressClassName`, use the following command to patch the existing ingress:
+
@@ -58,17 +61,17 @@ $ 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:
.. Create a YAML file, for example, `namespace.yaml`, that defines a `Namespace` object:
+
.Example `namespace.yaml` file
[source,yaml]
----
apiVersion: v1
kind: Namespace
metadata:
name: my-ingress-namespace <1>
name: <ingress_namespace>
----
<1> Specify the namespace for the Ingress.
+
Replace `<ingress_namespace>` with the namespace for the Ingress.
.. Create the `Namespace` object by running the following command:
+
@@ -77,44 +80,46 @@ metadata:
$ oc create -f namespace.yaml
----
.. Create a YAML file that defines the `Ingress` object:
.. Create a YAML file, for example, `ingress.yaml`, that defines the `Ingress` object:
+
.Example `ingress.yaml` file
[source,yaml]
----
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: sample-ingress <1>
namespace: my-ingress-namespace <2>
name: <ingress_name>
namespace: <ingress_namespace>
annotations:
cert-manager.io/cluster-issuer: letsencrypt-staging <3>
cert-manager.io/cluster-issuer: <cluster_issuer_name>
spec:
ingressClassName: openshift-default <4>
ingressClassName: <ingress_class_name>
tls:
- hosts:
- <hostname> <5>
secretName: sample-tls <6>
- <tls_hostname>
secretName: <secret_name>
rules:
- host: <hostname> <7>
- host: <hostname>
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: sample-workload <8>
name: <service_name>
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> Replace `<hostname>` with the Subject Alternative Name (SAN) to be associated with the certificate. This name is used to add DNS names to the certificate.
<6> Specify the secret that stores the certificate.
<7> 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 use `apps.<cluster_base_domain>`. Otherwise, you must ensure that a DNS record exists for the chosen hostname.
<8> Specify the name of the service to expose. This example uses a service named `sample-workload`.
+
where:
+
`<ingress_name>`:: Specifies the name of the Ingress.
`<ingress_namespace>`:: Specifies the namespace that you created for the Ingress.
`<cluster_issuer_name>`:: Specifies the cluster issuer that you created.
`<ingress_class_name>`:: Specifies the Ingress class name.
`<tls_hostname>`:: Specifies the Subject Alternative Name (SAN) to be associated with the certificate. This name is used to add DNS names to the certificate.
`<secret_name>`:: Specifies the secret that stores the certificate.
`<hostname>`:: Specifies the host name. 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 use `apps.<cluster_base_domain>`. Otherwise, you must ensure that a DNS record exists for the chosen hostname.
`<service_name>`:: Specifies the name of the service to expose. This example uses a service named `sample-workload`.
.. Create the `Ingress` object by running the following command:
+

31
modules/cert-manager-certificate-api-server.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-certificate-api-server_{context}"]
= Creating certificates for the API server
[role="_abstract"]
To secure interactions with the cluster control plane, create TLS certificates for the API server by using the {cert-manager-operator}.
.Prerequisites
* You have access to the cluster with `cluster-admin` privileges.
@@ -19,30 +22,30 @@
.. Create a YAML file, for example, `certificate.yaml`, that defines the `Certificate` object:
+
.Example `certificate.yaml` file
+
[source, yaml]
----
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: <tls_cert> #<1>
name: <tls_cert>
namespace: openshift-config
spec:
isCA: false
commonName: "api.<cluster_base_domain>" #<2>
secretName: <secret_name> #<3>
commonName: "api.<cluster_base_domain>"
secretName: <secret_name>
dnsNames:
- "api.<cluster_base_domain>" #<4>
- "api.<cluster_base_domain>"
issuerRef:
name: <issuer_name> #<5>
name: <issuer_name>
kind: Issuer
----
<1> Provide a name for the certificate.
<2> Specify the common name (CN).
<3> Specify the name of the secret to create that contains the certificate.
<4> Specify the DNS name of the API server.
<5> Specify the name of the issuer.
+
where:
+
`<tls_cert>`:: Specifies a name for the certificate.
`<cluster_base_domain>`:: Specifies the common name (CN).
`<secret_name>`:: Specifies the name of the secret to create that contains the certificate.
`<issuer_name>`:: Specifies the name of the issuer.
.. Create the `Certificate` object by running the following command:
+
@@ -52,7 +55,7 @@ $ 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.
+
[NOTE]
====
To ensure the certificates are updated, run the `oc login` command again after the certificate is created.
@@ -67,4 +70,4 @@ To ensure the certificates are updated, run the `oc login` command again after t
$ 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.
Once certificate is in `Ready` status, API server on your cluster can start using the generated certificate secret.

34
modules/cert-manager-certificate-mgmt.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-certificate-mgmt_{context}"]
= Creating certificates for user workloads
[role="_abstract"]
To secure communications for your applications, create and manage TLS certificates for your workloads by using the {cert-manager-operator}
.Prerequisites
* You have access to the cluster with `cluster-admin` privileges.
@@ -19,31 +22,32 @@
.. Create a YAML file, for example, `certificate.yaml`, that defines the `Certificate` object:
+
.Example `certificate.yaml` file
+
[source, yaml]
----
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: <tls_cert> #<1>
namespace: <issuer_namespace> #<2>
name: <tls_cert>
namespace: <issuer_namespace>
spec:
isCA: false
commonName: '<common_name>' #<3>
secretName: <secret_name> #<4>
commonName: '<common_name>'
secretName: <secret_name>
dnsNames:
- "<domain_name>" #<5>
- "<domain_name>"
issuerRef:
name: <issuer_name> #<6>
name: <issuer_name>
kind: Issuer
----
<1> Provide a name for the certificate.
<2> Specify the namespace of the issuer.
<3> Specify the common name (CN).
<4> Specify the name of the secret to create that contains the certificate.
<5> Specify the domain name.
<6> Specify the name of the issuer.
+
where:
+
`<tls_cert>`:: Specifies a name for the certificate.
`<issuer_namespace>`:: Specifies the namespace of the issuer.
`<common_name>`:: Specifies the common name (CN).
`<secret_name>`:: Specifies the name of the secret to create that contains the certificate.
`<domain_name>`:: Specifies the domain name.
`<issuer_name>`:: Specifies the name of the issuer.
.. Create the `Certificate` object by running the following command:
+
@@ -55,7 +59,7 @@ $ oc create -f certificate.yaml
.Verification
* Verify that the certificate is created and ready to use by running the following command:
+
+
[source, terminal]
----
$ oc get certificate -w -n <issuer_namespace>

18
modules/cert-manager-config-metrics-collection.adoc
View File

@@ -6,12 +6,13 @@
[id="cert-manager-config-metrics-collection_{context}"]
= Configuring metrics collection for the istio-csr operand
The istio-csr operand exposes metrics by default on port `9402` at the `/metrics` service endpoint. You can configure metrics collection for the operand by creating a `ServiceMonitor` custom resource (CR), which enables the Prometheus Operator to collect custom metrics. For more information, see "Configuring user workload monitoring".
[role="_abstract"]
The `istio-csr` operand exposes metrics by default on port `9402` at the `/metrics` service endpoint. You can configure metrics collection for the operand by creating a `ServiceMonitor` custom resource (CR), which enables the Prometheus Operator to collect custom metrics. For more information, see "Configuring user workload monitoring".
.Prerequisites
* You have access to the cluster with `cluster-admin` privileges.
* You have installed the {cert-manager-operator}.
* You have access to the cluster with `cluster-admin` privileges.
* You have installed the {cert-manager-operator}.
* You have enabled user workload monitoring.
.Procedure
@@ -29,7 +30,7 @@ metadata:
app.kubernetes.io/instance: cert-manager-istio-csr
app.kubernetes.io/name: cert-manager-istio-csr
name: cert-manager-istio-csr
namespace: <istio_csr_project_name> <1>
namespace: <istio_csr_project_name>
spec:
endpoints:
- honorLabels: false
@@ -39,14 +40,15 @@ spec:
targetPort: 9402
namespaceSelector:
matchNames:
- <istio_csr_project_name> <1>
- <istio_csr_project_name>
selector:
matchLabels:
app: cert-manager-istio-csr
app.kubernetes.io/instance: cert-manager-istio-csr
app.kubernetes.io/name: cert-manager-istio-csr
----
<1> Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
+
Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Create the `ServiceMonitor` CR by running the following command:
+
@@ -54,7 +56,7 @@ spec:
----
$ oc apply -f servicemonitor-istio-csr.yaml
----
+
After the `ServiceMonitor` CR is created, the user workload Prometheus instance starts collecting metrics from the istio-csr operand. The collected metrics are labeled with `job="cert-manager-istio-csr"`.
.Verification
@@ -62,4 +64,4 @@ After the `ServiceMonitor` CR is created, the user workload Prometheus instance
. Log in to the {product-title} web console.
. Click *Observe* -> *Targets*.
. In the **Label filter** field, enter the `service=cert-manager-istio-csr` label to filter the metrics targets.
. Confirm that the *Status* column shows *Up* for the `cert-manager-istio-csr` target.
. Confirm that the *Status* column shows *Up* for the `cert-manager-istio-csr` target.

5
modules/cert-manager-configure-cloud-credentials-aws-non-sts.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-configure-cloud-credentials-aws-non-sts_{context}"]
= Authenticating on AWS
[role="_abstract"]
To securely access AWS resources from your applications, authenticate your workloads on AWS by using the {cert-manager-operator}.
.Prerequisites
* You have installed version 1.11.1 or later of the {cert-manager-operator}.
@@ -101,4 +104,4 @@ spec:
secret:
...
secretName: aws-creds
----
----

5
modules/cert-manager-configure-cloud-credentials-aws-sts.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-configure-cloud-credentials-aws-sts_{context}"]
= Authenticating with AWS Security Token Service
[role="_abstract"]
To securely access AWS resources from your applications without managing long-lived keys, authenticate your workloads by using the AWS Security Token Service (STS).
.Prerequisites
* You have extracted and prepared the `ccoctl` binary.
@@ -120,4 +123,4 @@ $ oc set env -n cert-manager po/<cert_manager_controller_pod_name> --list
# POD_NAMESPACE from field path metadata.namespace
AWS_ROLE_ARN=XXXXXXXXXXXX
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token
----
----

5
modules/cert-manager-configure-cloud-credentials-gcp-non-sts.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-configure-cloud-credentials-gcp-non-sts_{context}"]
= Authenticating on {gcp-short}
[role="_abstract"]
To securely access {gcp-first} resources, authenticate your workloads on {gcp-short} by using the {cert-manager-operator}.
.Prerequisites
* You have installed version 1.11.1 or later of the {cert-manager-operator}.
@@ -102,4 +105,4 @@ spec:
- key: service_account.json
path: application_default_credentials.json
secretName: gcp-credentials
----
----

5
modules/cert-manager-configure-cloud-credentials-gcp-sts.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-configure-cloud-credentials-gcp-sts_{context}"]
= Authenticating with {gcp-short} Workload Identity
[role="_abstract"]
To securely access {gcp-first} resources from your applications without managing long-lived keys, authenticate your workloads by using {gcp-short} Workload Identity.
.Prerequisites
* You extracted and prepared the `ccoctl` binary.
@@ -142,4 +145,4 @@ spec:
- key: service_account.json
path: application_default_credentials.json
secretName: gcp-credentials
----
----

19
modules/cert-manager-configure-cpu-memory.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-configure-cpu-memory_{context}"]
= Overriding CPU and memory limits for the cert-manager components
After installing the {cert-manager-operator}, you can configure the CPU and memory limits from the {cert-manager-operator} API for the cert-manager components, such as the cert-manager controller, CA injector, and Webhook.
[role="_abstract"]
To ensure stable resource allocation and operation, configure CPU and memory limits for {cert-manager-operator} components. You can set specific constraints for the cert-manager controller, CA injector, and Webhook to align with your specific cluster requirements.
.Prerequisites
@@ -51,7 +52,7 @@ $ oc get deployment -n cert-manager -o yaml
spec:
containers:
- name: cert-manager-controller
resources: {} <1>
resources: {}
# ...
metadata:
name: cert-manager-cainjector
@@ -62,7 +63,7 @@ $ oc get deployment -n cert-manager -o yaml
spec:
containers:
- name: cert-manager-cainjector
resources: {} <1>
resources: {}
# ...
metadata:
name: cert-manager-webhook
@@ -73,10 +74,11 @@ $ oc get deployment -n cert-manager -o yaml
spec:
containers:
- name: cert-manager-webhook
resources: {} <1>
resources: {}
# ...
----
<1> The `spec.resources` field is empty by default. The cert-manager components do not have CPU and memory limits.
+
The `spec.resources` field is empty by default. The cert-manager components do not have CPU and memory limits.
. To configure the CPU and memory limits for the cert-manager controller, CA injector, and Webhook, enter the following command:
+
@@ -85,9 +87,9 @@ $ oc get deployment -n cert-manager -o yaml
$ oc patch certmanager.operator cluster --type=merge -p="
spec:
controllerConfig:
overrideResources: <1>
overrideResources:
limits:
cpu: 200m
cpu: 200m
memory: 64Mi
requests:
cpu: 10m
@@ -110,7 +112,8 @@ spec:
memory: 16Mi
"
----
<1> For information about the overridable resource parameters, see "Overridable resource parameters for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
+
For information about the overridable resource parameters, see "Overridable resource parameters for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
+
.Example output
[source,terminal]

120
modules/cert-manager-configuring-routes.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-configuring-routes_{context}"]
= Configuring certificates to secure routes in your cluster
The following steps demonstrate the process of utilizing the {cert-manager-operator} with the _Let's Encrypt_ ACME HTTP-01 challenge type to secure the route resources in your {product-title} cluster.
[role="_abstract"]
To encrypt traffic between external clients and your applications, configure certificates for routes in your {product-title} cluster. You can secure your routes by defining TLS termination types, such as edge, passthrough, or re-encrypt, to match your specific security policies.
.Prerequisites
@@ -18,16 +19,14 @@ The following steps demonstrate the process of utilizing the {cert-manager-opera
. 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
+
[source, yaml]
[source,yaml]
----
$ oc create -f - << EOF
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
name: letsencrypt-acme
namespace: <namespace> # <1>
namespace: <namespace>
spec:
acme:
server: https://acme-v02.api.letsencrypt.org/directory
@@ -39,111 +38,126 @@ spec:
ingressClassName: openshift-default
EOF
----
<1> Specify the namespace where the `Issuer` is located. It should be the same as your route's namespace.
+
Replace `<namespace>` with the namespace where the `Issuer` is located. It must be the same as your route's namespace.
. Create a `Certificate` object for the route by running the following command. The `secretName` 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.
+
[source, yaml]
[source,yaml]
----
$ oc create -f - << EOF
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: example-route-cert
namespace: <namespace> # <1>
namespace: <namespace>
spec:
commonName: <hostname> # <2>
commonName: <common_host>
dnsNames:
- <hostname> # <3>
- <hostname>
usages:
- server auth
issuerRef:
kind: Issuer
name: letsencrypt-acme
secretName: <secret_name> # <4>
secretName: <secret_name>
EOF
----
<1> Specify the `namespace` where the `Certificate` 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.
+
where:
+
`<namespace>`:: Specifies the `namespace` where the `Certificate` resource is located. It should be the same as your route's namespace.
`<common_host>`:: Specifies the certificate's common name using the hostname of the route.
`<hostname>`:: Specifies the hostname of your route to the certificate's DNS names.
`<secret_name>`:: Specifies 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:
+
[source, terminal]
[source,terminal]
----
$ oc create role secret-reader \
--verb=get,list,watch \
--resource=secrets \
--resource-name=<secret_name> \ # <1>
--namespace=<namespace> # <2>
--resource-name=<secret_name> \
--namespace=<namespace>
----
<1> Specify the name of the secret that you want to grant access to. It should be consistent with your `secretName` specified in the `Certificate` resource.
<2> Specify the namespace where both your secret and route are located.
+
where:
+
`<secret_name>`:: Specifies the name of the secret that you want to grant access to. It should be consistent with your `secretName` specified in the `Certificate` resource.
`<namespace>`:: Specifies the namespace where both your secret and route are located.
. Create a `RoleBinding` resource to bind the router service account with the newly created `Role` resource by using the following command:
+
[source, terminal]
[source,terminal]
----
$ oc create rolebinding secret-reader-binding \
--role=secret-reader \
--serviceaccount=openshift-ingress:router \
--namespace=<namespace> # <1>
--namespace=<namespace>
----
<1> Specify the namespace where both your secret and route are located.
+
Replace `<namespace>` with the namespace where both your secret and route are located.
. Create a route for your service resource, that uses edge TLS termination and a custom hostname, by running the following command. The hostname is used when creating a `Certificate` resource in the next step.
+
[source, terminal]
[source,terminal]
----
$ oc create route edge <route_name> \ # <1>
--service=<service_name> \ # <2>
--hostname=<hostname> \ # <3>
--namespace=<namespace> # <4>
$ oc create route edge <route_name> \
--service=<service_name> \
--hostname=<hostname> \
--namespace=<namespace>
----
<1> Specify your route's name.
<2> Specify the service you want to expose.
<3> Specify the hostname of your route.
<4> Specify the namespace where your route is located.
+
where:
+
`<route_name>`:: Specifies your route's name.
`<service_name>`:: Specifies the service you want to expose.
`<hostname>`:: Specifies the hostname of your route.
`<namespace>`:: Specifies the namespace where your route is 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:
+
[source, terminal]
[source,terminal]
----
$ oc patch route <route_name> \ # <1>
-n <namespace> \ # <2>
$ oc patch route <route_name> \
-n <namespace> \
--type=merge \
-p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}' # <3>
-p '{"spec":{"tls":{"externalCertificate":{"name":"<secret_name>"}}}}'
----
<1> Specify the route name.
<2> Specify the namespace where both your secret and route are located.
<3> Specify the name of the secret that contains the certificate.
+
where:
+
`<route_name>`:: Specifies the route name.
`<namespace>`:: Specifies the namespace where both your secret and route are located.
`<secret_name>`:: Specifies the name of the secret that contains the certificate.
.Verification
* Verify that the certificate is created and ready to use by running the following command:
. Verify that the certificate is created and ready to use by running the following command:
+
[source, terminal]
[source,terminal]
----
$ oc get certificate -n <namespace> <1>
$ oc get secret -n <namespace> <1>
$ oc get certificate -n <namespace>
$ oc get secret -n <namespace>
----
<1> Specify the namespace where both your secret and route reside.
+
Replace `<namespace>` with the namespace name where both your secret and route reside.
* 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`.
. 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`.
+
[source, terminal]
[source,terminal]
----
$ curl -IsS https://<hostname> <1>
$ curl -IsS https://<hostname>
----
<1> Specify the hostname of your route.
+
Replace `<hostname>` with the hostname of your route.
* Verify the server certificate's `subject`, `subjectAltName` and `issuer` are all as expected from the curl verbose outputs by running the following command:
. Verify the server certificate's `subject`, `subjectAltName` and `issuer` are all as expected from the curl verbose outputs by running the following command:
+
[source, terminal]
[source,terminal]
----
$ curl -v https://<hostname> <1>
$ curl -v https://<hostname>
----
<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.
Replace `<hostname>` with 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.

3
modules/cert-manager-enable-metrics.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-enable-metrics_{context}"]
= Configuring metrics collection for {cert-manager-operator} operands by using a ServiceMonitor
The {cert-manager-operator} operands exposes metrics by default on port `9402` at the `/metrics` service endpoint. You can configure metrics collection for the cert-manager operands by creating a `ServiceMonitor` custom resource (CR) that enables Prometheus Operator to collect custom metrics. For more information, see "Configuring user workload monitoring".
[role="_abstract"]]
The {cert-manager-operator} operands expose metrics by default on port `9402` at the `/metrics` service endpoint. You can configure metrics collection for the cert-manager operands by creating a `ServiceMonitor` custom resource (CR) that enables Prometheus Operator to collect custom metrics. For more information, see "Configuring user workload monitoring".
.Prerequisites

10
modules/cert-manager-enable-operand-log-level.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-enable-operand-log-level_{context}"]
= Setting a log level for cert-manager
You can set a log level for cert-manager to determine the verbosity of log messages.
[role="_abstract"]
To troubleshoot issues and control log volume, configure the log level for the {cert-manager-operator}. You can set specific verbosity levels to capture the necessary details for debugging or to reduce noise in your cluster logs.
.Prerequisites
@@ -30,9 +31,10 @@ apiVersion: operator.openshift.io/v1alpha1
kind: CertManager
...
spec:
logLevel: <log_level> <1>
logLevel: <log_level>
----
<1> The valid log level values for the `CertManager` resource are `Normal`, `Debug`, `Trace`, and `TraceAll`. To audit logs and perform common operations when there are no issues, set `logLevel` to `Normal` . To troubleshoot a minor issue by viewing verbose logs, set `logLevel` to `Debug` . To troubleshoot a major issue by viewing more verbose logs, you can set `logLevel` to `Trace`. To troubleshoot serious issues, set `logLevel` to `TraceAll`. The default `logLevel` is `Normal`.
+
The valid log level values for the `CertManager` resource are `Normal`, `Debug`, `Trace`, and `TraceAll`. To audit logs and perform common operations when there are no issues, set `logLevel` to `Normal` . To troubleshoot a minor issue by viewing verbose logs, set `logLevel` to `Debug` . To troubleshoot a major issue by viewing more verbose logs, you can set `logLevel` to `Trace`. To troubleshoot serious issues, set `logLevel` to `TraceAll`. The default `logLevel` is `Normal`.
+
[NOTE]
====
@@ -41,4 +43,4 @@ spec:
. 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.
After applying the changes, the verbosity level for the cert-manager components controller, CA injector, and webhook is updated.

10
modules/cert-manager-enable-operator-log-level.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-enable-operator-log-level_{context}"]
= Setting a log level for the {cert-manager-operator}
You can set a log level for the {cert-manager-operator} to determine the verbosity of the operator log messages.
[role="_abstract"]
To troubleshoot issues and control log volume, set the log level for the {cert-manager-operator}. You can configure the verbosity of the Operator log messages to capture the specific details required for your environment.
.Prerequisites
@@ -19,9 +20,10 @@ You can set a log level for the {cert-manager-operator} to determine the verbosi
+
[source,terminal]
----
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"OPERATOR_LOG_LEVEL","value":"v"}]}}}' <1>
$ oc -n cert-manager-operator patch subscription openshift-cert-manager-operator --type='merge' -p '{"spec":{"config":{"env":[{"name":"OPERATOR_LOG_LEVEL","value":"v"}]}}}'
----
<1> Replace `v` with the desired log level number. The valid values for `v` can range from `1`to `10`. The default value is `2`.
+
Replace `v` with the desired log level number. The valid values for `v` can range from `1`to `10`. The default value is `2`.
.Verification
@@ -46,4 +48,4 @@ OPERATOR_LOG_LEVEL=9
[source,terminal]
----
$ oc logs deploy/cert-manager-operator-controller-manager -n cert-manager-operator
----
----

3
modules/cert-manager-enable-user-workload-monitor.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-enable-user-workload-monitor_{context}"]
= Enabling user workload monitoring
You can enable monitoring for user-defined projects by configuring user workload monitoring in the cluster. For more information, see "Setting up metrics collection for user-defined projects".
[role="_abstract"]
To collect metrics from your specific applications, enable monitoring for user-defined projects. You can enable monitoring for user-defined projects by configuring user workload monitoring in the cluster. For more information, see "Setting up metrics collection for user-defined projects".
.Prerequisites

9
modules/cert-manager-explanation-of-certmanager-cr-fields.adoc
View File

@@ -6,7 +6,10 @@
[id="cert-manager-explanation-of-certmanager-cr-fields_{context}"]
= Explanation of fields in the CertManager custom resource
You can use the `CertManager` custom resource (CR) to configure the following core components of the {cert-manager-operator}:
[role="_abstract"]
To configure core components of the {cert-manager-operator}, use the CertManager custom resource (CR). You can define settings for the cert-manager controller, such as the spec.controllerConfig field, to customize your deployment.
The core components of the {cert-manager-operator} are as follows:
* Cert-manager controller: You can use the `spec.controllerConfig` field to configure the cert‑manager controller pod.
* Webhook: You can use the `spec.webhookConfig` field to configure the webhook pod, which handles validation and mutation requests.
@@ -164,7 +167,7 @@ The following table describes the overridable resource parameters for the cert-m
|Defines the minimum amount of CPU requested by the scheduler for a component pod.
|`overrideResources.requests.memory`
|Defines the minimum amount of memory requested by the scheduler for a component pod.
|Defines the minimum amount of memory requested by the scheduler for a component pod.
|====
@@ -187,4 +190,4 @@ The following table describes the pod scheduling parameters for the cert-manager
|`overrideScheduling.tolerations`
|List of tolerations to schedule pods on tainted nodes.
|====
|====

3
modules/cert-manager-fips-support.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-fips-support_{context}"]
= About FIPS compliance for {cert-manager-operator}
Starting with version 1.14.0, {cert-manager-operator} is designed for FIPS compliance. When running on {product-title} 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 link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic module validation program]. For the latest NIST status for the individual versions of the RHEL cryptographic libraries submitted for validation, see link:https://access.redhat.com/articles/2918071#fips-140-2-and-fips-140-3-2[Compliance activities and government standards].
[role="_abstract"]
Starting with version 1.14.0, {cert-manager-operator} is designed for FIPS compliance. When running on {product-title} 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} on an {product-title} cluster configured to operate in FIPS mode. For more information, see "Do you need extra security for your cluster?"

5
modules/cert-manager-install-cli.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-install-cli_{context}"]
= Installing the {cert-manager-operator} by using the CLI
[role="_abstract"]
You can install the {cert-manager-operator} by using the command-line interface(CLI).
.Prerequisites
* You have access to the cluster with `cluster-admin` privileges.
@@ -145,4 +148,4 @@ 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
----
----

1
modules/cert-manager-install-console.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-install-console_{context}"]
= Installing the {cert-manager-operator} by using the web console
[role="_abstract"]
You can use the web console to install the {cert-manager-operator}.
.Prerequisites

5
modules/cert-manager-issuer-types.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-issuer-types_{context}"]
= {cert-manager-operator} issuer providers
The {cert-manager-operator} has been tested with the following issuer types:
[role="_abstract"]
To configure certificate authorities for your cluster, review the issuer providers offered with the {cert-manager-operator}. You can use the following issuer types to automate certificate validation and issuance:
* Automated Certificate Management Environment (ACME)
* Certificate Authority (CA)
@@ -19,4 +20,4 @@ The {cert-manager-operator} has been tested with the following issuer types:
[NOTE]
====
{product-title} does not test all factors associated with third-party {cert-manager-operator} provider functionality. For more information about third-party support, see the link:https://access.redhat.com/third-party-software-support[{product-title} third-party support policy].
====
====

23
modules/cert-manager-istio-creating-issuer.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-istio-creating-issuer_{context}"]
= Creating a root CA issuer for the Istio-CSR agent
Use this procedure to create the root CA issuer for Istio-CSR agent.
[role="_abstract"]
To enable certificate signing for the Istio-CSR agent, configure a root CA issuer using the {cert-manager-operator}. You can establish a trusted root by using the {cert-manager-operator} to ensure secure communication between workloads.
[NOTE]
====
@@ -15,16 +16,15 @@ Other supported issuers can be used, except for the ACME issuer, which is not su
.Procedure
. Create a YAML file that defines the `Issuer` and `Certificate` objects:
. Create a YAML file that defines the `Issuer` and `Certificate` objects by using the following example configuration:
+
.Example `issuer.yaml` file
[source,yaml]
----
apiVersion: cert-manager.io/v1
kind: Issuer <1>
kind: Issuer
metadata:
name: selfsigned
namespace: <istio_project_name> <2>
namespace: <istio_project_name>
spec:
selfSigned: {}
---
@@ -47,20 +47,23 @@ spec:
- cert-manager
issuerRef:
name: selfsigned
kind: Issuer <1>
kind: Issuer
group: cert-manager.io
---
apiVersion: cert-manager.io/v1
kind: Issuer <1>
kind: Issuer
metadata:
name: istio-ca
namespace: <istio_project_name> <2>
namespace: <istio_project_name>
spec:
ca:
secretName: istio-ca
----
<1> Specify the `Issuer` or `ClusterIssuer`.
<2> Specify the name of the Istio project.
+
where:
+
`Issuer`:: Specifies the `Issuer` or `ClusterIssuer`.
`<istio_project_name>`:: Specifies the name of the Istio project.
.Verification

30
modules/cert-manager-istio-csr-config-ca-cert.adoc
View File

@@ -1,7 +1,12 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
:_mod-docs-content-type: PROCEDURE
[id="cert-manager-istio-csr-config-ca-cert_{context}"]
= Configuring the CA certificate for the Istio server
[role="_abstract"]
You can configure the `ConfigMap` that contains the CA bundle used by Istio workloads to verify the Istio server certificate. If not configured, the {cert-manager-operator} looks for the CA certificate in the configured issuer and in the Kubernetes Secret that contains the Istio certificates.
.Prerequisites
@@ -15,13 +20,13 @@ You can configure the `ConfigMap` that contains the CA bundle used by Istio work
+
[source,terminal]
----
oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name> <1>
$ oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name>
----
<1> Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the CA bundle by editing the `spec.istioCSRConfig.certManager` section:
+
.Sample `IstioCSR` CR with CA bundle configuration
Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the CA bundle by editing the `spec.istioCSRConfig.certManager` section. See the following example:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1alpha1
@@ -31,13 +36,16 @@ spec:
istioCSRConfig:
certManager:
istioCACertificate:
key: <key_in_the_configmap> <1>
name: <configmap_name> <2>
namespace: <configmap_namespace> <3>
key: <key_in_the_configmap>
name: <configmap_name>
namespace: <configmap_namespace>
----
<1> Specify the key name in the `ConfigMap` that contains the CA bundle.
<2> Specify the name of the `ConfigMap`. Ensure that the referenced `ConfigMap` and key exist before you update this field.
<3> Optional: Specify the namespace where the `ConfigMap` exists. If you do not set this field, the {cert-manager-operator} searches for the `ConfigMap` in the namespace where you have installed the `IstioCSR` CR.
+
where:
+
`<key_in_the_configmap>`:: Specifies the key name in the `ConfigMap` that contains the CA bundle.
`<configmap_name>`:: Specifies the name of the `ConfigMap`. Ensure that the referenced `ConfigMap` and key exist before you update this field.
`<configmap_namespace>`:: Optional. Specifies the namespace where the `ConfigMap` exists. If you do not set this field, the {cert-manager-operator} searches for the `ConfigMap` in the namespace where you have installed the `IstioCSR` CR.
+
[NOTE]
====

22
modules/cert-manager-istio-csr-config-namespace-sel.adoc
View File

@@ -1,7 +1,12 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
:_mod-docs-content-type: PROCEDURE
[id="cert-manager-istio-csr-config-namespace-sel_{context}"]
= Configuring the namespace selector for CA bundle distribution
[role="_abstract"]
The Istio-CSR agent creates and updates the `istio-ca-root-cert` `ConfigMap`, which contains the CA bundle. Workloads in the service mesh use this CA bundle to validate connections to the Istio control plane. You can configure a namespace selector to specify the namespaces in which the Istio-CSR agent creates this `ConfigMap`. If you do not configure a selector, the Istio-CSR agent creates the `ConfigMap` in all namespaces.
.Prerequisites
@@ -15,13 +20,13 @@ The Istio-CSR agent creates and updates the `istio-ca-root-cert` `ConfigMap`, wh
+
[source,terminal]
----
oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name> <1>
oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name>
----
<1> Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the `spec.istioCSRConfig.istioDataPlaneNamespaceSelector` section to set the namespace selector:
+
.Sample IstioCSR CR configuration with a namespace selector
Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the `spec.istioCSRConfig.istioDataPlaneNamespaceSelector` section to set the namespace selector. See the following example:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1alpha1
@@ -29,10 +34,11 @@ kind: IstioCSR
...
spec:
istioCSRConfig:
istioDataPlaneNamespaceSelector: maistra.io/member-of=istio-system <1>
istioDataPlaneNamespaceSelector: maistra.io/member-of=istio-system
# ...
----
<1> Replace `maistra.io/member-of=istio-system` with the label key and value that identify the namespaces in your service mesh. Use the format `<key>=<value>`.
+
The `maistra.io/member-of=istio-system` namespace selector defines the label key and value that identify the namespaces in your service mesh. Use the `<key>=<value>` format.
+
[NOTE]
====
@@ -48,4 +54,4 @@ done
----
====
. Save and close the editor to apply your changes. After the changes are applied, the {cert-manager-operator} updates the namespace selector configuration for the istio-csr operand.
. Save and close the editor to apply your changes. After the changes are applied, the {cert-manager-operator} updates the namespace selector configuration for the istio-csr operand.

10
modules/cert-manager-istio-csr-customizing.adoc
View File

@@ -1,10 +0,0 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
:_mod-docs-content-type: PROCEDURE
[id="cert-manager-istio-csr-customizing_{context}"]
= Customizing the IstioCSR custom resource
You can modify the `IstioCSR` custom resource (CR) to define how Istio workloads interact with the cert-manager Operator.

19
modules/cert-manager-istio-csr-installing.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-istio-csr-installing_{context}"]
= Creating the `IstioCSR` custom resource
Use this procedure to install the Istio-CSR agent through {cert-manager-operator}.
[role="_abstract"]
To secure your communications, install the Istio-CSR agent by creating the `IstioCSR` custom resource through the {cert-manager-operator}.
.Prerequisites
@@ -40,9 +41,8 @@ Only one `IstioCSR` custom resource (CR) is supported at a time. If multiple `Is
* The Operator does not automatically remove objects created for `IstioCSR`. If an active `IstioCSR` resource is deleted and a new one is created in a different namespace without removing the previous deployments, multiple `istio-csr` deployments may remain active. This behavior is not recommended and is not supported.
====
.. Create a YAML file that defines the `IstioCSR` object:
.. Create a YAML file that defines the `IstioCSR` object by using the following example:
+
.Example `IstioCSR` CR
[source,yaml]
----
apiVersion: operator.openshift.io/v1alpha1
@@ -54,16 +54,19 @@ spec:
istioCSRConfig:
certManager:
issuerRef:
name: istio-ca <1>
kind: Issuer <2>
name: istio-ca
kind: Issuer
group: cert-manager.io
istiodTLSConfig:
trustDomain: cluster.local
istio:
namespace: <istio_project_name>
----
<1> Specify the `Issuer` or `ClusterIssuer` name. It should be the same name as the CA issuer defined in the `issuer.yaml` file.
<2> Specify the `Issuer` or `ClusterIssuer` kind. It should be the same kind as the CA issuer defined in the `issuer.yaml` file.
+
where:
+
`name`:: Specifies the `Issuer` or `ClusterIssuer` name. It should be the same name as the CA issuer defined in the `issuer.yaml` file.
`kind`:: Specifies the `Issuer` or `ClusterIssuer` kind. It should be the same kind as the CA issuer defined in the `issuer.yaml` file.
.. Create the `IstioCSR` custom resource by running the following command:
+
@@ -114,4 +117,4 @@ $ oc -n <istio_csr_project_name> logs <istio_csr_pod_name>
[source,terminal]
----
$ oc -n cert-manager-operator logs <cert_manager_operator_pod_name>
----
----

26
modules/cert-manager-istio-csr-setting-log-level.adoc
View File

@@ -1,7 +1,12 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
:_mod-docs-content-type: PROCEDURE
[id="cert-manager-istio-csr-setting-log-level_{context}"]
= Setting the log level for the istio-csr component
[role="_abstract"]
You can set the log level for the istio-csr component to control the verbosity and format of its log messages.
.Prerequisites
@@ -15,13 +20,13 @@ You can set the log level for the istio-csr component to control the verbosity a
+
[source,terminal]
----
oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name> <1>
$ oc edit istiocsrs.operator.openshift.io default -n <istio_csr_project_name> <1>
----
<1> Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the log level and format in the `spec.istioCSRConfig` section:
+
.Sample IstioCSR CR configuration for setting the log level
Replace `<istio_csr_project_name>` with the namespace where you created the `IstioCSR` CR.
. Configure the log level and format in the `spec.istioCSRConfig` section by using the following example configuration:
+
[source,yaml]
----
apiVersion: operator.openshift.io/v1alpha1
@@ -29,11 +34,14 @@ kind: IstioCSR
...
spec:
istioCSRConfig:
logFormat: text <1>
logLevel: 2 <2>
logFormat: text
logLevel: 2
# ...
----
<1> Specify the log output format. You can set this field to either `text` or `json`.
<2> Set the log level. Supported values are in the range `1` through `5`, as defined by Kubernetes logging guidelines. The default value is `1`.
+
where:
+
`logFormat`:: Specifies the log output format. You can set this field to either `text` or `json`.
`logLevel`:: Specifies the log level. Supported values are in the range `1` through `5`, as defined by Kubernetes logging guidelines. The default value is `1`.
. Save and close the editor to apply your changes. After the changes are applied, the cert-manager Operator updates the log configuration for the istio-csr operand.

3
modules/cert-manager-istio-csr-uninstalling.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-istio-csr-uninstalling_{context}"]
= Uninstalling the Istio-CSR agent managed by {cert-manager-operator}
Use this procedure to uninstall the Istio-CSR agent managed by {cert-manager-operator}.
[role="_abstract"]
You can uninstall the Istio-CSR agent managed by the {cert-manager-operator} to remove the agent and its associated resources.
.Prerequisites

14
modules/cert-manager-nw-policy-examples.adoc
View File

@@ -1,13 +1,15 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-nw-policy.adoc
:_mod-docs-content-type: REFERENCE
[id="cert-manager-nw-policy-examples_{context}"]
= Network policy configuration examples
The following examples cover various scenarios related to enabling network policy and custom rules:
[role="_abstract"]
To control traffic flow and enhance cluster security, enable network policies and custom rules for the {cert-manager-operator}.
.Example for enabling the network policy management
To enable network policy and custom rules, see the following example:
[source, yaml]
----
@@ -19,7 +21,7 @@ spec:
defaultNetworkPolicy: "true"
----
.Example for allowing egress to all external issuer providers
To allow egress access to all external issuer providers, see the following example:
[source, yaml]
----
@@ -36,9 +38,7 @@ spec:
- {}
----
.Example for allowing egress to the specific issuer provider
The following configuration allows the cert-manager Operator controller to perform the ACME challenge self-check. This process requires connections to the ACME provider, DNS API endpoints, and recursive DNS servers.
To allow the cert-manager Operator controller to perform the ACME challenge self-check, see the following example. This process requires connections to the ACME provider, DNS API endpoints, and recursive DNS servers.
[source, yaml]
----
@@ -65,4 +65,4 @@ spec:
protocol: UDP
- port: 53
protocol: TCP
----
----

4
modules/cert-manager-nw-policy-params.adoc
View File

@@ -1,10 +1,12 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-nw-policy.adoc
:_mod-docs-content-type: REFERENCE
[id="cert-manager-nw-policy-params_{context}"]
= Network policy configuration parameters
[role="_abstract"]
You can enable and configure network policies for the cert-manager Operator components by updating the `CertManager` custom resource (CR). The CR includes the following parameters for enabling default network policies and defining custom egress rules.
[cols="1,1,3", options="header"]
@@ -40,4 +42,4 @@ Once you enable default network policies, you cannot disable them. This restrict
|`spec.networkPolicies.name`
|`string`
|Specifies a unique name for the custom network policy, which is used to generate the `NetworkPolicy` resource name.
|===
|===

4
modules/cert-manager-nw-policy-rules.adoc
View File

@@ -1,10 +1,12 @@
// Module included in the following assemblies:
//
// * security/cert_manager_operator/cert-manager-nw-policy.adoc
:_mod-docs-content-type: REFERENCE
[id="cert-manager-nw-policy-rules_{context}"]
= Default ingress and egress rules
[role="_abstract"]
The default network policy applies the following ingress and egress rules to each component.
[cols="1,1,1,1",options="header"]
@@ -33,4 +35,4 @@ The default network policy applies the following ingress and egress rules to eac
| 6443, 9402
| 6443
| Allows ingress traffic to the gRPC Istio certificate request API, metrics servers and egress traffic to OpenShift API server.
|===
|===

4
modules/cert-manager-nw-policy-verify.adoc
View File

@@ -5,6 +5,7 @@
[id="verifying-network-policy-creation_{context}"]
= Verifying the network policy creation
[role="_abstract"]
You can verify that the default and custom `NetworkPolicy` resources are created.
.Prerequisites
@@ -21,7 +22,6 @@ $ oc get networkpolicy -n cert-manager
----
+
.Example output
+
[source, terminal]
----
NAME POD-SELECTOR AGE
@@ -34,4 +34,4 @@ cert-manager-user-allow-egress-to-acme-server app=cert-manager
cert-manager-user-allow-egress-to-dns-service app=cert-manager 7s
----
+
The output lists the default policies and any custom policies that you created.
The output lists the default policies and any custom policies that you created.

1
modules/cert-manager-operator-update-channels.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-operator-update-channels_{context}"]
= Understanding update channels of the {cert-manager-operator}
[role="_abstract"]
Update channels are the mechanism by which you can declare the version of your {cert-manager-operator} in your cluster. The {cert-manager-operator} offers the following update channels:
* `stable-v1`

8
modules/cert-manager-override-arguments.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-override-arguments_{context}"]
= Customizing cert-manager by overriding arguments from the cert-manager Operator API
[role="_abstract"]
You can override the supported arguments for the {cert-manager-operator} by adding a `spec.controllerConfig` section in the `CertManager` resource.
.Prerequisites
@@ -34,7 +35,7 @@ spec:
...
controllerConfig:
overrideArgs:
- '--dns01-recursive-nameservers=<server_address>' <1>
- '--dns01-recursive-nameservers=<server_address>'
- '--dns01-recursive-nameservers-only'
- '--acme-http01-solver-nameservers=<host>:<port>'
- '--v=<verbosity_level>'
@@ -51,7 +52,8 @@ spec:
overrideArgs:
- '--v=<verbosity_level>'
----
<1> For information about the overridable aruguments, see "Overridable arguments for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
+
For information about the overridable aruguments, see "Overridable arguments for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
. Save your changes and quit the text editor to apply your changes.
@@ -103,4 +105,4 @@ $ oc get pods -n cert-manager -o yaml
- args:
...
- --v=4
----
----

18
modules/cert-manager-override-environment-variables.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-override-environment-variables_{context}"]
= Customizing cert-manager by overriding environment variables from the cert-manager Operator API
[role="_abstract"]
To refine your deployment for specific operational requirements, override supported environment variables for the {cert-manager-operator}. You can customize these variables through the Operator API to apply configurations, such as proxy settings or system-level adjustments, that differ from the default values.
You can override the supported environment variables for the {cert-manager-operator} by adding a `spec.controllerConfig` section in the `CertManager` resource.
.Prerequisites
@@ -35,14 +38,17 @@ spec:
controllerConfig:
overrideEnv:
- name: HTTP_PROXY
value: http://<proxy_url> <1>
value: http://<proxy_url>
- name: HTTPS_PROXY
value: https://<proxy_url> <1>
value: https://<proxy_url>
- name: NO_PROXY
value: <ignore_proxy_domains> <2>
value: <ignore_proxy_domains>
----
<1> Replace `<proxy_url>` with the proxy server URL.
<2> Replace `<ignore_proxy_domains>` with a comma separated list of domains. These domains are ignored by the proxy server.
+
where:
+
`HTTP_PROXY`:: Specifies the proxy server URL.
`NO_PROXY`:: Specifies a comma separated list of domains. These domains are ignored by the proxy server.
+
[NOTE]
====
@@ -85,4 +91,4 @@ $ oc get pod <redeployed_cert-manager_controller_pod> -n cert-manager -o yaml
value: https://<PROXY_URL>
- name: NO_PROXY
value: <IGNORE_PROXY_DOMAINS>
----
----

1
modules/cert-manager-override-flag-controller.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-override-flag-controller_{context}"]
= Deleting a TLS secret automatically upon Certificate removal
[role="_abstract"]
You can enable the `--enable-certificate-owner-ref` flag for the {cert-manager-operator} 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.
[WARNING]

10
modules/cert-manager-override-scheduling.adoc
View File

@@ -6,7 +6,8 @@
[id="cert-manager-override-scheduling_{context}"]
= Configuring scheduling overrides for cert-manager components
You can configure the pod scheduling from the {cert-manager-operator} API for the {cert-manager-operator} components, such as the cert-manager controller, CA injector, and Webhook.
[role="_abstract"]
You can configure the pod scheduling from the {cert-manager-operator} API for the {cert-manager-operator} components, such as the cert-manager controller, CA injector, and Webhook.
.Prerequisites
@@ -22,7 +23,7 @@ You can configure the pod scheduling from the {cert-manager-operator} API for th
$ oc patch certmanager.operator cluster --type=merge -p="
spec:
controllerConfig:
overrideScheduling: <1>
overrideScheduling:
nodeSelector:
node-role.kubernetes.io/control-plane: ''
tolerations:
@@ -47,7 +48,8 @@ spec:
effect: NoSchedule"
"
----
<1> For information about the overridable scheduling parameters, see "Overridable scheduling parameters for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
+
For information about the overridable scheduling parameters, see "Overridable scheduling parameters for the cert-manager components" in "Explanation of fields in the CertManager custom resource".
.Verification
@@ -97,4 +99,4 @@ cert-manager-webhook
[source,terminal]
----
$ oc get events -n cert-manager --field-selector reason=Scheduled
----
----

1
modules/cert-manager-proxy-support.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-proxy-support_{context}"]
= Injecting a custom CA certificate for the {cert-manager-operator}
[role="_abstract"]
If your {product-title} 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}.
.Prerequisites

13
modules/cert-manager-query-metrics-for-istio-csr-operand.adoc
View File

@@ -6,20 +6,17 @@
[id="cert-manager-query-metrics-for-istio-csr-operand_{context}"]
= Querying metrics for the istio-csr operand
[role="_abstract"]
Cluster administrators, or users with view access to all namespaces, can query metrics for the istio-csr operand by using the {product-title} web console. For more information, see "Accessing metrics".
.Prerequisites
* You have access to the cluster with `cluster-admin` privileges.
* You have installed the {cert-manager-operator}.
* You have access to the cluster with `cluster-admin` privileges.
* You have installed the {cert-manager-operator}.
* You have enabled monitoring and metrics collection by creating the `ServiceMonitor` object for the istio-csr operand.
.Procedure
. Log in to the {product-title} web console.
. Click *Observe* -> *Metrics*.
. In the query field, enter the following PromQL expression to query the `istio-csr` operand metrics:
+
`{job="cert-manager-istio-csr"}`
The results display metrics collected for the istio-csr operand, which can help you monitor its performance and behavior.
. Click *Observe* -> *Metrics*.
. In the query field, enter the `{job="cert-manager-istio-csr"}` PromQL expression to query the `istio-csr` operand metrics. The results display metrics collected for the istio-csr operand, which can help you monitor its performance and behavior.

1
modules/cert-manager-query-metrics.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-query-metrics_{context}"]
= Querying metrics for the {cert-manager-operator} operands
[role="_abstract"]
As a cluster administrator, or as a user with view access to all namespaces, you can query {cert-manager-operator} operands metrics by using the {product-title} web console or the command-line interface (CLI). For more information, see "Accessing metrics".
.Prerequisites

3
modules/cert-manager-remove-resources-console.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-remove-resources-console_{context}"]
= Removing {cert-manager-operator} resources
[role="_abstract"]
Once you have uninstalled the {cert-manager-operator}, you have the option to eliminate its associated resources from your cluster.
.Prerequisites
@@ -62,4 +63,4 @@ $ oc patch certmanagers.operator cluster --type=merge -p='{"metadata":{"finalize
. Optional: Remove the `cert-manager-operator` namespace.
.. Navigate to *Administration* -> *Namespaces*.
.. Click the Options menu {kebab} next to the *cert-manager-operator* and select *Delete Namespace*.
.. In the confirmation dialog, enter `cert-manager-operator` in the field and click *Delete*.
.. In the confirmation dialog, enter `cert-manager-operator` in the field and click *Delete*.

3
modules/cert-manager-request-methods.adoc
View File

@@ -6,6 +6,9 @@
[id="cert-manager-request-methods_{context}"]
= Certificate request methods
[role="_abstract"]
To obtain certificates for your workloads, choose a request method supported by the {cert-manager-operator}. You can select the approach that fits your operational requirements and automation workflow.
There are two ways to request a certificate using the {cert-manager-operator}:
Using the `cert-manager.io/CertificateRequest` object:: With this method a service developer creates a `CertificateRequest` object with a valid `issuerRef` 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.

3
modules/cert-manager-supported-versions.adoc
View File

@@ -6,4 +6,5 @@
[id="cert-manager-operator-supported-versions_{context}"]
= Supported {cert-manager-operator} versions
For the list of supported versions of the {cert-manager-operator} across different {product-title} releases, see the "Platform Agnostic Operators" section in the link:https://access.redhat.com/support/policy/updates/openshift_operators[{product-title} update and support policy].
[role="_abstract"]
To maintain a supported configuration, review the compatibility of the {cert-manager-operator} with different {product-title} releases. To find the list of supported versions of the {cert-manager-operator} across different {product-title} releases, see the "Platform Agnostic Operators" section in "{product-title} update and support policy".

1
modules/cert-manager-uninstall-console.adoc
View File

@@ -6,6 +6,7 @@
[id="cert-manager-uninstall-console_{context}"]
= Uninstalling the {cert-manager-operator}
[role="_abstract"]
You can uninstall the {cert-manager-operator} by using the web console.
.Prerequisites

5
security/cert_manager_operator/cert-manager-authenticate.adoc
View File

@@ -6,7 +6,8 @@ include::_attributes/common-attributes.adoc[]
toc::[]
You can authenticate the cert-manager Operator for Red Hat OpenShift on the cluster by configuring the cloud credentials.
[role="_abstract"]
To enable the operator to manage components on your cloud provider, authenticate the {cert-manager-operator} by configuring cloud credentials. You can grant the Operator access to external services required for certificate issuance, such as DNS providers.
// on AWS
include::modules/cert-manager-configure-cloud-credentials-aws-non-sts.adoc[leveloffset=+1]
@@ -34,4 +35,4 @@ include::modules/cert-manager-configure-cloud-credentials-gcp-sts.adoc[leveloffs
* xref:../../authentication/managing_cloud_provider_credentials/cco-short-term-creds.adoc#cco-short-term-creds[Manual mode with short-term credentials for components]
* xref:../../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator-default_about-cloud-credential-operator[Default behavior of the Cloud Credential Operator]
* xref:../../authentication/managing_cloud_provider_credentials/about-cloud-credential-operator.adoc#about-cloud-credential-operator-default_about-cloud-credential-operator[Default behavior of the Cloud Credential Operator]

8
security/cert_manager_operator/cert-manager-creating-certificate.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
By using the {cert-manager-operator}, 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.
include::modules/cert-manager-certificate-mgmt.adoc[leveloffset=+1]
@@ -17,12 +18,11 @@ include::modules/cert-manager-certificate-ingress.adoc[leveloffset=+1]
[role="_additional-resources"]
[id="additional-resources_cert-manager-creating-certificate"]
== Additional resources
* Configuring an issuer
** xref:../../security/cert_manager_operator/index.adoc#cert-manager-issuer-types_cert-manager-operator-about[Supported issuer types]
* xref:../../security/cert_manager_operator/index.adoc#cert-manager-issuer-types_cert-manager-operator-about[Supported issuer types]
** xref:../../security/cert_manager_operator/cert-manager-operator-issuer-acme.adoc#cert-manager-operator-issuer-acme[Configuring an ACME issuer]
* xref:../../security/cert_manager_operator/cert-manager-operator-issuer-acme.adoc#cert-manager-operator-issuer-acme[Configuring an ACME issuer]
* xref:../../security/certificates/api-server.adoc#customize-certificates-api-add-named_api-server-certificates[Adding an API server named certificate]
* xref:../../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Replacing the default ingress certificate]
* xref:../../security/certificates/replacing-default-ingress-certificate.adoc#replacing-default-ingress[Replacing the default ingress certificate]

3
security/cert_manager_operator/cert-manager-customizing-api-fields.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
After installing the {cert-manager-operator}, you can perform the following actions by configuring the `CertManager` custom resource (CR):
* Configure the arguments to modify the behavior of the cert-manager components, such as the cert-manager controller, CA injector, and Webhook.
@@ -106,4 +107,4 @@ include::modules/cert-manager-override-scheduling.adoc[leveloffset=+1]
[role="_additional-resources"]
.Additional resources
* xref:../../security/cert_manager_operator/cert-manager-customizing-api-fields.adoc#cert-manager-explanation-of-certmanager-cr-fields_cert-manager-customizing-api-fields[Explanation of fields in the CertManager custom resource]
* xref:../../security/cert_manager_operator/cert-manager-customizing-api-fields.adoc#cert-manager-explanation-of-certmanager-cr-fields_cert-manager-customizing-api-fields[Explanation of fields in the CertManager custom resource]

1
security/cert_manager_operator/cert-manager-log-levels.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
To troubleshoot issues with the cert-manager components and the {cert-manager-operator}, you can configure the log level verbosity.
[NOTE]

3
security/cert_manager_operator/cert-manager-monitoring.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
By default, the {cert-manager-operator} exposes metrics for the three core components: controller, cainjector, and webhook. You can configure OpenShift Monitoring to collect these metrics by using the Prometheus Operator format.
// Enabling user workload monitoring for the cert-manager operand
@@ -45,4 +46,4 @@ include::modules/cert-manager-query-metrics-for-istio-csr-operand.adoc[leveloffs
[role="_additional-resources"]
.Additional resources
* link:https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.21/html/accessing_metrics/accessing-metrics-as-an-administrator[Accessing metrics as an administrator]
* link:https://docs.redhat.com/en/documentation/monitoring_stack_for_red_hat_openshift/4.21/html/accessing_metrics/accessing-metrics-as-an-administrator[Accessing metrics as an administrator]

3
security/cert_manager_operator/cert-manager-nw-policy.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} provides predefined `NetworkPolicy` resources to enhance security by controlling the ingress and egress traffic for its components. By default, this feature is disabled to prevent connectivity issues or breaking changes during an upgrade. To use this feature, you must enable it in the `CertManager` custom resource (CR).
After enabling the default policies, you must manually configure additional egress rules to allow outbound traffic. These rules are required for {cert-manager-operator} to communicate with external services beyond the API server and internal DNS.
@@ -33,4 +34,4 @@ include::modules/cert-manager-nw-policy-params.adoc[leveloffset=+1]
include::modules/cert-manager-nw-policy-examples.adoc[leveloffset=+1]
//Verification
include::modules/cert-manager-nw-policy-verify.adoc[leveloffset=+1]
include::modules/cert-manager-nw-policy-verify.adoc[leveloffset=+1]

5
security/cert_manager_operator/cert-manager-operator-install.adoc
View File

@@ -6,13 +6,14 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} is not installed in {product-title} by default. You can install the {cert-manager-operator} by using the web console.
[IMPORTANT]
====
The {cert-manager-operator} version 1.15 or later supports the `AllNamespaces`, `SingleNamespace`, and `OwnNamespace` installation modes. Earlier versions, such as 1.14, support only the `SingleNamespace` and `OwnNamespace` installation modes.
====
The {cert-manager-operator} is not installed in {product-title} by default. You can install the {cert-manager-operator} by using the web console.
== Installing the {cert-manager-operator}
// Installing the {cert-manager-operator} using the web console
include::modules/cert-manager-install-console.adoc[leveloffset=+2]

10
security/cert_manager_operator/cert-manager-operator-integrating-istio.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} provides enhanced support for securing workloads and control plane components in {SMProductName} or Istio. This includes support for certificates enabling mutual TLS (mTLS), which are signed, delivered, and renewed using cert-manager issuers. You can secure Istio workloads and control plane components by using the {cert-manager-operator} managed Istio-CSR agent.
With this Istio-CSR integration, Istio can now obtain certificates from the {cert-manager-operator}, simplifying security and certificate management.
@@ -24,17 +25,14 @@ include::modules/cert-manager-istio-creating-issuer.adoc[leveloffset=+2]
// Installing using Istio-CSR
include::modules/cert-manager-istio-csr-installing.adoc[leveloffset=+2]
// Customizing the IstioCSR custom resource
include::modules/cert-manager-istio-csr-customizing.adoc[leveloffset=+1]
// Setting a log level for istio-csr
include::modules/cert-manager-istio-csr-setting-log-level.adoc[leveloffset=+2]
// Configuring the namespace selector for CA bundle distribution [leveloffset=+3]
// Configuring the namespace selector for CA bundle distribution
include::modules/cert-manager-istio-csr-config-namespace-sel.adoc[leveloffset=+2]
// Configuring the CA certificate of the istio server [leveloffset=+3]
// Configuring the CA certificate of the istio server
include::modules/cert-manager-istio-csr-config-ca-cert.adoc[leveloffset=+2]
// Uninstalling cert-manager Operator with Istio-CSR
include::modules/cert-manager-istio-csr-uninstalling.adoc[leveloffset=+1]
include::modules/cert-manager-istio-csr-uninstalling.adoc[leveloffset=+1]

3
security/cert_manager_operator/cert-manager-operator-issuer-acme.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} 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.
[NOTE]
@@ -67,4 +68,4 @@ include::modules/cert-manager-acme-dns01-explicit-azure.adoc[leveloffset=+1]
* xref:../../security/cert_manager_operator/cert-manager-authenticate.adoc#cert-manager-configure-cloud-credentials-gcp-sts_cert-manager-authenticate[Configuring cloud credentials for the {cert-manager-operator} with {gcp-short} Workload Identity]
* xref:../../security/cert_manager_operator/cert-manager-authenticate.adoc#cert-manager-configure-cloud-credentials-gcp-non-sts_cert-manager-authenticate[Configuring cloud credentials for the {cert-manager-operator} on {gcp-short}]
* xref:../../security/cert_manager_operator/cert-manager-authenticate.adoc#cert-manager-configure-cloud-credentials-gcp-non-sts_cert-manager-authenticate[Configuring cloud credentials for the {cert-manager-operator} on {gcp-short}]

1
security/cert_manager_operator/cert-manager-operator-proxy.adoc
View File

@@ -4,6 +4,7 @@
include::_attributes/common-attributes.adoc[]
:context: cert-manager-operator-proxy
[role="_abstract"]
If a cluster-wide egress proxy is configured in {product-title}, 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}.

8
security/cert_manager_operator/cert-manager-operator-release-notes.adoc
View File

@@ -6,13 +6,13 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} is a cluster-wide service that provides application certificate lifecycle management.
These release notes track the development of {cert-manager-operator}.
For more information, see xref:../../security/cert_manager_operator/index.adoc#cert-manager-operator-about[About the {cert-manager-operator}].
[id="cert-manager-operator-release-notes-1-18-0_{context}"]
== {cert-manager-operator} 1.18.0
@@ -28,7 +28,7 @@ The following advisories are available for the {cert-manager-operator} 1.18.0:
Version `1.18.0` of the {cert-manager-operator} is based on the upstream cert-manager version `v1.18.3`. For more information, see the link:https://cert-manager.io/docs/releases/release-notes/release-notes-1.18#v1183[cert-manager project release notes for v1.18.3].
[id="cert-manager-operator-1-18-0-features-enhancements_{context}"]
=== New features and enhancements
== New features and enhancements
*Istio-CSR integration with {cert-manager-operator} (Generally Available)*
@@ -51,7 +51,7 @@ By default, this feature is disabled to prevent connectivity issues during upgra
[id="cert-manager-operator-1-18-0-known-issues_{context}"]
=== Known issues
== Known issues
* The upstream cert-manager `v1.18` release updated the ACME HTTP-01 challenge ingress path type from `ImplementationSpecific` to `Exact`. The OpenShift Route API does not have an equivalent for the `Exact` path type, which prevents the ingress-to-route controller from supporting it. As a result, ingress resources created for HTTP-01 challenges cannot route traffic to the solver pod, causing the challenge to fail with a 503 error.
To mitigate this issue, the `ACMEHTTP01IngressPathTypeExact` feature gate is disabled by default in this release.
To mitigate this issue, the `ACMEHTTP01IngressPathTypeExact` feature gate is disabled by default in this release.

3
security/cert_manager_operator/cert-manager-operator-uninstall.adoc
View File

@@ -6,10 +6,11 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
You can remove the {cert-manager-operator} from {product-title} by uninstalling the Operator and removing its related resources.
// Uninstalling the {cert-manager-operator}
include::modules/cert-manager-uninstall-console.adoc[leveloffset=+1]
// Removing {cert-manager-operator} resources
include::modules/cert-manager-remove-resources-console.adoc[leveloffset=+1]
include::modules/cert-manager-remove-resources-console.adoc[leveloffset=+1]

2
security/cert_manager_operator/cert-manager-securing-routes.adoc
View File

@@ -17,4 +17,4 @@ include::modules/cert-manager-configuring-routes.adoc[leveloffset=+1]
* xref:../../networking/ingress_load_balancing/routes/nw-configuring-routes.adoc#nw-ingress-route-secret-load-external-cert_secured-routes[Creating a route with externally managed certificate]
* xref:../../security/cert_manager_operator/cert-manager-operator-issuer-acme.adoc#cert-manager-operator-issuer-acme[Configuring an ACME issuer]
* xref:../../security/cert_manager_operator/cert-manager-operator-issuer-acme.adoc#cert-manager-operator-issuer-acme[Configuring an ACME issuer]

5
security/cert_manager_operator/index.adoc
View File

@@ -6,6 +6,7 @@ include::_attributes/common-attributes.adoc[]
toc::[]
[role="_abstract"]
The {cert-manager-operator} is a cluster-wide service that provides application certificate lifecycle management. The {cert-manager-operator} allows you to integrate with external certificate authorities and provides certificate provisioning, renewal, and retirement.
// About the {cert-manager-operator}
@@ -27,7 +28,9 @@ include::modules/cert-manager-fips-support.adoc[leveloffset=+1]
[id="cert-manager-operator-about_additional-resources"]
== Additional resources
* link:https://csrc.nist.gov/Projects/cryptographic-module-validation-program/validated-modules[Cryptographic module validation program]
* link:https://cert-manager.io/docs/[cert-manager project documentation]
* link:https://access.redhat.com/support/policy/updates/openshift_operators[{product-title} update and support policy]
* xref:../../security/container_security/security-compliance.adoc#security-compliance[Understanding compliance]
* xref:../../installing/overview/installing-fips.adoc#installing-fips-mode_installing-fips[Installing a cluster in FIPS mode]
* xref:../../installing/overview/installing-preparing.adoc#installing-preparing-security[Do you need extra security for your cluster?]
* xref:../../installing/overview/installing-preparing.adoc#installing-preparing-security[Do you need extra security for your cluster?]