Docs

Volcengine Kubernetes Engine

Certificate and security

Configuring HTTPS certificates for ALB Ingress

To ensure communication security in public networks, HTTPS is typically used for communication when services are exposed to public networks through Ingresses. This topic introduces how to configure HTTPS certificates for ALB Ingress.

warning

Before configuring an ALB Ingress, thoroughly read the ALB Ingress considerations topic.

Certificate categories

Based on the effective scopes of certificates, ALB supports the following certificate types.

Certificate category	Configuration method	Certificate management
Default certificate	Required when the listener protocol is configured as HTTPS. Only one default certificate is allowed per listener. When configuring ALB Ingress or ALBInstance, no domain name is required.	Supports certificate updates. Deleting certificates is not supported.
Extension certificate	Required when the listener protocol is configured as HTTPS. Each listener can be configured with multiple extension certificates. When configuring ALB Ingress or ALBInstance, you also need to configure the domain names corresponding to the extension certificates.	Supports certificate updates. Supports certificate deletion.

tip

ALB selects the certificate to send to clients based on domain, rule, and certificate mapping. For details, see Configuring multiple certificates for HTTPS listener (basic edition) and Configuring multiple certificates for HTTPS listener (standard edition).

Based on the certificate sources, ALB supports the following certificate types.

Certificate source	Description
ALB certificates	For certificates obtained from other sources (such as other certificate authorities or those created using OpenSSL), upload them to the ALB console for unified management and use. For details, see Adding/Deleting certificate.
Certificates from Certificate Center	Certificate Center is a full-lifecycle management platform for digital certificates, providing SSL certificates and private CA services. Through Certificate Center, you can order, issue, renew, upload, and deploy SSL certificates. For more details, see Using certificates from Certificate Center on ALB. You can purchase certificates directly via Certificate Center or upload certificates obtained from other sources, enabling unified management and usage. tip We recommended managing certificates via Certificate Center. When a VKE cluster is connected to a standard-edition ALB instance, only certificates managed by Certificate Center are supported. Certificates managed in the ALB console are not supported.

Certificate configuration

Resource description

The following Kubernetes resources are involved when configuring ALB Ingress for a VKE cluster.

Resource name	Resource description	Whether certificate configuration is allowed
ALBInstance	A custom resource, mainly used to configure ALB instances and listeners.	Allowed. Specify the certificate ID in albinstance.spec. For details, see Specifying a certificate ID on ALBInstance.
Ingress	A standard Kubernetes resource object, mainly used to configure forwarding rules and backend servers on the ALB instance.	Allowed. Specify a Secret containing certificate information (certificate ID or key) in Ingress.spec. For details, see Specifying a certificate ID using a Secret and Specifying certificate content using a TLS Secret.

tip

For details on Ingress and albinstance, see Creating ALB Ingress via kubectl.

Configuration method

ALB Ingress supports the following certificate configuration methods, with differences and use cases shown below.

Configuration method	Certificate source	Application scenario
Use the Secret that contains the certificate ID	ALB certificate.	The certificate has been uploaded via the ALB console.
Use the Secret that contains the certificate ID		Certificate from Certificate Center.	The certificate has been purchased or uploaded via Certificate Center.
Using a Secret of type TLS that contains the certificate content.	Enter the certificate and key information in Secret, and VKE will upload the key information to Certificate Center.	Use the cert-manager tool inside the cluster to automatically update certificate information in Secrets.
Use an ALBInstance to specify a certificate	ALB certificate.	The certificate has been uploaded via the ALB console.
Use an ALBInstance to specify a certificate		Certificate from Certificate Center.	The certificate has been purchased or uploaded via Certificate Center.

warning

To use certificates from Certificate Center, log in to the Volcano Engine console with your account, click Service authorization, and on the page that appears, click Authorize now to complete cross-service authorization.

Selection logic

Certificates for ALB instances are configured at the listener level. Both Ingresses and ALBInstances can specify certificates for a listener. Therefore, a single listener may be associated with one ALBInstance and multiple Ingresses simultaneously. Certificates configured on these associated resources may differ. When multiple resources have certificates with conflicts, VKE selects the one with the latest expiration date.

For example, assume that the ALB instance has a listener on port 80; Ingress-A, Ingress-B, and Ingress-C use certificates A, B, and C, respectively; and ALBInstance uses certificate D. If certificate C has the most distant expiration date, VKE associates certificate C with the ALB instance.

Exceptions

To prevent traffic interruption caused by accidental certificate modification/deletion, VKE provides special handling for the following scenarios.

Hash-based security protection

Certificate deletion protection

In addition to adding certificates to the ALB when configuring ALB Ingress or ALBInstance, users sometimes directly change the certificates associated with the listener of the corresponding ALB instance in the ALB console. During reconciliation, the alb-ingress-controller may overwrite certificates added or changed manually in the ALB console based on ALB Ingress/ALBInstance configurations. To avoid that, it uses the certificate Hash value as additional protection. If the Hash value remains unchanged, the controller does not actively change the ALB certificate configuration. The following table lists main scenarios and provides examples.

Scenario	Example
As long as the Hash value does not change, the alb-ingress-controller does not actively modify the certificate.	Configure certificate cert-a on the ALB Ingress. The alb-ingress-controller associates cert-a with the ALB and records its Hash value as hash-a. The user changes the certificate to cert-b in the ALB console. When the ALB Ingress triggers reconciliation, the alb-ingress-controller finds that the recorded Hash value is still hash-a, so it skips the certificate change step, and the ALB remains associated with cert-b.
When the Hash value changes, the alb-ingress-controller changes the certificate.	Configure certificate cert-a on the ALB Ingress. The alb-ingress-controller associates cert-a with the ALB and records its Hash value as hash-a. The user changes the certificate to cert-b in the ALB console. Configure certificate cert-c on the ALB Ingress. During reconciliation, the alb-ingress-controller finds that the currently calculated Hash value is hash-c, which does not match the previously recorded hash-a. It then proceeds with the certificate change logic and updates the certificate associated with the ALB to cert-c.

When the domain name is still used in any forwarding rules, the certificate will not be deleted. For example:

When creating an ALB Ingress, an extension certificate is configured for example.com. In this case, the certificates associated with the ALB include the default certificate and the extension certificate corresponding to example.com. The sample code is as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress-demo
namespace: default
annotations:
ingress.vke.volcengine.com/loadbalancer-port: "443" # Listening port.
ingress.vke.volcengine.com/loadbalancer-protocol: "https" # Listener protocol. In this example, the value is https.
spec:
ingressClassName: alb # The name of the ALB instance.
rules:
- host: example.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: service-demo
port:
number: 80
- host: another.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: service-demo
port:
number: 80
tls:
- secretName: https-secret-demo # The default certificate. No domain name required.
- secretName: https-secret-dem-extension # Extension certificate
hosts:
- example.com # Domain name corresponding to the extension certificate

When the certificate configured on the ALB Ingress is deleted but the forwarding rules for example.com are not, the alb-ingress-controller skips deleting the extension certificate corresponding to example.com. This can prevent accidental certificate deletion that could impact traffic. Only after the forwarding rules for example.com are deleted will the alb-ingress-controller delete the extension certificate for the domain. The sample code is as follows:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alb-ingress-demo
namespace: default
annotations:
ingress.vke.volcengine.com/loadbalancer-port: "443" # Listening port.
ingress.vke.volcengine.com/loadbalancer-protocol: "https" # Listener protocol. In this example, the value is https.
spec:
ingressClassName: alb # The name of the ALB instance.
rules:
- host: example.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: service-demo
port:
number: 80
- host: another.com
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: service-demo
port:
number: 80
tls:
- secretName: https-secret-demo # Default certificate

Configuration examples

Default certificates vs extension certificates

When creating an Ingress, use a Secret to specify the default or extension certificate, as shown in the example below.

Configure a default certificate or an extension certificate by using an ALBInstance. The following content provides an example:

Use the Secret that contains the certificate ID

You can provide the certificate ID in the Secret, and then associate the Secret with the Ingress that you want to create. The example is as follows:

tip

You can use the echo -n "$(cert)" | base64 command to Base64-encode the certificate ID and source. Replace $(cert) with your actual value. For example, if $(cert) is cert_center, the encoding command is echo -n "cert_center" | base64. The encoded value is Y2VydF9jZW50ZXI=.

Using a Secret of type TLS that contains the certificate content.

You can enter the certificate content in the Secret, and then associate the Secret when configuring Ingress. The example is as follows:

Specifying a certificate ID in the ALBInstance

You can specify the certificate ID when configuring ALBInstance. The example is as follows:

FAQ

Question 1: What is the difference between configuring via the console and via YAML?

The core difference is whether the certificate ID is synced to ALBInstance.

Configuring via the console: The certificate ID is automatically synced to ALBInstance. When a certificate is removed, the ID is also removed from ALBInstance.

Configuring via YAML: The certificate ID is not synced to ALBInstance. When a certificate is removed, the ID is not removed from ALBInstance.

Question 2: After an extension certificate is removed in the console, it remains bound to the ALB.

Two possible causes for this issue. Handle it based on the actual situation.

Possible cause: Ingress still has forwarding rules using this certificate, so the alb-ingress-controller skips deletion.

Solution: After confirming the certificate is no longer in use, manually delete it in the ALB console.

Possible cause: ALBInstance has been edited via YAML and still has the extension certificate ID recorded.

Solution: After confirming the certificate is no longer in use, edit ALBInstance to remove the ID.

Question 3: The console shows "Certificate does not meet expectations."

Two possible causes for this issue. Handle it based on the actual situation.

Possible cause: The certificate for the corresponding listener was changed directly in the ALB console, causing a mismatch between the certificate actually in effect on the ALB and the Kubernetes resource records.

Solution: We recommend always binding ALB Ingress certificates on the VKE, and avoiding changing them directly in the ALB console.

Possible cause: Multiple ALB Ingresses are associated with the same ALB instance, and the certificates configured on different Ingresses conflict with each other. In this case, the alb-ingress-controller automatically selects the certificate with the most distant expiration date and applies it to the ALB instance. The certificate configurations on other Ingresses are not adopted, hence the "Certificate does not meet expectations" message.

Solution: When multiple ALB Ingresses share the same ALB instance, ensure that the certificates configured on each Ingress are consistent.

Recommendation

Unify the configuration channel and avoid mixing methods.

We recommend using the same method (console or YAML) throughout the certificate management process. Avoid mixing the two channels, as this may lead to inconsistent certificate status.

Configure certificates via the console

Follow the console page guidance to complete certificate configuration, and adhere to the following principles:

The default certificates of multiple Ingresses should be consistent.

Each Ingress manages its own extension domains and certificates.

The example is as follows:

Ingress	Default certificate	Extension domain name	Extension certificate
Ingress-A	cert-a	www.a.com	cert-b
Ingress-B	cert-a	www.b.com	cert-c

Configure certificates via YAML

Choose the corresponding configuration path based on how the certificates are managed:

Already have a certificate ID: We recommend configuring the certificate ID uniformly on the ALBInstance.

Manage certificates (including crt, key, etc.) by yourself using components such as cert-manager: We recommend configuring TLS Secrets on the Ingress.

Last updated: 2026.08.10 14:25:55