Add CORS and configure endpoint to services (Virtual service)

The new Istio endpoint to serve requests to the service and set up CORS policy. It is necessary to have this configured for all services which have public endpoint.

Istio Virtual Service

Istio Virtual Service defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.

Why you need to create it? Since we are going to switch from the AGIC to the Istio ingress controller, it's necessary to configure the new Ingress controller in the same way as the old one configured. For the Istio setup, it was decided to use separate files of Virtual service for each service which have a public endpoint.

Cross-Origin Resource Sharing (CORS)

Browsers implement CORS to allow servers to control who is allowed to make use of their resources. The control is applied when a web page in a browser makes a request to a server at a different origin (domain). The browser will first make a preflight request to the server to determine whether the full request is permitted. This preflight request does not include any authorization (for security purposes) and the response will specify the permitted HTTP verb as well as any headers that will be accepted by the server. If the web page attempts to use a method or header not on that list, the request will be blocked by the browser.

Solution

The Istio VirtualService object, in addition to providing a mapping between an HTTP request's host/path and a Kubernetes service, can also provide CORS responses without requiring logic in the service. This is convenient because it separates business logic from framework overhead.

The application team should create a VirtualService object YAML file to define the HTTP request mapping by declaring one or more URL paths and a destination service to handle those paths.

To properly configure the VirtualService object's CORS support, the application team should add the appropriate attributes to declare any headers that are accepted by the service, and the HTTP verbs that the service supports. Following the principle of least privilege, it is best practice to declare only the verbs and headers actually accepted by the service; only the application team can make this determination.

See the Istio VirtualService documentation for more detail.

At a minimum, most OSDU services should support the three headers Authorization, Data-Partition-Id, and Correlation-Id.