You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/customize-certificates-replace-default-router.adoc
+19-30Lines changed: 19 additions & 30 deletions
Original file line number
Diff line number
Diff line change
@@ -6,38 +6,28 @@
6
6
[id="replacing-default-ingress_{context}"]
7
7
= Replacing the default ingress certificate
8
8
9
-
You can replace the default ingress certificate for all
10
-
applications under the `.apps` subdomain. After you replace
11
-
the certificate, all applications, including the web console
12
-
and CLI, will have encryption provided by specified certificate.
9
+
You can replace the default ingress certificate for all applications under the `.apps` subdomain. After you replace the certificate, all applications, including the web console and CLI, have encryption provided by the specified certificate.
13
10
14
11
.Prerequisites
15
12
16
-
* You must have a wildcard certificate for the fully qualified `.apps` subdomain
17
-
and its corresponding private key. Each should be in a separate PEM format file.
18
-
* The private key must be unencrypted. If your key is encrypted, decrypt it
19
-
before importing it into {product-title}.
20
-
* The certificate must include the `subjectAltName` extension showing
21
-
`*.apps.<clustername>.<domain>`.
22
-
* The certificate file can contain one or more certificates in a chain. The
23
-
wildcard certificate must be the first certificate in the file. It can then be
24
-
followed with any intermediate certificates, and the file should end with the
25
-
root CA certificate.
13
+
* You must have a wildcard certificate for the fully qualified `.apps` subdomain and its corresponding private key. Each should be in a separate PEM format file.
14
+
* The private key must be unencrypted. If your key is encrypted, decrypt it before importing it into {product-title}.
15
+
* The certificate must include the `subjectAltName` extension showing `*.apps.<clustername>.<domain>`.
16
+
* The certificate file can contain one or more certificates in a chain. The file must list the wildcard certificate as the first certificate, followed by other intermediate certificates, and then ending with the root CA certificate.
26
17
* Copy the root CA certificate into an additional PEM format file.
27
-
* Verify that all certificates which include `-----END CERTIFICATE-----` also
28
-
end with one carriage return after that line.
18
+
* Verify that all certificates which include `-----END CERTIFICATE-----` also end with one carriage return after that line.
29
19
30
20
.Procedure
31
21
32
-
. Create a config map that includes only the root CA certificate used to sign the wildcard certificate:
22
+
. Create a config map that includes only the root CA certificate that is used to sign the wildcard certificate:
<1> `</path/to/example-ca.crt>` is the path to the root CA certificate file on your local file system.
30
+
<1> `</path/to/example-ca.crt>` is the path to the root CA certificate file on your local file system. For example, `/etc/pki/ca-trust/source/anchors`.
41
31
42
32
. Update the cluster-wide proxy configuration with the newly created config map:
If you update only the trusted CA for your cluster, the MCO updates the `/etc/pki/ca-trust/source/anchors/openshift-config-user-ca-bundle.crt` file and the Machine Config Controller (MCC) applies the trusted CA update to each node so that a node reboot is not required. Changing any other parameter in the `openshift-config-user-ca-bundle.crt` file, such as `noproxy`, results in the MCO rebooting each node in your cluster.
44
+
====
50
45
51
46
. Create a secret that contains the wildcard certificate chain and key:
<1> Replace `<secret>` with the name used for the secret in
78
-
the previous step.
68
+
<1> Replace `<secret>` with the name used for the secret in the previous step.
79
69
+
80
70
[IMPORTANT]
81
71
====
82
72
To trigger the Ingress Operator to perform a rolling update, you must update the name of the secret.
83
-
Because the kubelet automatically propagates changes to the secret in the volume mount, updating the secret contents does not trigger a rolling update.
84
-
For more information, see this link:https://access.redhat.com/solutions/4542531[Red{nbsp}Hat Knowledgebase Solution].
73
+
Because the kubelet automatically propagates changes to the secret in the volume mount, updating the secret contents does not trigger a rolling update. For more information, see this link:https://access.redhat.com/solutions/4542531[Red{nbsp}Hat Knowledgebase Solution].
Copy file name to clipboardExpand all lines: modules/nw-proxy-configure-object.adoc
+13-13Lines changed: 13 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -7,7 +7,7 @@
7
7
[id="nw-proxy-configure-object_{context}"]
8
8
= Enabling the cluster-wide proxy
9
9
10
-
The `Proxy` object is used to manage the cluster-wide egress proxy. When a cluster is installed or upgraded without the proxy configured, a `Proxy` object is still generated but it will have a nil `spec`. For example:
10
+
The `Proxy` object is used to manage the cluster-wide egress proxy. When a cluster is installed or upgraded without the proxy configured, a `Proxy` object is still generated but it has a nil `spec`. For example:
11
11
12
12
[source,yaml]
13
13
----
@@ -21,16 +21,16 @@ spec:
21
21
status:
22
22
----
23
23
24
-
A cluster administrator can configure the proxy for {product-title} by modifying this `cluster``Proxy` object.
25
-
26
24
[NOTE]
27
25
====
28
26
Only the `Proxy` object named `cluster` is supported, and no additional proxies can be created.
29
27
====
30
28
29
+
A cluster administrator can configure the proxy for {product-title} by modifying the `cluster``Proxy` object.
30
+
31
31
[WARNING]
32
32
====
33
-
Enabling the cluster-wide proxy causes the Machine Config Operator (MCO) to trigger node reboot.
33
+
After you enable the cluster-wide proxy capability for your cluster and you save the `Proxy` object file, the Machine Config Operator (MCO) reboots all nodes in your cluster so that each node can access connections that exist outside of the cluster. You do not need to manually reboot these nodes.
34
34
====
35
35
36
36
.Prerequisites
@@ -44,10 +44,10 @@ Enabling the cluster-wide proxy causes the Machine Config Operator (MCO) to trig
44
44
+
45
45
[NOTE]
46
46
====
47
-
You can skip this step if the proxy's identity certificate is signed by an authority from the RHCOS trust bundle.
47
+
You can skip this step if the identity certificate of the proxy is signed by an authority from the {op-system-first} trust bundle.
48
48
====
49
49
50
-
.. Create a file called `user-ca-bundle.yaml` with the following contents, and provide the values of your PEM-encoded certificates:
50
+
.. Create a file called `user-ca-bundle.yaml`, and provide the values of your PEM-encoded certificates:
51
51
+
52
52
[source,yaml]
53
53
----
@@ -63,10 +63,10 @@ metadata:
63
63
<1> This data key must be named `ca-bundle.crt`.
64
64
<2> One or more PEM-encoded X.509 certificates used to sign the proxy's
65
65
identity certificate.
66
-
<3> The config map name that will be referenced from the `Proxy` object.
67
-
<4> The config map must be in the `openshift-config` namespace.
66
+
<3> The config map name that is referenced from the `Proxy` object.
67
+
<4> The config map must exist in the `openshift-config` namespace.
68
68
69
-
.. Create the config map from this file:
69
+
.. Create the config map from the `user-ca-bundle.yaml` file by entering the following command:
70
70
+
71
71
[source,terminal]
72
72
----
@@ -101,7 +101,7 @@ spec:
101
101
+
102
102
--
103
103
<1> A proxy URL to use for creating HTTP connections outside the cluster. The URL scheme must be `http`.
104
-
<2> A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either `http` or `https`. Specify a URL for the proxy that supports the URL scheme. For example, most proxies will report an error if they are configured to use `https` but they only support `http`. This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens for `https` connections from the cluster, you may need to configure the cluster to accept the CAs and certificates that the proxy uses.
104
+
<2> A proxy URL to use for creating HTTPS connections outside the cluster. The URL scheme must be either `http` or `https`. Specify a URL for the proxy that supports the URL scheme. For example, most proxies report an error if they are configured to use `https` but they only support `http`. This failure message may not propagate to the logs and can appear to be a network connection failure instead. If using a proxy that listens for `https` connections from the cluster, you might need to configure the cluster to accept the CAs and certificates that the proxy uses.
105
105
<3> A comma-separated list of destination domain names, domains, IP addresses (or other network CIDRs), and port numbers to exclude proxying.
106
106
+
107
107
[NOTE]
@@ -112,13 +112,13 @@ Port numbers are only supported when configuring IPv6 addresses. Port numbers ar
112
112
Preface a domain with `.` to match subdomains only. For example, `.y.com` matches `x.y.com`, but not `y.com`. Use `*` to bypass proxy for all destinations.
113
113
+
114
114
If your `noproxy` field needs to include a domain address, you must explicitly specify that FQDN, or prefix-matched subdomain, in the `noproxy` field. You cannot use the IP address or CIDR range that encapsulates the domain. This is because the cluster does not wait for DNS to return the IP address before assigning the route connection, and checks explicitly against the request being made.
115
-
For example, if you have a CIDR block value, such as `10.0.0.0/24`, for the `noproxy` field and attempt to access `\https://10.0.0.11`, it will match successfully. However, attempting to access `\https://exampleserver.externaldomain.com`, whose A record entry is `10.0.0.11`, will fail. An additional value of `.externaldomain.com` for your `noproxy` field is necessary.
115
+
For example, if you have a CIDR block value, such as `10.0.0.0/24`, for the `noproxy` field and the field attempts to access `\https://10.0.0.11`, the addresses successfully match. However, attempting to access `\https://exampleserver.externaldomain.com`, whose A record entry is `10.0.0.11`, fails. An additional value of `.externaldomain.com` for your `noproxy` field is necessary.
116
116
+
117
-
If you scale up workers that are not included in the network defined by the `networking.machineNetwork[].cidr` field from the installation configuration, you must add them to this list to prevent connection issues.
117
+
If you scale up compute nodes that are not included in the network defined by the `networking.machineNetwork[].cidr` field from the installation configuration, you must add them to this list to prevent connection issues.
118
118
+
119
119
This field is ignored if neither the `httpProxy` or `httpsProxy` fields are set.
120
120
<4> One or more URLs external to the cluster to use to perform a readiness check before writing the `httpProxy` and `httpsProxy` values to status.
121
-
<5> A reference to the config map in the `openshift-config` namespace that contains additional CA certificates required for proxying HTTPS connections. Note that the config map must already exist before referencing it here. This field is required unless the proxy's identity certificate is signed by an authority from the RHCOS trust bundle.
121
+
<5> A reference to the config map in the `openshift-config` namespace that contains additional CA certificates required for proxying HTTPS connections. Note that the config map must already exist before referencing it here. This field is required unless the proxy's identity certificate is signed by an authority from the {op-system} trust bundle.
0 commit comments