When a client from one domain accesses a service in a different domain or a service that resides in the same domain but uses a different port from the client, the client initiates a cross-origin request. If the service does not allow cross-origin resource access, the client cannot access the service. In this case, you can implement cross-origin resource sharing (CORS) to allow web application servers to support cross-origin resource access. This topic describes how to configure a CORS policy in a virtual service of Service Mesh (ASM) to implement CORS.
CORS overview
For security reasons, browsers restrict cross-origin HTTP requests that are initiated from scripts. To meet your requirements for cross-origin resource access, ASM allows you to implement CORS. CORS is a mechanism based on HTTP headers and allows a server to identify domains, protocols, or ports other than its own from which a browser permits loading resources.
The CORS mechanism supports two types of requests: simple requests and preflight requests.
Simple requests
A browser sends a cross-origin request. The Origin header is specified in the request. This indicates that the request is a cross-origin request. After the destination server receives the cross-origin request, the server determines whether to allow the request based on configured CORS rules. In response, the server returns the Access-Control-Allow-Origin and Access-Control-Allow-Methods headers to indicate whether the request is allowed.
Preflight requests
A browser sends a preflight request. The request is an HTTP OPTIONS request and is used to check whether the destination server allows cross-origin requests from the current domain. If the destination server allows cross-origin requests from the current domain, the browser sends an actual cross-origin request.
The OPTIONS request contains the following headers: Origin, Access-Control-Request-Method, and Access-Control-Request-Headers. After the destination server receives the OPTIONS request, the server specifies the Access-Control-Allow-Origin, Access-Control-Allow-Method, Access-Control-Allow-Headers, and Access-Control-Max-Age headers in the response to indicate whether the request is allowed. If the preflight request is allowed, the browser sends an actual cross-origin request.
If a request meets the following three requirements, the CORS mechanism processes the request as a simple request. Otherwise, the CORS mechanism processes the request as a preflight request.
The request uses one of the following methods:
GET, HEAD, and POST
The Content-Type header in the request is set to one of the following values:
text/plain, application/x-www-form-urlencoded, and multipart/form-data
The request uses one of the following CORS-safelisted headers that are defined by the Fetch standard:
Accept, Accept-Language, Content-Language, and Content-Type. Note that the value of the Content-Type header must be set to one of the values that are listed in the second requirement.
Configure a CORS policy in a virtual service
Browsers automatically implement CORS communication. To allow cross-origin requests that are initiated to a service and implement CORS communication, you must set the corsPolicy field in the virtual service that is defined for the service.
Parameter | Description |
allowOrigins | The addresses of the origins that are allowed to access the service. Regular expressions are supported. For requests without credentials, the server can set this parameter to a wildcard (*) so that all origins are allowed to access the service. |
allowMethods | The HTTP methods that can be used to initiate cross-origin requests. |
allowHeaders | The headers that can be used during actual cross-origin requests. The specified headers are serialized to the Access-Control-Allow-Headers header used in the response to a preflight request. |
exposeHeaders | The headers that the server allows browsers to access. |
maxAge | The maximum amount of time that browsers can cache the response to a preflight request. |
allowCredentials | Specifies whether cross-origin requests can be made with credentials. Only valid credentials can be used to send cross-origin requests. |
Best practices for CORS
Prerequisites
-
You have created the
defaultandfoonamespaces, and enabled automatic sidecar proxy injection for them. For more information, see Manage global namespaces.
Step 1: Deploy applications
Deploy a backend application.
Obtain the kubeconfig file of the cluster and use kubectl to connect to the cluster. For more information, see Obtain the kubeconfig file of a cluster and use kubectl to connect to the cluster.
Create a file named details.yaml and add the following content to the file:
Run the following command to deploy the details application in the default namespace:
kubectl apply -f details.yaml -n default
Deploy a frontend application.
Create a file named istio-cors-demo.yaml and add the following content to the file:
Run the following command to deploy the istio-cors-demo application in the foo namespace:
kubectl apply -f istio-cors-demo.yaml -n foo
Step 2: Deploy an ingress gateway
-
Log on to the ASM console. In the left-side navigation pane, choose .
-
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose .
-
On the Ingress Gateway page, click Create.
-
On the Create page, set Name to ingressgateway, select the deployment Cluster, and set CLB instance type to Internet Access. Under New CLB, select a specification for the Classic Load Balancer (CLB) instance. Use the default values for other parameters and click Create.
Repeat Step 3 and Step 4 to create an ingress gateway named ingressgateway2.
Step 3: Create routing rules
-
Create a routing rule for the backend application.
-
Create an Istio gateway and associate the details application with the ingressgateway gateway.
-
Log on to the ASM console. In the left-side navigation pane, choose .
-
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose .
-
On the Gateway page, click Create from YAML.
-
On the Create page, set Namespaces to default. Select any Scenario Template. Replace the content in the YAML editor with the following configuration and click Create.
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: bookinfo-gateway namespace: default spec: selector: istio: ingressgateway servers: - hosts: - '*' port: name: http number: 80 protocol: HTTP
-
-
Create a virtual service.
-
In the left-side navigation pane of the mesh details page, choose . On the page that appears, click Create from YAML.
-
On the Create page, set Namespaces to default. Select any Scenario Template. Replace the content in the YAML editor with the following configuration and click Create.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: bookinfo namespace: default spec: gateways: - bookinfo-gateway hosts: - '*' http: - match: - uri: prefix: /details route: - destination: host: details port: number: 9080
-
-
Access the backend application.
Obtain the IP address of the ingressgateway gateway. For more information, see Create an ingress gateway.
-
In your browser's address bar, enter http://<IP address of the ingressgateway gateway>/details/2.
{"id":2,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}If the message in the preceding figure is returned, it indicates that the request to the details backend application is successful.
-
-
Create a routing rule for the frontend application.
-
Create an Istio gateway.
Create an Istio gateway and associate the istio-cors-demo application with the ingressgateway2 gateway.
-
In the left-side navigation pane of the mesh details page, choose . On the Gateway page, click Create from YAML.
-
On the Create page, set Namespaces to foo. Select any Scenario Template. Replace the content in the YAML editor with the following configuration and click Create.
apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: istio-cors-demo-gateway namespace: foo spec: selector: istio: ingressgateway2 servers: - hosts: - '*' port: name: http number: 80 protocol: HTTP
-
-
Create a virtual service.
-
In the left-side navigation pane, choose . On the VirtualService page, click Create from YAML.
-
On the Create page, set Namespaces to foo. Select any Scenario Template. Replace the content in the YAML editor with the following configuration and click Create.
apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: istio-cors-demo namespace: foo spec: gateways: - istio-cors-demo-gateway hosts: - '*' http: - route: - destination: host: istio-cors-demo port: number: 8000
-
-
-
Access the backend application by using the frontend application.
Obtain the IP address of the ingressgateway2 gateway. For more information, see Create an ingress gateway.
In the address bar of Google Chrome, enter http://<IP address of the ingressgateway2 gateway>.
-
In the URL text box, enter http://<IP address of the ingressgateway gateway>/details/2 and click Send.
-
In the upper-right corner of Google Chrome, click the
icon and choose . Access to XMLHttpRequest at 'http://47.111.xxx/details/2' from origin 'http://116.62.xxx' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Failed to load resource: net::ERR_FAILED Access to XMLHttpRequest at 'http://47.111.xxx/details/2' from origin 'http://116.62.xxx' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Failed to load resource: net::ERR_FAILED Access to XMLHttpRequest at 'http://47.111.xxx/details/2' from origin 'http://116.62.xxx' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. Failed to load resource: net::ERR_FAILED DevTools failed to load source map: Could not load content for https://unpkg.com/axios/dist/axios.min.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILUREThe preceding error messages indicate that the request fails. This is because the istio-cors-demo frontend application sends a cross-origin request to access the details backend application.
Step 4: Configure a CORS policy
-
Log on to the ASM console. In the left-side navigation pane, choose .
-
On the Mesh Management page, click the name of the ASM instance. In the left-side navigation pane, choose .
-
On the VirtualService page, find the bookinfo virtual service and click View YAML in the Actions column.
-
In the Edit dialog box, add the following
corsPolicyconfiguration under the http parameter and click OK.- corsPolicy: allowCredentials: false allowMethods: - POST - GET allowOrigins: - prefix: 'http://<IP address of the ingressgateway2 gateway>' maxAge: 24h# Final YAML after adding the corsPolicy http: - match: - uri: prefix: /details route: - destination: host: details port: number: 9080 corsPolicy: allowCredentials: false allowMethods: - POST - GET allowOrigins: - prefix: 'http://<IP address of the ingressgateway2 gateway>' # Use the IP of your ingressgateway2 gateway. maxAge: 24h
Step 5: Verify that the CORS policy takes effect
In the address bar of Google Chrome, enter http://<IP address of the ingressgateway2 gateway>.
-
In the URL text box, enter http://<IP address of the ingressgateway gateway>/details/2 and click Send.
success {"id":2,"author":"William Shakespeare","year":1595,"type":"paperback","pages":200,"publisher":"PublisherA","language":"English","ISBN-10":"1234567890","ISBN-13":"123-1234567890"}If the message in the preceding figure is returned, the istio-cors-demo frontend application successfully accessed the details backend application. This indicates that the CORS policy takes effect.