Custom CORS configuration

[djannot]

Is your feature request related to a problem? Please describe. The VirtualService generated by Gloo Portal includes a CORS configuration but:

• the content-type isn't part of the allowHeaders
• the allowOrigin can't be customized

Describe the solution you'd like We need to either provide a way for the user to provide its own CORS configuration or at least some entries they want to add to the allowHeaders and allowOrigin arrays.

[marcogschmidt]

Adding some context and initial thoughts. We currently set CORS configuration on the Gloo Edge VirtualService that is generated for an Environment only if any of the API product versions included in that Environment are published in one or more Portal resources. This is done in order for the "Try it out" feature in the interactive docs for those APIs to work in portal applications (as the requests sent from there are cross-origin). Specifically, we set the following CORS configuration:

# The domains of the relevant portals (each with both http and https schemes)
allowOrigin: [] 
# Regular expressions for the domains of the relevant portals 
# that contain DNS wildcards (each with both http and https schemes)
allowOriginRegex: []
allowCredentials: true
allowHeaders:
- api-key
- Authorization

Although we allow users to set a wide array of options on the generated VirtualService, we currently do not allow setting custom CORS policies in not to conflict with these automatically added ones (see docs here). I think the best solution would be to relax this constraint and allow users to provide their custom CORS config using the existing options fields.

If we go with approach, to not break the current behavior (where we automatically set the CORS config to have the "try it out" feature work), Gloo Portal could merge the CORS configuration above into the user-defined one. If it turns out that users do not want the automatic behavior, we could easily add a flag to disable it in the future.

To give a concrete example, this is what the configuration might look like:

apiVersion: portal.gloo.solo.io/v1beta1
kind: APIProduct
metadata:
  name: test
  namespace: gloo-portal
spec:
  versions:
  - name: v1
    apis: [ ] # omitted for brevity
    gatewayConfig:
      route:
        inlineRoute:
          backends: [ ] # omitted for brevity
          options:
            # Custom CORS config for this whole API product version
            # Currently this would result in an error.
            cors:
              allowHeaders:
              - foo
              allowOrigin:
              - custom.app.com

---

apiVersion: portal.gloo.solo.io/v1beta1
kind: Environment
metadata:
  name: test-environment
  namespace: gloo-portal
spec:
  domains:
  - api.com
  apiProducts:
  - namespaces:
    - "*"
  gatewayConfig:
    # New flag to disable the automatic setting of CORS based on portals for this env
    disableAutoCors: false
---

apiVersion: portal.gloo.solo.io/v1beta1
kind: Portal
metadata:
  name: test
  namespace: gloo-portal
spec:
  domains:
  - portal.com
  publishedEnvironments:
  - name: test-environment
    namespace: gloo-portal

The above would result in the following CORS config on the generated VirtualService/RouteTable:

apiVersion: gateway.solo.io/v1
kind: VirtualService
metadata:
  name: test-environment
  namespace: gloo-portal
spec:
  virtualHost:
    domains:
    - api.com
    routes:
    - delegateAction:
        selector:
          labels: [ ] # omitted, selects table below
      matchers:
      - prefix: /
      options:
        # No more CORS options here
        cors: { }
---

apiVersion: gateway.solo.io/v1
kind: RouteTable
metadata:
  name: test.v1
  namespace: gloo-portal
spec:
  routes:
  - matchers:
    - prefix: '/'
        options:
          # Result of merging the custom + autogenerated CORS config
          cors:
            allowOrigin:
            - http://portal.com
            - https://portal.com
            - custom.app.com
            allowCredentials: true
            allowHeaders:
            - api-key
            - Authorization
            - foo
    routeAction: {} # omitted

[marcogschmidt]

We have to decide whether we want the disableAutoCors in the initial version of this feature. If so, then we need to update the admin UI as well to allow users to set this flag.

[marcogschmidt]

After discussing this internally we decided to implement the following behavior:

• if the user did not provide any CORS configuration on the environment virtualHostOptions, then autogenerate the CORS configuration (on the delegates VHost route, as we do now) to make the "try it out" feature work
• if the user provided CORS configuration on the environment virtualHostOptions, then don't add anything there or elsewhere. It will be up to the user to make sure CORS is configured correctly to work with the "try it out" feature.
• if the user provides CORS configuration on the APIProduct routes, then just propagate that to the route options. The route-level config can override the one on the virtual host delegated route (e.g. if allowedOrigin is defined in both, the route config wins), so it will be up to the user to make sure the final CORS configuration is correct.

[marcogschmidt]

This change has been merged and will be released with Gloo Portal v1.1.0-beta7.