Docs

Volcengine Kubernetes Engine

Customize ALB Ingress forwarding rules

Configuring cross-origin traffic forwarding

ALB Ingresses support cross-origin resource sharing (CORS) configuration for traffic forwarding. This feature controls cross-origin access from the frontend and enables separation of frontend and backend, multi-domain access, and other similar cross-origin business scenarios. This topic describes the CORS configuration procedure and considerations.

warning

[Beta - apply for trial]: This feature is currently in beta. Submit an application to use it.

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

Prerequisites

The cluster has been connected. For details, see Connecting to clusters.

An ALB instance has been created. For details, see Creating ALB Ingresses via kubectl.

The alb-ingress-controller add-on has been installed and upgraded to v0.39.2 or later. For details, see Upgrading add-ons.

Usage limits

This configuration is supported only when an ALB Ingress associates with a Standard edition ALB instance. For details, see Overview of ALB instance editions.

To configure multiple forwarding actions, the CORS action must be placed after the traffic throttling action and before other actions (such as redirection and rewrite). For more limits and considerations, see Creating forwarding rules (Standard edition).

Procedure

An ALB Ingress supports configuring CORS for traffic forwarding via an annotation. The following content provides a configuration example and describes the annotation:

warning

The {{service-name}} field in the annotation must match the name of the back-end service configured in spec.rules. For example, in this case, the correct annotation is ingress.vke.volcengine.com/loadbalancer-actions.service-demo.

The following table describes fields in the ingress.vke.volcengine.com/loadbalancer-actions.{{service-name}} annotation.

Field	Type	Required	Description
type	String	Yes	The action type of the custom forwarding rule. For cross-origin traffic forwarding, set this field to Cors.
allowOrigin	Array	Yes	Specifies the URIs allowed to access the target resource. It determines which external sites can successfully make cross-origin requests to the server. You can specify an exact domain name and protocol to allow cross-origin access only from the domain name. The value must start with http:// or https://, followed by a specific domain name or a first-level wildcard domain name (such as .test.abc.example.com). For example, you can specify https://web.example.com. After the domain name, you can append a port number within the range from 1 to 65535. For example, you can specify https://web.example.com:443. You can use the wildcard to allow requests from any origins. warning If you set the allowCredentials field to on, this field requires exact domain names and does not support the wildcard *.
allowMethods	Array	Yes	Specifies the HTTP methods allowed by the server for cross-origin requests. This setting declares supported request methods to clients when the browsers initiate preflight requests. Supported methods include common HTTP methods, such as GET, POST, OPTIONS, PUT, PATCH, DELETE, and HEAD. You can configure multiple HTTP methods separated by commas (,). For example, you can enter "GET","POST".
allowHeaders	Array	No	Specifies the custom HTTP request headers that clients are allowed to include in cross-origin requests. Specific HTTP request headers, such as Authorization, are supported. You can configure multiple HTTP request headers separated by commas (,). For example, you can enter "Authorization","X-Custom-Header". The wildcard * is supported. This setting indicates that all HTTP request headers are allowed.
exposeHeaders	Array	No	Specifies the ‌custom HTTP response headers‌ that the browser is allowed to access and read in response to cross-origin requests. Specific HTTP response headers, such as Authorization, are supported. You can configure multiple HTTP response headers separated by commas (,). For example, you can enter "X-Custom-Header","Content-Length". The wildcard * is supported. This setting indicates that the browser can access all custom HTTP response headers. warning If the backend service returns specific business data (such as the total list pagination count and trace IDs) in response headers and the frontend code needs to read and process the headers, use this field to explicitly expose the headers to the browser.
allowCredentials	String	Yes	Specifies whether credentials, such as cookies, are allowed in cross-origin requests. Valid values: on: Allows credentials to be included. off: Prohibits credentials from being included.
maxAge	Integer	No	Specifies the maximum cache duration for preflight requests (OPTIONS) in the browser. For similar cross-origin requests within this period, the browser can skip the preflight requests and send the actual requests directly. The time (in seconds) is an integer value. For example, the value 3600 means 1 hour.

Validating results

View the configuration

Click Instance in the left navigation bar. In the instance list, find the target ALB instance and click Listener in the Actions column.

On the Listener information page, find the target listener. In the Actions column, click Edit forwarding rules to view rule configuration details. The rule details should be consistent with the configured ones.

Sending access requests for verification

tip

Before verification, make sure that you have deployed back-end applications and services in the cluster. In this example, an Nginx image is used and the service path is /. For deployment steps, see Using ALB Ingresses for service deployment.

Use the domain name configured in the ALB Ingress for CORS preflights. In this example, 14.***.***.*** is the public IP address of the ALB instance.

The expected result is similar to the following one. If the response message includes headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Max-Age, CORS has been enabled.

Last updated: 2026.06.05 15:13:36