When you configure an HTTPS listener, you must associate an SSL or TLS certificate with the listener to encrypt connections between clients and the listener. This topic describes how to use an Application Load Balancer (ALB) Ingress to configure certificates for an HTTPS listener.
Certificate configuration method comparison
ALB Ingresses allow you to configure automatic certificate discovery, manage certificates as Kubernetes Secrets, and specify certificates in AlbConfigs. The following table compares the preceding methods.
Comparison item | Configure automatic certificate discovery | Specify certificates in AlbConfigs | Manage certificates as Secrets |
Certificate storage | Certificates are stored in Certificate Management Service. | Certificates are stored as Kubernetes Secrets. | |
Certificate discovery | A certificate is discovered based on the domain name that is bound to the certificate. | A certificate is discovered based on its ID. | A certificate is discovered based on the Secret in which the certificate is stored. |
Scenarios | This method is suitable for certificates that are purchased in the Certificate Management Service console or certificates that are uploaded to the Certificate Management Service console. | This feature is suitable for certificates that are managed in the cluster. For example, if you use cert-manager to manage certificates, you can store the certificates in Secrets. | |
Cross-namespace certificate usage | Yes. You can enable internal access and external access for ALB Ingresses at the same time. | Not supported. A certificate stored as a Secret can be used only within the namespace of the Secret. | |
Certificate renewal method | You must upload a new certificate to or renew the original certificate in the Certificate Management Service console. Then, you need to manually modify the configurations of the Ingress to which the certificate is associated. | You must update the configurations of the Secret in which the certificate is stored. |
An ALB instance supports a maximum of 25 certificates. In most cases, the number of certificates used by an ALB instance equals the total number of certificates associated with all listeners of the instance, including certificates associated with Ingresses. For more information, see Methods to calculate ALB quotas.
Compatibility of certificates configured by using different methods
The following table describes the compatibility of different certificate configuration methods.
How certificates are configured | Description |
A certificate is configured by using automatic certificate discovery and another certificate is configured by using a Kubernetes Secret. |
|
A certificate is configured by using automatic certificate discovery and another certificate is specified in an AlbConfig. Both certificates are associated with the same listener. | The listener uses only the certificate specified in the AlbConfig. |
A certificate is configured by using a Kubernetes Secret and another certificate is specified in an AlbConfig. Both certificates are associated with the same listener. | Both certificates are used. |
Prerequisites
A trusted certificate is obtained. You can obtain a certificate in one of the following ways:
Purchase a certificate in the Certificate Management Service console. For more information, see Purchase an official certificate.
Purchase a certificate that is issued by another certificate authority (CA).
(Optional) Follow the steps in Generate a self-signed certificate to generate a self-signed certificate.
Procedure
By default, the AlbConfig is configured with an HTTP listener on port 80. You must create an HTTPS listener and configure certificates. If no certificate is configured, the HTTPS listener becomes unavailable and the controller fails due to the lack of a certificate.
Step 1: Create an HTTPS listener in an AlbConfig
Run the following command to edit the
albconfig
configuration file:kubectl edit albconfig <Albconfig_Name>
Modify the configurations based on your business requirements. You can configure the
port
andprotocol
parameters in the Albconfig to create a corresponding listener.apiVersion: alibabacloud.com/v1 kind: AlbConfig metadata: name: alb spec: config: addressAllocatedMode: Fixed addressType: Internet zoneMappings: - vSwitchId: vsw-bp19sXXXXXXX176iv - vSwitchId: vsw-bp1boXXXXXXXu74xz listeners: - port: 80 protocol: HTTP - port: 443 # New content protocol: HTTPS # New content
(Optional) Step 2: Create a self-signed certificate
Run the following OpenSSL commands to create a self-signed certificate:
By default, self-signed certificates are not trusted by browsers or clients. If you associate a self-signed certificate with an Ingress, you may receive a security warning when you access the application that uses the Ingress. The self-signed certificate generated in this example is for reference only. Do not use the certificate in the production environment.
openssl genrsa -out albtop-key.pem 4096
openssl req -subj "/CN=demo.alb.ingress.top" -sha256 -new -key albtop-key.pem -out albtop.csr
echo subjectAltName = DNS:demo.alb.ingress.top > extfile.cnf
openssl x509 -req -days 3650 -sha256 -in albtop.csr -signkey albtop-key.pem -out albtop-cert.pem -extfile extfile.cnf
Expected results:
Certificate request self-signature ok
subject=CN=demo.alb.ingress.top
In the preceding command lines, the demo.alb.ingress.top
domain name is associated with the self-signed certificate. You can replace the domain name with a custom domain name.
Step 3: Create sample resources
In addition to the AlbConfig you created, you need to create a Deployment, Service, IngressClass, and Ingress to make an ALB Ingress function as normal. You can use the following YAML template to create the preceding resources.
Create a file named https-quickstart.yaml and copy the following content to the file:
(Optional) If both HTTP listeners and HTTPS listeners are configured in the AlbConfig, add the
annotations
field to the Ingress configurations. Example:Run the following command to create the preceding resources:
kubectl apply -f https-quickstart.yaml
Step 4: Configure certificates
Configure automatic certificate discovery
After you upload the self-signed certificate to Certificate Management Service, you can specify the domain name bound to the tls
field of the Ingress configurations. This way, the ALB Ingress can automatically discover and use the uploaded certificate.
Upload the self-signed certificate to the Certificate Management Service console. For more information, see Upload an SSL certificate.
Update the Ingress configurations.
Run the following command to modify the Ingress:
kubectl edit ingress https-ingress
Add the
tls
field and specify the domain name bound to the certificate.apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: https-ingress namespace: default spec: ingressClassName: alb rules: - host: demo.alb.ingress.top http: #... tls: - hosts: - demo.alb.ingress.top # Set the value to the domain name bound to the certificate. The domain name must be the same as the domain name specified in the “rules: host“ field.
After auto certificate discovery is configured, the associated ALB instance automatically creates an HTTPS:443
listener.
Manage certificates as Secrets
You can store the self-signed certificate in a Secret and then specify the Secret in the Ingress configurations.
Run the following commands to encode the certificate and private key files in Base64: Replace
albtop-key.pem
andalbtop-cert.pem
with the actual key and certificate files.echo -n `cat albtop-key.pem` | base64
echo -n `cat albtop-cert.pem` | base64
Create a Secret.
Create a file named albconfig.yaml and copy the following content to the file: Replace
{base64 albtop-key.pem}
and{base64 albtop-cert.pem}
with the Base64 codes in the previous step.apiVersion: v1 kind: Secret metadata: name: https-secret type: kubernetes.io/tls data: tls.key: | {base64 albtop-key.pem} tls.crt: | {base64 albtop-cert.pem}
Run the following command to create the Secret:
kubectl apply -f https-secret.yaml
Update the Ingress configurations.
Run the following command to modify the Ingress:
kubectl edit ingress https-ingress
Add the
tls
field and specify the domain name bound to the certificate and the Secret in which the certificate is stored.apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: https-ingress namespace: default spec: ingressClassName: alb rules: - host: demo.alb.ingress.top http: #... tls: - hosts: - demo.alb.ingress.top # Set the value to the domain name bound to the certificate. The domain name must be the same as the domain name specified in the “rules: host“ field. secretName: https-secret
After you configure the Secret, a certificate named default-https-secret-******
is automatically uploaded to the SSL certificate management page of the Certificate Management Service console. The associated ALB instance automatically creates an HTTPS:443
listener.
Specify certificates in AlbConfigs
After you upload the self-signed certificate to Certificate Management Service, you can specify the certificate ID in the CertificateId
field in the listener configurations of an AlbConfig. This way, the certificate is associated with the listener.
If a listener is associated with a certificate, the Ingress no longer uses the automatic certificate discovery feature.
Upload the self-signed certificate to the Certificate Management Service console. For more information, see Upload and share an SSL certificate.
Obtain the certificate ID.
Log on to the Certificate Management Service console.
In the left-side navigation pane, choose .
On the SSL Certificate Management page, click the Manage Uploaded Certificates tab. Select the certificate you uploaded and click More in the Actions column.
In the Certificate Details panel, you can view the certificate ID in the CertIdentifier field.
Specify the certificate in an AlbConfig.
Run the following command to modify the AlbConfig:
kubectl edit albconfig <ALBCONFIG_NAME> # Replace <ALBCONFIG_NAME> with the name of the AlbConfig.
Add the
certificates
field to the listener configurations of the AlbConfig and specify the certificate ID you obtained in the previous step.apiVersion: alibabacloud.com/v1 kind: AlbConfig metadata: name: alb spec: config: addressType: Intranet name: xiaosha-alb-test listeners: - port: 80 protocol: HTTP - certificates: - CertificateId: 756****-cn-hangzhou # The ID of the certificate. IsDefault: true # Specify whether the certificate is a default one. port: 443 protocol: HTTPS
Run the following command to modify the Ingress:
kubectl edit ingress https-ingress
Add the
alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]'
annotation.apiVersion: networking.k8s.io/v1 kind: Ingress metadata: annotations: alb.ingress.kubernetes.io/listen-ports: '[{"HTTPS": 443}]' # New field. If you want to listen for both HTTP and HTTPS requests, modify the value to '[{"HTTP": 80},{"HTTPS": 443}]'. name: https-ingress spec: ingressClassName: https-ingressclass rules: - host: demo.alb.ingress.top # Replace demo.alb.ingress.top with the domain name that you want to use. http: paths: - backend: service: name: https-svc port: number: 443 path: / pathType: Prefix
After the AlbConfig is configured, the associated ALB instance automatically creates an HTTPS:443
listener.
Step 5: Verify the result
Access the application over HTTPS to check whether the certificate is configured.
Run the following command to query the Ingress:
kubectl get ingress
Expected results:
NAME CLASS HOSTS ADDRESS PORTS AGE https-ingress https-ingressclass demo.alb.ingress.top alb-********.alb.aliyuncs.com 80, 443 83m
Record the values in the
HOSTS
andADDRESS
columns.Run the following command to access the backend Service of the ALB Ingress: Replace
demo.alb.ingress.top
andalb-********.alb.aliyuncs.com
with the values you obtained in the preceding step.curl -H HOST:demo.alb.ingress.top -k https://alb-********.alb.aliyuncs.com
If the following output is returned, the certificate is configured:
old
References
If you want to receive requests from clients that use the HTTP/3 protocol, see Use QUIC listeners to support HTTP/3 and improve network performance
If you want to use a listener to enable HTTPS mutual authentication, see Use HTTPS mutual authentication to enhance service security.