Enabling CORS for a HTTPRoute

[Amila-Rukshan]

Description:

I see two ways to enable CORS in for a HTTPRoute either via a targetRef from a Policy resource or an extensionRef from a custom route filter.

Will envoy-gateway support another CR like below for this purpose?

apiVersion: gateway.envoy.io/v1alpha1
kind: CORSPolicy
metadata:
 name: cors-policy-1
Spec:
  default:
    corsConfigurationEnabled: true
    accessControlAllowOrigins:
     - '*'
    accessControlAllowCredentials: true
    accessControlAllowHeaders:
     - authorization
     - Access-Control-Allow-Origin
     - Content-Type
     - accept
     - origin
    accessControlAllowMethods:
     - GET
     - PUT
     - POST
     - DELETE
     - PATCH
     - OPTIONS
  targetRef:
    kind: HTTPRoute / Gateway
    name: http-route-1 / my-gateway

with this setting, it should be able to configure cors filter in HTTPRoute or Gateway levels.

Any thoughts?

Thanks!

[arkodg]

thanks for raising this, I would prefer if this was an extensionRef within the HTTPRoute so the API could be considered for graduation (to extended) in the future and become a native field within the spec, but I see this GEP that talks about dropping support for it.
@youngnick can you advise on how this issue should move forward ?

[arkodg]

Hi @Amila-Rukshan my earlier comment was incorrect and the above GEP only drop extension support within matches disallowing custom matches, but still supports extensions under filters . This means there are still 2 options of either using PolicyAttachment or Filter Extensions. There is a detailed discussion here #675, hoping the outcome will help drive this discussion

[youngnick]

Sorry @arkodg, I missed this one earlier. I think that a Policy resource is going to be the best fit for now, that is enough implementation to be able to suggest that something like this be implemented upstream in the HTTPRoute object (which I think is not unreasonable, since it's a common request). Its support level will depend on the data plane support, but I can see it ending up as Extended at the very least.

[arkodg]

thanks @youngnick
hey @Amila-Rukshan, it would be great if you would be able to contribute to the design and implementation for CORS, it could be a stretch goal for v0.3.0 / Jan 2023

[Amila-Rukshan]

@arkodg,

As I checked the references in gateway api, there is no extensionRef in HTTPRouteMatch even though the GEP document mention like that https://gateway-api.sigs.k8s.io/geps/gep-820/.

I think it should be HTTPRouteFilter which has extensionRef for customer specific implementaions.

I created this issue to clear the doubt - kubernetes-sigs/gateway-api#1523

we are still safe since we are going to use a policy for it

[danehans]

we are still safe since we are going to use a policy for it

Policy will depend on the outcome of #675.

[sunjayBhatia]

What Gateway API extension mechanism works best for this feature may come down to what UX is allowed

The Envoy filter is configurable per-Virtualhost or per-Route, so can be configured e.g. for all of say foo.com or for a particular path like foo.com/restricted. Depending on the choice made on what extension mechanism to provide, this may rule out (or make difficult/unwieldy) some use cases.

See: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/cors/v3/cors.proto#envoy-v3-api-msg-extensions-filters-http-cors-v3-corspolicy