Configuring an HTTPS Certificate for a LoadBalancer Ingress

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. Choose Services and Ingresses in the navigation pane, click the Ingresses tab, and click Create Ingress in the upper right corner.
3. Configure ingress parameters.
   

   This example explains only key parameters for configuring HTTPS certificates. You can configure other parameters as required. For details, see Creating a LoadBalancer Ingress on the Console.

   Table 1 Key parameters

   Parameter	Description	Example
   Name	Enter an ingress name.	ingress-test
   Load Balancer	Select a load balancer to be associated with the ingress or automatically create a load balancer.	Shared
   Listener	Frontend Protocol: Select HTTPS when configuring a certificate for an ingress. External Port: specifies the port of the load balancer listener. The default HTTPS port is 443. Certificate Source: Select TLS secret. Server Certificate: kubernetes.io/tls and IngressTLS are supported. If no certificate is available, you can create a TLS certificate. For details about parameter settings, see Creating a Secret.	Frontend Protocol: HTTPS External Port: 443 Certificate Source: TLS secret Server Certificate: test
   Forwarding Policy	Domain Name: Enter an actual domain name to be accessed. If it is left blank, the ingress can be accessed through an IP address. The domain name must be registered and filed. Once used by a forwarding policy, only that domain name will be accepted for access. Path Matching Rule: Choose Prefix match, Exact match, or RegEx match. Path: comes from a backend application for external access. It must work in the backend application. Otherwise, forwarding will not take effect. Destination Service: Select an existing Service. Only Services that meet the requirements are automatically displayed in the Service list. If no Service meets the requirements, create one by following the operations provided in Services Supported by Ingresses. Destination Service Port: Select the access port of the destination Service.	Domain Name: You do not need to configure this parameter. Path Matching Rule: Prefix match Path: / Destination Service: nginx Destination Service Port: 80

   Figure 1 Selecting a TLS certificate
   

4. Click OK.

1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
2. Ingress supports two TLS secret types: kubernetes.io/tls and IngressTLS. IngressTLS is used as an example. For details, see Creating a Secret. For details about examples of the kubernetes.io/tls secret and its description, see TLS secrets.

   Create a YAML file named ingress-test-secret.yaml. You can change the file name if you want to.

   vi ingress-test-secret.yaml

   The YAML file is configured as follows:

   apiVersion: v1
   data:
     tls.crt: LS0******tLS0tCg==
     tls.key: LS0tL******0tLS0K
   kind: Secret
   metadata:
     annotations:
       description: test for ingressTLS secrets
     name: ingress-test-secret
     namespace: default
   type: IngressTLS

   

   In the preceding information, tls.crt and tls.key are only examples. Replace them with the actual files. The values of tls.crt and tls.key are Base64-encoded.

3. Create a secret.

   kubectl create -f ingress-test-secret.yaml

   If information similar to the following is displayed, the secret has been created:

   secret/ingress-test-secret created

4. Check the created secret.

   kubectl get secrets

   If information similar to the following is displayed, the secret has been created:

   NAME                         TYPE                                  DATA      AGE
   ingress-test-secret          IngressTLS                            2         13s

5. Create a YAML file named ingress-test.yaml. You can change the file name if you want to.

   vi ingress-test.yaml

   

   Default security policy (kubernetes.io/elb.tls-ciphers-policy) is supported only in clusters v1.17.17 or later.

   Custom security policy (kubernetes.io/elb.security_policy_id) is supported only in clusters v1.17.17 or later.

   An example YAML file of an ingress associated with an automatically created load balancer is as follows:

   For clusters v1.23 or later:

   apiVersion: networking.k8s.io/v1
   kind: Ingress 
   metadata: 
     name: ingress-test
     annotations: 
       kubernetes.io/elb.class: performance
       kubernetes.io/elb.port: '443'
       kubernetes.io/elb.autocreate: 
         '{
             "type": "public",
             "bandwidth_name": "cce-bandwidth-******",
             "bandwidth_chargemode": "bandwidth",
             "bandwidth_size": 5,
             "bandwidth_sharetype": "PER",
             "eip_type": "5_bgp", # EIP
             "available_zone": [
                 "ap-southeast-1a"
             ], # The AZ where the load balancer is located
             "elb_virsubnet_ids":["b4bf8152-6c36-4c3b-9f74-2229f8e640c9"],  # Subnet network ID
             "l7_flavor_name": "L7_flavor.elb.s1.small"   # Layer 7 load balancer flavor name
          }'
       kubernetes.io/elb.security_policy_id: 99bec42b-0dd4-4583-98e9-b05ce628d157  # The priority of the custom security policy is higher than that of the default security policy.
       kubernetes.io/elb.tls-ciphers-policy: tls-1-2
   spec:
     tls: 
     - secretName: ingress-test-secret # Server certificate name
     rules: 
     - host: ''
       http: 
         paths: 
         - path: '/'
           backend: 
             service:
               name: <your_service_name>  # Replace it with your target Service name.
               port: 
                 number: 80             # Replace it with your target Service port.
           property:
             ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
           pathType: ImplementationSpecific
     ingressClassName: cce 

   For clusters v1.21 or earlier:

   apiVersion: networking.k8s.io/v1beta1
   kind: Ingress 
   metadata: 
     name: ingress-test
     annotations: 
       kubernetes.io/elb.class: performance
       kubernetes.io/ingress.class: cce
       kubernetes.io/elb.port: '443'
       kubernetes.io/elb.autocreate: 
         '{
             "type": "public",
             "bandwidth_name": "cce-bandwidth-******",
             "bandwidth_chargemode": "bandwidth",
             "bandwidth_size": 5,
             "bandwidth_sharetype": "PER",
             "eip_type": "5_bgp",    # EIP
             "available_zone": [
                 "ap-southeast-1a"
             ],   # The AZ where the load balancer is located
             "elb_virsubnet_ids":["b4bf8152-6c36-4c3b-9f74-2229f8e640c9"],   # Subnet network ID
             "l7_flavor_name": "L7_flavor.elb.s1.small"       # Layer 7 load balancer flavor name
          }'
       kubernetes.io/elb.security_policy_id: 99bec42b-0dd4-4583-98e9-b05ce628d157  # The priority of the custom security policy is higher than that of the default security policy.
       kubernetes.io/elb.tls-ciphers-policy: tls-1-2
   spec:
     tls: 
     - secretName: ingress-test-secret # Server certificate name
     rules: 
     - host: ''
       http: 
         paths: 
         - path: '/'
           backend: 
             serviceName: <your_service_name>  # Replace it with your target Service name.
             servicePort: 80      # Replace it with your target Service port.
           property:
             ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH

   Table 2 Key parameters

   Parameter	Mandatory	Type	Description
   kubernetes.io/elb.security_policy_id	No	String	The ID of the custom security group policy on ELB. Obtain it on the ELB console. This field takes effect only when HTTPS is used and has a higher priority than the default security policy. For details about how to create and update a custom security policy, see TLS Security Policy.
   kubernetes.io/elb.tls-ciphers-policy	No	String	The default value is tls-1-2, which is the default security policy used by the listener and takes effect only when HTTPS is used. Options: tls-1-0 tls-1-1 tls-1-2 tls-1-2-strict tls-1-0-with-1-3 (dedicated load balancer) tls-1-2-fs (dedicated load balancer) tls-1-2-fs-with-1-3 (dedicated load balancer) For details of cipher suites for each security policy, see Table 3.
   tls	No	Array of strings	When HTTPS is used, this parameter must be added to specify the secret certificate. Multiple independent domain names and certificates can be added. For details, see Configuring SNI for a LoadBalancer Ingress.
   secretName	No	String	This parameter is mandatory if HTTPS is used. Set this parameter to the name of the created secret.

   Table 3 tls_ciphers_policy parameters

   Security Policy	TLS Version	Cipher Suite
   tls-1-0	TLS 1.2 TLS 1.1 TLS 1.0	ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-SHA:AES256-SHA
   tls-1-1	TLS 1.2 TLS 1.1
   tls-1-2	TLS 1.2
   tls-1-2-strict	TLS 1.2	ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384
   tls-1-0-with-1-3 (dedicated load balancer)	TLS 1.3 TLS 1.2 TLS 1.1 TLS 1.0	ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-SHA256:AES256-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:AES128-SHA:AES256-SHA:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256
   tls-1-2-fs (dedicated load balancer)	TLS 1.3 TLS 1.2	ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384
   tls-1-2-fs-with-1-3 (dedicated load balancer)	TLS 1.3 TLS 1.2	ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_8_SHA256:TLS_AES_128_CCM_SHA256

6. Create an ingress.

   kubectl create -f ingress-test.yaml

   If information similar to the following is displayed, the ingress has been created:

   ingress.networking.k8s.io/ingress-test created

7. Check the created ingress.

   kubectl get ingress

   If information similar to the following is displayed, the ingress has been created:

   NAME          CLASS    HOSTS     ADDRESS          PORTS   AGE
   ingress-test  cce      *         121.**.**.**     80,443  10s

8. Enter https://121.**.**.**:443 in the address bar of the browser to access the workload (for example, Nginx workload).

   121.**.**.** indicates the IP address of the unified load balancer.

1. Log in to the CCE console and click the cluster name to access the cluster console.
2. Choose Services and Ingresses in the navigation pane, click the Ingresses tab, and click Create Ingress in the upper right corner.
3. Configure ingress parameters.
   

   This example explains only key parameters for configuring HTTPS certificates. You can configure other parameters as required. For details, see Creating a LoadBalancer Ingress on the Console.

   Table 4 Key parameters

   Parameter	Description	Example
   Name	Enter an ingress name.	ingress-test
   Load Balancer	Select a load balancer to be associated with the ingress or automatically create a load balancer.	Shared
   Listener	Frontend Protocol: Select HTTPS. External Port: specifies the port of the load balancer listener. The default HTTPS port is 443. Certificate Source: Select ELB server certificate. SSL Authentication: This parameter is available only when Certificate Source is set to ELB server certificate. Clusters v1.28.15-r60, v1.29.15-r20, v1.30.14-r20, v1.31.10-r20, v1.32.6-r20, v1.33.5-r10, or later support this configuration. One-way authentication: Only the backend server is authenticated. If you also need to authenticate the identity of the client, select two-way authentication. Two-way authentication: Both the clients and the load balancer authenticate each other. This ensures only authenticated clients can access the load balancer. No additional backend server configuration is required if you select this option. Server Certificate: Use a certificate created on ELB. If no certificate is available, go to the ELB console and create one. For details, see Adding a Certificate.	Frontend Protocol: HTTPS External Port: 443 Certificate Source: ELB server certificate SSL Authentication: One-way authentication Server Certificate: cert-test
   Forwarding Policy	Domain Name: Enter an actual domain name to be accessed. If it is left blank, the ingress can be accessed through an IP address. The domain name must be registered and filed. Once used by a forwarding policy, only that domain name will be accepted for access. Path Matching Rule: Choose Prefix match, Exact match, or RegEx match. Path: comes from a backend application for external access. It must work in the backend application. Otherwise, forwarding will not take effect. Destination Service: Select an existing Service. Only Services that meet the requirements are automatically displayed in the Service list. If no Service meets the requirements, create one by following the operations provided in Services Supported by Ingresses. Destination Service Port: Select the access port of the destination Service.	Domain Name: You do not need to configure this parameter. Path Matching Rule: Prefix match Path: / Destination Service: nginx Destination Service Port: 80

   Figure 2 Selecting a certificate from the ELB service
   

4. Click OK.

To use an ELB certificate, you can specify the kubernetes.io/elb.tls-certificate-ids annotation.

1. Use kubectl to access the cluster. For details, see Accessing a Cluster Using kubectl.
2. Create a YAML file named ingress-test.yaml. You can change the file name if you want to.

   vi ingress-test.yaml

   An example YAML file of an ingress associated with an existing load balancer is as follows:

   For clusters v1.23 or later:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: ingress-test
     namespace: default
     annotations:
       kubernetes.io/elb.port: '443'               # The port on the interconnected load balancer
       kubernetes.io/elb.id: 0b9a6c4d-bd8b-45cc-bfc8-ff0f9da54e95    # ELB ID
       kubernetes.io/elb.class: union                 # Load balancer type
       kubernetes.io/elb.tls-ciphers-policy: tls-1-2    # Default security policy, which is tls-1-2 by default
       kubernetes.io/elb.tls-certificate-ids: 058cc023690d48a3867ad69dbe9cd6e5,b98382b1f01c473286653afd1ed9ab63  # ELB certificate IDs
   spec:
     rules:
       - host: ''
         http:
           paths:
             - path: '/'
               backend:
                 service:
               name: <your_service_name>  # Replace it with your target Service name.
                   port: 
                 number: 80             # Replace it with your target Service port.
               property:
                 ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH
               pathType: ImplementationSpecific
     ingressClassName: cce

   For clusters v1.21 or earlier:

   apiVersion: networking.k8s.io/v1beta1
   kind: Ingress 
   metadata: 
     name: ingress-test
     annotations: 
       kubernetes.io/ingress.class: cce   # This parameter is mandatory when you create an ingress. The default value is cce, indicating that proprietary LoadBalancer ingresses are used.
       kubernetes.io/elb.port: '443'    # The port on the interconnected load balancer
       kubernetes.io/elb.id: 0b9a6c4d-bd8b-45cc-bfc8-ff0f9da54e95    # ELB ID
       kubernetes.io/elb.class: union     # Load balancer type
       kubernetes.io/elb.tls-ciphers-policy: tls-1-2    # Default security policy, which is tls-1-2 by default
       kubernetes.io/elb.tls-certificate-ids: 058cc023690d48a3867ad69dbe9cd6e5,b98382b1f01c473286653afd1ed9ab63  # ELB certificate IDs
   spec:
     rules: 
     - host: ''
       http: 
         paths: 
         - path: '/'
           backend: 
             serviceName: <your_service_name>  # Replace it with your target Service name.
             servicePort: 80     # Replace it with your target Service port.
           property:
             ingress.beta.kubernetes.io/url-match-mode: STARTS_WITH

   Table 5 Key parameters

   Parameter	Type	Description
   kubernetes.io/elb.tls-certificate-ids	String	ELB certificate IDs, which are separated by comma (,). The list length is greater than or equal to 1. The first ID in the list is the server certificate, and the other IDs are SNI certificates in which a domain name must be contained. If an SNI certificate cannot be found based on the domain name requested by the client, the server certificate will be returned by default. To obtain the certificate, log in to the CCE console, choose Service List > Networking > Elastic Load Balance, and choose Certificates in the navigation pane. In the certificate list, copy the ID under the target certificate name.

3. Create an ingress.

   kubectl create -f ingress-test.yaml

   If information similar to the following is displayed, the ingress has been created:

   ingress.networking.k8s.io/ingress-test created

4. Check the created ingress.

   kubectl get ingress

   If information similar to the following is displayed, the ingress has been created:

   NAME          CLASS    HOSTS     ADDRESS          PORTS   AGE
   ingress-test  cce      *         121.**.**.**     80,443  10s