Add CORS and configure endpoint for services

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. We are already using this approach for service.yaml or hpa.yaml. It will allow service teams to easily manage these files and configure endpoints and CORS rules on their own.

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.

The preflight request is currently returning a 403 Forbidden response because no credentials are included, but the Istio configuration requires credentials for all requests. Even if individual services have CORS-compliant logic, that code will never be executed in the preflight context.

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.

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