Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 9. Creating secure HTTP load balancers

You can create various types of load balancers to manage secure HTTP (HTTPS) network traffic.

9.1. About non-terminated HTTPS load balancers

A non-terminated HTTPS load balancer acts effectively like a generic TCP load balancer: the load balancer forwards the raw TCP traffic from the web client to the back-end servers where the HTTPS connection is terminated with the web clients. While non-terminated HTTPS load balancers do not support advanced load balancer features like Layer 7 functionality, they do lower load balancer resource utilization by managing the certificates and keys themselves.

9.2. Creating a non-terminated HTTPS load balancer

If your application requires HTTPS traffic to terminate on the back-end member servers, typically called HTTPS pass through, you can use the HTTPS protocol for your load balancer listeners.

Prerequisites

A shared external (public) subnet that you can reach from the internet.

Procedure

Source your credentials file.
Example
```
$ source ~/overcloudrc
```
Create a load balancer (lb1) on a public subnet (public_subnet).
Note
Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
```
$ openstack loadbalancer create --name lb1 \
--vip-subnet-id public_subnet --wait
```

Create a listener (listener1) on a port (443).

Example

$ openstack loadbalancer listener create --name listener1 \
--protocol HTTPS --protocol-port 443 lb1

Create the listener default pool (pool1).
Example
The command in this example creates an HTTPS pool that uses a private subnet containing back-end servers that host HTTPS applications configured with a TLS-encrypted web application on TCP port 443:
```
$ openstack loadbalancer pool create --name pool1 \
--lb-algorithm ROUND_ROBIN --listener listener1 \
--protocol HTTPS
```
Create a health monitor (healthmon1) on the pool (pool1) of type (TLS-HELLO) that connects to the back-end servers and tests the path (/).
Health checks are recommended but not required. If no health monitor is defined, the member server is assumed to be ONLINE.
Example
```
$ openstack loadbalancer healthmonitor create --name healthmon1 \
--delay 15 --max-retries 4 --timeout 10 --type TLS-HELLO \
--url-path / pool1
```

Add load balancer members (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the default pool.

Example

In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2, respectively:

$ openstack loadbalancer member create --name member1 --subnet-id \
private_subnet --address 192.0.2.10 --protocol-port 443 pool1

$ openstack loadbalancer member create --name member2 --subnet-id \
private_subnet --address 192.0.2.11 --protocol-port 443 pool1

Verification

View and verify the load balancer (lb1) settings.

Example

$ openstack loadbalancer show lb1

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| description         |                                      |
| flavor              |                                      |
| id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
| listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
| name                | lb1                                  |
| operating_status    | ONLINE                               |
| pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| provider            | amphora                              |
| provisioning_status | ACTIVE                               |
| updated_at          | 2022-01-15T11:12:42                  |
| vip_address         | 198.51.100.11                        |
| vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
| vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
| vip_qos_policy_id   | None                                 |
| vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
+---------------------+--------------------------------------+

When a health monitor is present and functioning properly, you can check the status of each member.

Example

A working member (member1) has an ONLINE value for its operating_status.

$ openstack loadbalancer member show pool1 member1

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| address             | 192.0.2.10                           |
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
| name                | member1                              |
| operating_status    | ONLINE                               |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| protocol_port       | 443                                  |
| provisioning_status | ACTIVE                               |
| subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
| updated_at          | 2022-01-15T11:12:42                  |
| weight              | 1                                    |
| monitor_port        | None                                 |
| monitor_address     | None                                 |
| backup              | False                                |
+---------------------+--------------------------------------+

Additional resources

Managing secrets with the Key Manager service guide
loadbalancer in the Command line interface reference

9.3. About TLS-terminated HTTPS load balancers

When a TLS-terminated HTTPS load balancer is implemented, web clients communicate with the load balancer over Transport Layer Security (TLS) protocols. The load balancer terminates the TLS session and forwards the decrypted requests to the back-end servers. When you terminate the TLS session on the load balancer, you offload the CPU-intensive encryption operations to the load balancer, and allow the load balancer to use advanced features such as Layer 7 inspection.

9.4. Creating a TLS-terminated HTTPS load balancer

Prerequisites

A shared external (public) subnet that you can reach from the internet.
TLS public-key cryptography is configured with the following characteristics:
- A TLS certificate, key, and intermediate certificate chain is obtained from an external certificate authority (CA) for the DNS name that is assigned to the load balancer VIP address, for example, www.example.com.
- The certificate, key, and intermediate certificate chain reside in separate files in the current directory.
- The key and certificate are PEM-encoded.
- The intermediate certificate chain contains multiple certificates that are PEM-encoded and concatenated together.
You must configure the Load-balancing service (octavia) to use the Key Manager service (barbican). For more information, see the Managing secrets with the Key Manager service guide.

Procedure

Combine the key (server.key), certificate (server.crt), and intermediate certificate chain (ca-chain.crt) into a single PKCS12 file (server.p12).
Note
Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
```
$ openssl pkcs12 -export -inkey server.key -in server.crt \
-certfile ca-chain.crt -passout pass: -out server.p12
```
Note
The following procedure does not work if you password protect the PKCS12 file.
Source your credentials file.
Example
```
$ source ~/overcloudrc
```

Use the Key Manager service to create a secret resource (tls_secret1) for the PKCS12 file.

Example

$ openstack secret store --name='tls_secret1' \
-t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < server.p12)"

Create a load balancer (lb1) on the public subnet (public_subnet).

Example

$ openstack loadbalancer create --name lb1 \
--vip-subnet-id public_subnet --wait

Create a TERMINATED_HTTPS listener (listener1), and reference the secret resource as the default TLS container for the listener.

Example

$ openstack loadbalancer listener create --protocol-port 443 \
--protocol TERMINATED_HTTPS \
--default-tls-container=\
$(openstack secret list | awk '/ tls_secret1 / {print $2}') lb1

Create a pool (pool1) and make it the default pool for the listener.
Example
The command in this example creates an HTTP pool that uses a private subnet containing back-end servers that host non-secure HTTP applications on TCP port 80:
```
$ openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
```
Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).
Health checks are recommended but not required. If no health monitor is defined, the member server is assumed to be ONLINE.
Example
```
$ openstack loadbalancer healthmonitor create --name healthmon1 \
--delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1
```

Add the non-secure HTTP back-end servers (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool.

Example

In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2, respectively:

$ openstack loadbalancer member create --name member1 --subnet-id \
private_subnet --address 192.0.2.10 --protocol-port 443 pool1

$ openstack loadbalancer member create --name member2 --subnet-id \
private_subnet --address 192.0.2.11 --protocol-port 443 pool1

Verification

View and verify the load balancer (lb1) settings.

Example

$ openstack loadbalancer show lb1

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| description         |                                      |
| flavor              |                                      |
| id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
| listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
| name                | lb1                                  |
| operating_status    | ONLINE                               |
| pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| provider            | amphora                              |
| provisioning_status | ACTIVE                               |
| updated_at          | 2022-01-15T11:12:42                  |
| vip_address         | 198.51.100.11                        |
| vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
| vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
| vip_qos_policy_id   | None                                 |
| vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
+---------------------+--------------------------------------+

When a health monitor is present and functioning properly, you can check the status of each member.

Example

$ openstack loadbalancer member show pool1 member1

A working member (member1) has an ONLINE value for its operating_status:

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| address             | 192.0.2.10                           |
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
| name                | member1                              |
| operating_status    | ONLINE                               |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| protocol_port       | 80                                   |
| provisioning_status | ACTIVE                               |
| subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
| updated_at          | 2022-01-15T11:12:42                  |
| weight              | 1                                    |
| monitor_port        | None                                 |
| monitor_address     | None                                 |
| backup              | False                                |
+---------------------+--------------------------------------+

Additional resources

Managing secrets with the Key Manager service guide
loadbalancer in the Command line interface reference

9.5. Creating a TLS-terminated HTTPS load balancer with SNI

For TLS-terminated HTTPS load balancers that employ Server Name Indication (SNI) technology, a single listener can contain multiple TLS certificates and enable the load balancer to know which certificate to present when it uses a shared IP. It is a best practice to also create a health monitor to ensure that your back-end members remain available.

Prerequisites

A shared external (public) subnet that you can reach from the internet.
TLS public-key cryptography is configured with the following characteristics:
- Multiple TLS certificates, keys, and intermediate certificate chains have been obtained from an external certificate authority (CA) for the DNS names assigned to the load balancer VIP address, for example, www.example.com and www2.example.com.
- The keys and certificates are PEM-encoded.
You must configure the Load-balancing service (octavia) to use the Key Manager service (barbican). For more information, see the Managing secrets with the Key Manager service guide.

Procedure

For each of the TLS certificates in the SNI list, combine the key (server.key), certificate (server.crt), and intermediate certificate chain (ca-chain.crt) into a single PKCS12 file (server.p12).
In this example, you create two PKCS12 files (server.p12 and server2.p12) one for each certificate (www.example.com and www2.example.com).
Note
Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
```
$ openssl pkcs12 -export -inkey server.key -in server.crt \
-certfile ca-chain.crt -passout pass: -out server.p12

$ openssl pkcs12 -export -inkey server2.key -in server2.crt \
-certfile ca-chain2.crt -passout pass: -out server2.p12
```
Source your credentials file.
Example
```
$ source ~/overcloudrc
```

Use the Key Manager service to create secret resources (tls_secret1 and tls_secret2) for the PKCS12 file.

Example

$ openstack secret store --name='tls_secret1' \
-t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < server.p12)"

$ openstack secret store --name='tls_secret2' \
-t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < server2.p12)"

Create a load balancer (lb1) on the public subnet (public_subnet).

Example

$ openstack loadbalancer create --name lb1 \
--vip-subnet-id public_subnet --wait

Create a TERMINATED_HTTPS listener (listener1), and use SNI to reference both the secret resources.

(Reference tls_secret1 as the default TLS container for the listener.)

Example

$ openstack loadbalancer listener create  --name listener1 \
--protocol-port 443 --protocol TERMINATED_HTTPS \
--default-tls-container=\
$(openstack secret list | awk '/ tls_secret1 / {print $2}') \
--sni-container-refs \
$(openstack secret list | awk '/ tls_secret1 / {print $2}') \
$(openstack secret list | awk '/ tls_secret2 / {print $2}') -- lb1

Create a pool (pool1) and make it the default pool for the listener.
Example
The command in this example creates an HTTP pool that uses a private subnet containing back-end servers that host non-secure HTTP applications on TCP port 80:
```
$ openstack loadbalancer pool create --name pool1 \
--lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
```
Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).
Health checks are recommended but not required. If no health monitor is defined, the member server is assumed to be ONLINE.
Example
```
$ openstack loadbalancer healthmonitor create --name healthmon1 \
--delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1
```

Add the non-secure HTTP back-end servers (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool.

Example

In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2, respectively:

$ openstack loadbalancer member create --name member1 --subnet-id \
private_subnet --address 192.0.2.10 --protocol-port 443 pool1

$ openstack loadbalancer member create --name member2 --subnet-id \
private_subnet --address 192.0.2.11 --protocol-port 443 pool1

Verification

View and verify the load balancer (lb1) settings.

Example

$ openstack loadbalancer show lb1

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| description         |                                      |
| flavor              |                                      |
| id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
| listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
| name                | lb1                                  |
| operating_status    | ONLINE                               |
| pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| provider            | amphora                              |
| provisioning_status | ACTIVE                               |
| updated_at          | 2022-01-15T11:12:42                  |
| vip_address         | 198.51.100.11                        |
| vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
| vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
| vip_qos_policy_id   | None                                 |
| vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
+---------------------+--------------------------------------+

When a health monitor is present and functioning properly, you can check the status of each member.

Example

$ openstack loadbalancer member show pool1 member1

Sample output

A working member (member1) has an ONLINE value for its operating_status:

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| address             | 192.0.2.10                           |
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
| name                | member1                              |
| operating_status    | ONLINE                               |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| protocol_port       | 80                                   |
| provisioning_status | ACTIVE                               |
| subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
| updated_at          | 2022-01-15T11:12:42                  |
| weight              | 1                                    |
| monitor_port        | None                                 |
| monitor_address     | None                                 |
| backup              | False                                |
+---------------------+--------------------------------------+

Additional resources

Managing secrets with the Key Manager service guide
loadbalancer in the Command line interface reference

9.6. Creating a TLS-terminated load balancer with an HTTP/2 listener

When you use TLS-terminated HTTPS load balancers, you offload the CPU-intensive encryption operations to the load balancer, and allow the load balancer to use advanced features such as Layer 7 inspection. With the addition of an HTTP/2 listener, you can leverage the HTTP/2 protocol to improve performance by loading pages faster. Load balancers negotiate HTTP/2 with clients by using the Application-Layer Protocol Negotiation (ALPN) TLS extension.

The Load-balancing service (octavia) supports end-to-end HTTP/2 traffic, which means that the HTTP2 traffic is not translated by HAProxy from the point where the request reaches the listener until the response returns from the load balancer. To achieve end-to-end HTTP/2 traffic, you must have an HTTP pool with back-end re-encryption: pool members that are listening on a secure port and web applications that are configured for HTTPS traffic.

You can send HTTP/2 traffic to an HTTP pool without back-end re-encryption. In this situation, HAProxy translates the traffic before it reaches the pool, and the response is translated back to HTTP/2 before it returns from the load balancer.

Red Hat recommends that you create a health monitor to ensure that your back-end members remain available.

Note

Currently, the Load-balancing service does not support health monitoring for TLS-terminated load balancers that use HTTP/2 listeners.

Prerequisites

TLS public-key cryptography is configured with the following characteristics:
- A TLS certificate, key, and intermediate certificate chain is obtained from an external certificate authority (CA) for the DNS name that is assigned to the load balancer VIP address, for example, www.example.com.
- The certificate, key, and intermediate certificate chain reside in separate files in the current directory.
- The key and certificate are PEM-encoded.
- The intermediate certificate chain contains multiple certificates that are PEM-encoded and concatenated together.
You must configure the Load-balancing service (octavia) to use the Key Manager service (barbican). For more information, see the Managing secrets with the Key Manager service guide.

Procedure

Combine the key (server.key), certificate (server.crt), and intermediate certificate chain (ca-chain.crt) into a single PKCS12 file (server.p12).
Note
Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Important
When you create the PKCS12 file, do not password protect the file.
Example
In this example, the PKCS12 file is created without a password:
```
$ openssl pkcs12 -export -inkey server.key -in server.crt \
-certfile ca-chain.crt -passout pass: -out server.p12
```
Source your credentials file.
Example
```
$ source ~/overcloudrc
```

Use the Key Manager service to create a secret resource (tls_secret1) for the PKCS12 file.

Example

$ openstack secret store --name='tls_secret1' \
-t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < server.p12)"

Create a load balancer (lb1) on the public subnet (public_subnet).

Example

$ openstack loadbalancer create --name lb1 --vip-subnet-id \
public_subnet --wait

Create a TERMINATED_HTTPS listener (listener1) and do the following:
- reference the secret resource (tls_secret1) as the default TLS container for the listener.
- set the ALPN protocol (h2).
- set the fallback protocol if the client does not support HTTP/2 (http/1.1).
  Example
```
$ openstack loadbalancer listener create --name listener1 \
--protocol-port 443 --protocol TERMINATED_HTTPS --alpn-protocol h2 \
--alpn-protocol http/1.1 --default-tls-container=\
$(openstack secret list | awk '/ tls_secret1 / {print $2}') lb1
```
Create a pool (pool1) and make it the default pool for the listener.
Example
The command in this example creates an HTTP pool containing back-end servers that host HTTP applications configured with a web application on TCP port 80:
```
$ openstack loadbalancer pool create --name pool1 \
--lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
```
Create a health monitor (healthmon1) of type (TCP) on the pool (pool1) that connects to the back-end servers.
Health checks are recommended but not required. If no health monitor is defined, the member server is assumed to be ONLINE.
Example
```
$ openstack loadbalancer healthmonitor create --name healthmon1 \
--delay 15  --max-retries 4 --timeout 10 --type TCP pool1
```

Add the HTTP back-end servers (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool.

Example

In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2, respectively:

$ openstack loadbalancer member create --name member1 --subnet-id \
private_subnet --address 192.0.2.10 --protocol-port 80 pool1

$ openstack loadbalancer member create --name member2 --subnet-id \
private_subnet --address 192.0.2.11 --protocol-port 80 pool1

Verification

View and verify the load balancer (lb1) settings.

Example

$ openstack loadbalancer status show lb1

Sample output

{
    "loadbalancer": {
        "id": "936dad29-4c3f-4f24-84a8-c0e6f10ed810",
        "name": "lb1",
        "operating_status": "ONLINE",
        "provisioning_status": "ACTIVE",
        "listeners": [
            {
                "id": "708b82c6-8a6b-4ec1-ae53-e619769821d4",
                "name": "listener1",
                "operating_status": "ONLINE",
                "provisioning_status": "ACTIVE",
                "pools": [
                    {
                        "id": "5ad7c678-23af-4422-8edb-ac3880bd888b",
                        "name": "pool1",
                        "provisioning_status": "ACTIVE",
                        "operating_status": "ONLINE",
                        "health_monitor": {
                            "id": "4ad786ef-6661-4e31-a325-eca07b2b3dd1",
                            "name": "healthmon1",
                            "type": "TCP",
                            "provisioning_status": "ACTIVE",
                            "operating_status": "ONLINE"
                        },
                        "members": [
                            {
                                "id": "facca0d3-61a7-4b46-85e8-da6994883647",
                                "name": "member1",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "192.0.2.10",
                                "protocol_port": 80
                            },
                            {
                                "id": "2b0d9e0b-8e0c-48b8-aa57-90b2fde2eae2",
                                "name": "member2",
                                "operating_status": "ONLINE",
                                "provisioning_status": "ACTIVE",
                                "address": "192.0.2.11",
                                "protocol_port": 80
                            }
...

When a health monitor is present and functioning properly, you can check the status of each member.

Example

$ openstack loadbalancer member show pool1 member1

Sample output

A working member (member1) has an ONLINE value for its operating_status:

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| address             | 192.0.2.10                           |
| admin_state_up      | True                                 |
| created_at          | 2023-11-16T20:08:01                  |
| id                  | facca0d3-61a7-4b46-85e8-da6994883647 |
| name                | member1                              |
| operating_status    | ONLINE                               |
| project_id          | 9b29c91f67314bd09eda9018616851cf     |
| protocol_port       | 80                                   |
| provisioning_status | ACTIVE                               |
| subnet_id           | 3b459c95-64d2-4cfa-b348-01aacc4b3fa9 |
| updated_at          | 2023-11-16T20:08:42                  |
| weight              | 1                                    |
| monitor_port        | None                                 |
| monitor_address     | None                                 |
| backup              | False                                |
| tags                |                                      |
+---------------------+--------------------------------------+

Additional resources

Managing secrets with the Key Manager service guide
loadbalancer in the Command line interface reference

9.7. Creating HTTP and TLS-terminated HTTPS load balancing on the same IP and back-end

You can configure a non-secure listener and a TLS-terminated HTTPS listener on the same load balancer and the same IP address when you want to respond to web clients with the exact same content, regardless if the client is connected with a secure or non-secure HTTP protocol. It is a best practice to also create a health monitor to ensure that your back-end members remain available.

Prerequisites

A shared external (public) subnet that you can reach from the internet.
TLS public-key cryptography is configured with the following characteristics:
- A TLS certificate, key, and optional intermediate certificate chain have been obtained from an external certificate authority (CA) for the DNS name assigned to the load balancer VIP address (for example, www.example.com).
- The certificate, key, and intermediate certificate chain reside in separate files in the current directory.
- The key and certificate are PEM-encoded.
- The intermediate certificate chain contains multiple certificates that are PEM-encoded and concatenated together.
You have configured the Load-balancing service (octavia) to use the Key Manager service (barbican). For more information, see the Managing secrets with the Key Manager service guide.
The non-secure HTTP listener is configured with the same pool as the HTTPS TLS-terminated load balancer.

Procedure

Combine the key (server.key), certificate (server.crt), and intermediate certificate chain (ca-chain.crt) into a single PKCS12 file (server.p12).
Note
Values inside parentheses are sample values that are used in the example commands in this procedure. Substitute these sample values with values that are appropriate for your site.
Example
```
$ openssl pkcs12 -export -inkey server.key -in server.crt \
-certfile ca-chain.crt -passout pass: -out server.p12
```
Source your credentials file.
Example
```
$ source ~/overcloudrc
```

Use the Key Manager service to create a secret resource (tls_secret1) for the PKCS12 file.

Example

$ openstack secret store --name='tls_secret1' \
-t 'application/octet-stream' -e 'base64' \
--payload="$(base64 < server.p12)"

Create a load balancer (lb1) on the public subnet (public_subnet).

Example

$ openstack loadbalancer create --name lb1 \
--vip-subnet-id external_subnet --wait

Create a TERMINATED_HTTPS listener (listener1), and reference the secret resource as the default TLS container for the listener.

Example

$ openstack loadbalancer listener create --name listener1 \
--protocol-port 443 --protocol TERMINATED_HTTPS \
--default-tls-container=\
$(openstack secret list | awk '/ tls_secret1 / {print $2}') lb1

Create a pool (pool1) and make it the default pool for the listener.
Example
The command in this example creates an HTTP pool that uses a private subnet containing back-end servers that host non-secure HTTP applications on TCP port 80:
```
$ openstack loadbalancer pool create --name pool1 \
--lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
```
Create a health monitor (healthmon1) of type (HTTP) on the pool (pool1) that connects to the back-end servers and tests the path (/).
Health checks are recommended but not required. If no health monitor is defined, the member server is assumed to be ONLINE.
Example
```
$ openstack loadbalancer healthmonitor create --name healthmon1 \
--delay 15 --max-retries 4 --timeout 10 --type HTTP --url-path / pool1
```

Add the non-secure HTTP back-end servers (192.0.2.10 and 192.0.2.11) on the private subnet (private_subnet) to the pool.

Example

In this example, the back-end servers, 192.0.2.10 and 192.0.2.11, are named member1 and member2, respectively:

$ openstack loadbalancer member create --name member1 --subnet-id \
private_subnet --address 192.0.2.10 --protocol-port 443 pool1

$ openstack loadbalancer member create --name member2 --subnet-id \
private_subnet --address 192.0.2.11 --protocol-port 443 pool1

Create a non-secure, HTTP listener (listener2), and make its default pool, the same as the secure listener.

Example

$ openstack loadbalancer listener create --name listener2 \
--protocol-port 80 --protocol HTTP --default-pool pool1 lb1

Verification

View and verify the load balancer (lb1) settings.

Example

$ openstack loadbalancer show lb1

Sample output

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| description         |                                      |
| flavor              |                                      |
| id                  | 788fe121-3dec-4e1b-8360-4020642238b0 |
| listeners           | 09f28053-fde8-4c78-88b9-0f191d84120e |
| name                | lb1                                  |
| operating_status    | ONLINE                               |
| pools               | 627842b3-eed8-4f5f-9f4a-01a738e64d6a |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| provider            | amphora                              |
| provisioning_status | ACTIVE                               |
| updated_at          | 2022-01-15T11:12:42                  |
| vip_address         | 198.51.100.11                        |
| vip_network_id      | 9bca13be-f18d-49a5-a83d-9d487827fd16 |
| vip_port_id         | 69a85edd-5b1c-458f-96f2-b4552b15b8e6 |
| vip_qos_policy_id   | None                                 |
| vip_subnet_id       | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
+---------------------+--------------------------------------+

When a health monitor is present and functioning properly, you can check the status of each member.

Example

$ openstack loadbalancer member show pool1 member1

Sample output

A working member (member1) has an ONLINE value for its operating_status:

+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| address             | 192.0.2.10                           |
| admin_state_up      | True                                 |
| created_at          | 2022-01-15T11:11:09                  |
| id                  | b85c807e-4d7c-4cbd-b725-5e8afddf80d2 |
| name                | member1                              |
| operating_status    | ONLINE                               |
| project_id          | dda678ca5b1241e7ad7bf7eb211a2fd7     |
| protocol_port       | 80                                   |
| provisioning_status | ACTIVE                               |
| subnet_id           | 5bd7334b-49b3-4849-b3a2-b0b83852dba1 |
| updated_at          | 2022-01-15T11:12:42                  |
| weight              | 1                                    |
| monitor_port        | None                                 |
| monitor_address     | None                                 |
| backup              | False                                |
+---------------------+--------------------------------------+

Additional resources

Managing secrets with the Key Manager service guide
loadbalancer in the Command line interface reference

Ce contenu n'est pas disponible dans la langue sélectionnée.

Chapter 9. Creating secure HTTP load balancers

9.1. About non-terminated HTTPS load balancers

9.2. Creating a non-terminated HTTPS load balancer

9.3. About TLS-terminated HTTPS load balancers

9.4. Creating a TLS-terminated HTTPS load balancer

9.5. Creating a TLS-terminated HTTPS load balancer with SNI

9.6. Creating a TLS-terminated load balancer with an HTTP/2 listener

9.7. Creating HTTP and TLS-terminated HTTPS load balancing on the same IP and back-end

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Rendre l’open source plus inclusif

À propos de Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links