Skip to content

Commit f80f0ea

Browse files
authored
Merge pull request #110361 from openshift/revert-105153-OSDOCS-16863-4RE-18
Revert "[enterprise-4.18] OSDOCS-16863-4RE: CQA for MetalLB Ingress and Route"
2 parents 7cc68da + e737baa commit f80f0ea

24 files changed

Lines changed: 149 additions & 203 deletions

microshift_networking/microshift-configuring-routes.adoc

Lines changed: 5 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -6,10 +6,7 @@ include::_attributes/attributes-microshift.adoc[]
66

77
toc::[]
88

9-
[role="_abstract"]
10-
To enable {microshift-short} node access for services, configure the cluster routes. By using this configuration, you can expose specific applications directly through the network interface of the node.
11-
12-
Secure routes provide the ability to use several types of TLS termination to serve certificates to the client. See the _Additional resources_ section for links to the {OCP} documentation that describe how to create re-encrypt, edge, and passthrough routes with custom certificates.
9+
You can configure routes for services to have {microshift-short} node access.
1310

1411
//OCP module, edit with care; Creating an insecure/http route
1512
include::modules/microshift-nw-create-http-based-route.adoc[leveloffset=+1]
@@ -53,8 +50,10 @@ include::modules/nw-ingress-edge-route-default-certificate.adoc[leveloffset=+1]
5350
//OCP module, edit with care
5451
include::modules/nw-ingress-reencrypt-route-custom-cert.adoc[leveloffset=+1]
5552

56-
[role="_additional-resources"]
57-
.Additional resources
53+
[id="microshift-secured-routes_{context}"]
54+
== Secured routes
55+
56+
Secure routes provide the ability to use several types of TLS termination to serve certificates to the client. The following links to the {OCP} documentation describe how to create re-encrypt, edge, and passthrough routes with custom certificates.
5857

5958
* link:https://docs.redhat.com/en/documentation/openshift_container_platform/{ocp-version}/html/networking/configuring-routes#nw-ingress-creating-a-reencrypt-route-with-a-custom-certificate_secured-routes[Creating a re-encrypt route with a custom certificate]
6059

modules/microshift-nw-create-http-based-route.adoc

Lines changed: 10 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -6,10 +6,7 @@
66
[id="microshift-nw-creating-a-route_{context}"]
77
= Creating an HTTP-based route
88

9-
[role="_abstract"]
10-
To host your application at a public URL by using the basic HTTP routing protocol, create an HTTP-based route. This configuration exposes a service on an unsecured application port, allowing external access without TLS encryption.
11-
12-
A route can either be secure or unsecured, depending on the network security configuration of your application.
9+
A route allows you to host your application at a public URL. It can either be secure or unsecured, depending on the network security configuration of your application. An HTTP-based route is an unsecured route that uses the basic HTTP routing protocol and exposes a service on an unsecured application port.
1310

1411
The following procedure describes how to create a simple HTTP-based route to a web application, using the `hello-microshift` application as an example.
1512

@@ -41,11 +38,11 @@ $ oc expose svc/hello-microshift --hostname=microshift.com $namespace
4138
+
4239
[source,terminal]
4340
----
44-
$ oc get routes -o yaml <name of resource> -n $namespace
41+
$ oc get routes -o yaml <name of resource> -n $namespace <1>
4542
----
46-
* `namespace`: Specifies the route that is named `hello-microshift` and the namespace is named `hello-microshift`.
47-
+
48-
.Sample YAML definition for the created unsecured route
43+
<1> In this example, the route is named `hello-microshift` and the namespace is named `hello-microshift`.
44+
45+
.Sample YAML definition of the created unsecured route:
4946
[source,yaml]
5047
----
5148
apiVersion: route.openshift.io/v1
@@ -54,20 +51,17 @@ metadata:
5451
name: hello-microshift
5552
namespace: hello-microshift
5653
spec:
57-
host: microshift.com
54+
host: microshift.com <1>
5855
port:
59-
targetPort: 8080
56+
targetPort: 8080 <2>
6057
to:
6158
kind: Service
6259
name: hello-microshift
6360
----
64-
+
65-
where:
66-
+
67-
`spec.host`:: Specifies the hostname.
68-
`port.targetPort`:: Specifies the target port for the router to map the endpoint port in the service.
61+
<1> Example hostname.
62+
<2> `targetPort` is required for the router to map the endpoint port in the service.
6963
+
7064
[NOTE]
7165
====
72-
{microshift-short} does not use an API that creates a default ingress domain, but instead provides a wildcard for automatically generated domains. Each route can also define a separate hostname.
66+
{microshift-short} does not a use an API that creates a default ingress domain, but instead provides a wildcard for automatically generated domains. Each route can also define a separate hostname.
7367
====

modules/microshift-nw-enforcing-hsts-per-domain.adoc

Lines changed: 6 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,7 @@
66
[id="microshift-nw-enforcing-hsts-per-domain_{context}"]
77
= Enforcing HTTP Strict Transport Security per-domain
88

9-
[role="_abstract"]
10-
To enforce secure communication per-domain, configure routes with a compliant HSTS policy annotation. For upgraded nodes with non-compliant routes, ensure consistent enforcement by updating the source manifests to apply the new security policies.
9+
You can configure a route with a compliant HSTS policy annotation. To handle an upgraded node with noncompliant HSTS routes, you can update the manifests at the source and apply the updates.
1110

1211
You cannot use `oc expose route` or `oc create route` commands to add a route in a domain that enforces HSTS because the API for these commands does not accept annotations.
1312

@@ -17,30 +16,28 @@ HSTS cannot be applied to insecure, or non-TLS, routes.
1716
====
1817

1918
.Prerequisites
20-
2119
* You have root access to the node.
2220
* You installed the {oc-first}.
2321
2422
.Procedure
2523

26-
* Apply HSTS to all routes in the node by running the following command:
24+
* Apply HSTS to all routes in the node by running the following `oc annotate command`:
2725
+
2826
[source,terminal]
2927
----
3028
$ oc annotate route --all --all-namespaces --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;preload;includeSubDomains"
3129
----
32-
33-
* Apply HSTS to all routes in a particular namespace by running the following command:
30+
+
31+
* Apply HSTS to all routes in a particular namespace by running the following `oc annotate command`:
3432
+
3533
[source,terminal]
3634
[subs="+quotes"]
3735
----
38-
$ oc annotate route --all -n __<my_namespace>__ --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;preload;includeSubDomains"
36+
$ oc annotate route --all -n __<my_namespace>__ --overwrite=true "haproxy.router.openshift.io/hsts_header"="max-age=31536000;preload;includeSubDomains" <1>
3937
----
40-
* `<my_namespace>`: Specify the namespace that you want to use.
38+
<1> Replace `_<my_namespace>_` with the namespace you want to use.
4139
4240
.Verification
43-
4441
* Review the HSTS annotations on all routes by running the following command:
4542
+
4643
[source,terminal]

modules/nw-annotating-a-route-with-a-cookie-name.adoc

Lines changed: 7 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -11,10 +11,7 @@
1111
[id="nw-annotating-a-route-with-a-cookie-name_{context}"]
1212
= Annotating a route with a cookie
1313

14-
[role="_abstract"]
15-
To enable applications to manage session persistence and load distribution, annotate the route with a custom cookie name. Overwriting the default cookie allows the backend application to identify and delete the specific cookie, forcing endpoint re-selection when necessary.
16-
17-
When a server is overloaded, the server tries to remove the requests from the client and redistribute the requests to other endpoints.
14+
You can set a cookie name to overwrite the default, auto-generated one for the route. This allows the application receiving route traffic to know the cookie name. Deleting the cookie can force the next request to re-choose an endpoint. The result is that if a server is overloaded, that server tries to remove the requests from the client and redistribute them.
1815

1916
.Procedure
2017

@@ -25,10 +22,12 @@ When a server is overloaded, the server tries to remove the requests from the cl
2522
$ oc annotate route <route_name> router.openshift.io/cookie_name="<cookie_name>"
2623
----
2724
+
25+
--
2826
where:
29-
+
27+
3028
`<route_name>`:: Specifies the name of the route.
3129
`<cookie_name>`:: Specifies the name for the cookie.
30+
--
3231
+
3332
For example, to annotate the route `my_route` with the cookie name `my_cookie`:
3433
+
@@ -44,9 +43,11 @@ $ oc annotate route my_route router.openshift.io/cookie_name="my_cookie"
4443
$ ROUTE_NAME=$(oc get route <route_name> -o jsonpath='{.spec.host}')
4544
----
4645
+
46+
--
4747
where:
48-
+
48+
4949
`<route_name>`:: Specifies the name of the route.
50+
--
5051

5152
. Save the cookie, and then access the route:
5253
+

modules/nw-disabling-hsts.adoc

Lines changed: 2 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,7 @@
66
[id="nw-disabling-hsts_{context}"]
77
= Disabling HTTP Strict Transport Security per-route
88

9-
[role="_abstract"]
10-
To allow unencrypted connections or troubleshoot access issues, disable HTTP Strict Transport Security (HSTS) for a specific route. Setting the `max-age` route annotation to `0` instructs browsers to stop enforcing HTTPS requirements on the route host.
9+
To disable HTTP strict transport security (HSTS) per-route, you can set the `max-age` value in the route annotation to `0`.
1110

1211
.Prerequisites
1312
ifndef::microshift[]
@@ -20,7 +19,7 @@ endif::microshift[]
2019

2120
.Procedure
2221

23-
* To disable HSTS, enter the following to set the `max-age` value in the route annotation to `0`:
22+
* To disable HSTS, set the `max-age` value in the route annotation to `0`, by entering the following command:
2423
+
2524
[source,terminal]
2625
----
@@ -33,8 +32,6 @@ You can alternatively apply the following YAML to create the config map for disa
3332
3433
[source,yaml]
3534
----
36-
kind: Route
37-
apiVersion: route.openshift.io/v1
3835
metadata:
3936
annotations:
4037
haproxy.router.openshift.io/hsts_header: max-age=0

modules/nw-enabling-hsts-per-route.adoc

Lines changed: 7 additions & 10 deletions
Original file line numberDiff line numberDiff line change
@@ -6,8 +6,7 @@
66
[id="nw-enabling-hsts-per-route_{context}"]
77
= Enabling HTTP Strict Transport Security per-route
88

9-
[role="_abstract"]
10-
To enforce secure HTTPS connections for specific applications, enable HTTP Strict Transport Security (HSTS) on a per-route basis. Applying the `haproxy.router.openshift.io/hsts_header` annotation to edge and re-encrypt routes ensures that browsers reject unencrypted traffic.
9+
HTTP strict transport security (HSTS) is implemented in the HAProxy template and applied to edge and re-encrypt routes that have the `haproxy.router.openshift.io/hsts_header` annotation.
1110

1211
.Prerequisites
1312
ifndef::microshift[]
@@ -22,7 +21,7 @@ endif::microshift[]
2221

2322
* To enable HSTS on a route, add the `haproxy.router.openshift.io/hsts_header` value to the edge-terminated or re-encrypt route. You can use the `oc annotate` tool to do this by running the following command. To properly run the command, ensure that the semicolon (`;`) in the `haproxy.router.openshift.io/hsts_header` route annotation is also surrounded by double quotation marks (`""`).
2423
+
25-
.Example `annotate` command that sets the maximum age to `31536000` ms (approximately 8.5 hours)
24+
.Example `annotate` command that sets the maximum age to `31536000` ms (approximetly 8.5 hours)
2625
[source,terminal]
2726
----
2827
$ oc annotate route <route_name> -n <namespace> --overwrite=true "haproxy.router.openshift.io/hsts_header=max-age=31536000;\
@@ -36,7 +35,7 @@ apiVersion: route.openshift.io/v1
3635
kind: Route
3736
metadata:
3837
annotations:
39-
haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload
38+
haproxy.router.openshift.io/hsts_header: max-age=31536000;includeSubDomains;preload <1> <2> <3>
4039
# ...
4140
spec:
4241
host: def.abc.com
@@ -46,9 +45,7 @@ spec:
4645
wildcardPolicy: "Subdomain"
4746
# ...
4847
----
49-
+
50-
where:
51-
+
52-
`max-age`:: Specifies the measurement of the length of time, in seconds, for the HSTS policy. If set to `0`, it negates the policy.
53-
`includeSubDomains`:: Specifies that all subdomains of the host must have the same HSTS policy as the host. Optional parameter.
54-
`preload`:: Specifies that the site is included in the HSTS preload list when `max-age` is greater than `0`. For example, sites such as Google can construct a list of sites that have `preload` set. Browsers can then use these lists to determine which sites they can communicate with over HTTPS, even before they have interacted with the site. Without `preload` set, browsers must have interacted with the site over HTTPS, at least once, to get the header. Optional parameter.
48+
<1> Required. `max-age` measures the length of time, in seconds, that the HSTS policy is in effect. If set to `0`, it negates the policy.
49+
<2> Optional. When included, `includeSubDomains` tells the client
50+
that all subdomains of the host must have the same HSTS policy as the host.
51+
<3> Optional. When `max-age` is greater than 0, you can add `preload` in `haproxy.router.openshift.io/hsts_header` to allow external services to include this site in their HSTS preload lists. For example, sites such as Google can construct a list of sites that have `preload` set. Browsers can then use these lists to determine which sites they can communicate with over HTTPS, even before they have interacted with the site. Without `preload` set, browsers must have interacted with the site over HTTPS, at least once, to get the header.

modules/nw-enabling-hsts.adoc

Lines changed: 1 addition & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -7,8 +7,7 @@
77
[id="nw-enabling-hsts_{context}"]
88
= HTTP Strict Transport Security
99

10-
[role="_abstract"]
11-
To enhance security and optimize website performance, use the HTTP Strict Transport Security (HSTS) policy. This mechanism signals browsers to use only HTTPS traffic on the route host, eliminating the need for HTTP redirects and speeding up user interactions.
10+
HTTP Strict Transport Security (HSTS) policy is a security enhancement, which signals to the browser client that only HTTPS traffic is allowed on the route host. HSTS also optimizes web traffic by signaling HTTPS transport is required, without using HTTP redirects. HSTS is useful for speeding up interactions with websites.
1211

1312
When HSTS policy is enforced, HSTS adds a Strict Transport Security header to HTTP and HTTPS responses from the site. You can use the `insecureEdgeTerminationPolicy` value in a route to redirect HTTP to HTTPS. When HSTS is enforced, the client changes all requests from the HTTP URL to HTTPS before the request is sent, eliminating the need for a redirect.
1413

modules/nw-http-header-configuration.adoc

Lines changed: 7 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -7,16 +7,12 @@
77
[id="nw-http-header-configuration_{context}"]
88
= HTTP header configuration
99

10-
[role="_abstract"]
1110
ifndef::microshift[]
12-
To customize request and response headers for your applications, configure the Ingress Controller or apply specific route annotations. Understanding the interaction between these configuration methods ensures you effectively manage global and route-specific header policies.
13-
14-
You can also set certain headers by using route annotations. The various ways of configuring headers can present challenges when working together.
11+
{product-title} provides different methods for working with HTTP headers. When setting or deleting headers, you can use specific fields in the Ingress Controller or an individual route to modify request and response headers. You can also set certain headers by using route annotations. The various ways of configuring headers can present challenges when working together.
1512
endif::microshift[]
16-
ifdef::microshift[]
17-
To customize request and response headers, modify individual route configurations or apply route annotations. Understanding the interaction between these methods ensures you effectively manage header policies and resolve potential configuration conflicts.
1813

19-
The various ways of configuring headers can present challenges when working together.
14+
ifdef::microshift[]
15+
When setting or deleting headers, you can use an individual route to modify request and response headers. You can also set certain headers by using route annotations. The various ways of configuring headers can present challenges when working together.
2016
endif::microshift[]
2117

2218
ifndef::microshift[]
@@ -34,7 +30,8 @@ You can only set or delete headers within a `Route` CR. You cannot append header
3430
endif::microshift[]
3531

3632
ifndef::microshift[]
37-
Order of precedence::
33+
[id="nw-http-header-configuration-order_{context}"]
34+
== Order of precedence
3835

3936
When the same HTTP header is modified both in the Ingress Controller and in a route, HAProxy prioritizes the actions in certain ways depending on whether it is a request or response header.
4037

@@ -107,7 +104,8 @@ ifdef::microshift[]
107104
Any actions defined in a route override values set using route annotations.
108105
endif::microshift[]
109106

110-
Special case headers::
107+
[id="nw-http-header-configuration-special-cases_{context}"]
108+
== Special case headers
111109

112110
The following headers are either prevented entirely from being set or deleted, or allowed under specific circumstances:
113111

0 commit comments

Comments
 (0)