gateway-api

gateway-api copied to clipboard

What would you like to be added: The ability to configure CORS policies on a HTTPRoute

Why this is needed: CORS is needed to relax specific restrictions of SOP associated with requests sent from a web browser.

To learn more visit https://enable-cors.org/index.html

How some common data plane implementations that do this today

• Envoy - https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/cors_filter
• NGINX - https://enable-cors.org/server_nginx.html
• Many more in - https://enable-cors.org/server.html

Here is an example of existing high level APIs

• Contour - https://projectcontour.io/docs/v1.21.1/config/cors/
• Istio - https://istio.io/latest/docs/reference/config/networking/virtual-service/#CorsPolicy
• Envoy Gateway - https://gateway.envoyproxy.io/latest/user/cors/
• Ingress NGINX - https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors

Relates to https://github.com/envoyproxy/gateway/issues/567

/assign

I think that this one could either be done with a Policy or with fields. A Policy design should probably wait for #1565 to merge, but a review of implementations and what CORS configuration they support, and what's common between them (like I did for #1744) should allow us to have a better design here.

Yes, this needs more infros before getting it started, I am going to resolve other assigned high priority issues first.

I think for this one, we need to talk about how to do it first, before we start, which will need probably a small GEP. @Xunzhuo, I'm going to unassign this for now, as it's reasonably large, and you've got a lot on your plate.

related https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#enable-cors

We've marked this one as v1.0.0 and placed it on the road to ga as something to do next. For this to actually make it in GA however, we probably need an owner/champion for it to start driving it forward and starting a GEP fairly soon. Is anyone up for that task?

/help

@shaneutt: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to this:

We've marked this one as v1.0.0 and placed it on the road to ga as something to do next. For this to actually make it in GA however, we probably need an owner/champion for it to start driving it forward and starting a GEP fairly soon. Is anyone up for that task?

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@youngnick Do we have any roadmap for this feature. When will this be available.

@youngnick Do we have any roadmap for this feature. When will this be available.

As per the previous message we are still in need of someone from the community to champion this issue and bring it forward, until then we have no roadmap or timeline for it. We did mark it as wanted for v1.0.0 but it's not considered a release-blocker so if nobody drives it forward very soon it will likely be pushed to post-GA.

Just added CORS to the SecurityPolicy in Envoy Gateway. I can try to come up with an initial GEP from what we have learned from Envoy Gateway. @youngnick @shaneutt

CORS is a common requirement, as we have implemented in the Kubernetes Ingress-NGINX project. However, I believe that Policy Attachment could be a more flexible and practical option for certain scenarios.

It would be great if HTTPRouteFilter had a field (E.g., HTTPRouteFilterCORS) to set CORS config (i.e., enable_cors, cors_allow_origin, cors_allow_methods, cors_allow_headers, cors_max_age, cors_allow_credentials and cors_expose_headers).

Then, if a HTTPRoute has the HTTPRouteFilterCORS, the gateway will :

• return HTTP 204 with specific CORS headers to the client for HTTP OPTION based on the HTTPRouteFilterCORS;
• add/set specific CORS headers to the response based on the HTTPRouteFilterCORS.

We've marked this one as v1.0.0 and placed it on the road to ga as something to do next. For this to actually make it in GA however, we probably need an owner/champion for it to start driving it forward and starting a GEP fairly soon. Is anyone up for that task?

/help

@shaneutt It is a common feature for HTTP gateway. If this requires a GEP, I would be like to start working on it.

/assign @lianglli

The CORS was discussed at Kubecon last week. @mikemorris @arkodg I will start a GEP for CORS that focuses on background and past implementations first.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

/remove-lifecycle stale

Hi @TJKkking! We noticed you changed the lifecycle on this, are you by chance interested in working on this?

Earlier on this issue I suggested that it would require work on the how to do this, which is true but misleading.

CORS is a reasonably complex feature that may be different between data paths (that is the proxies that actually pass the traffic).

So the next steps for this GEP (which can proceed at any time and is not affected by the Gateway API release cycle) are:

• Someone requests to have the work assigned to them on this issue (I've removed the current assignee because there have been no updates for some time).
• That person generates a new PR to the geps/ directory in the repo. This PR must do a few things:
  • copy the template in the gep-696 directory to a new gep-1767 directory
  • update all references to GEP-696 to GEP-1767, in both the Markdown and YAML files in there
  • Mark this new GEP as the Provisional state, both in the Markdown and the YAML files
  • Fill out the title (CORS Support), TLDR, Goals, Non-Goals and Introduction sections of the GEP only. Other sections can be left as they are in the template or filled out with "To be completed later" or similar.
  • The most important part of this update is the Introduction. This section should explain what CORS is and why people want to be able to configure it, and, even more importantly, explain what each relevant data plane (proxy) does to configure CORS today. See GEP-1742 for a similar example, although this CORS GEP should also include checking if any Gateway API implementations support CORS already, and how they configure it (I believe that Envoy Gateway and Istio already do, but I'm not sure).

The purpose of this initial Provisional update is to ensure that everyone talking about CORS in Gateway API has the same understanding of the current state of the art around configuring and using CORS in both Gateway API implementations and their underlying data plane proxies. This will mean that, at a future date, we can look at doing the further work to push this GEP to Implementable and Experimental (which will be subject to the usual planning cycle and freeze periods). Up until the Provisional state is finished, though, all updates to this GEP document will not be covered by Gateway API change freezes.

Lastly, whoever does take this on should not feel obligated to push this feature all the way to Experimental or beyond! It's totally fine to come in and do the initial background and Introduction for the GEP and then move on to something else. Of course, if you're passionate about the feature and want to push it forward, that's how features make it into Standard eventually!

Marking as good-first-issue with this todo list.

/good-first-issue

@youngnick: This request has been marked as suitable for new contributors.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-good-first-issue command.

In response to this:

Earlier on this issue I suggested that it would require work on the how to do this, which is true but misleading.

CORS is a reasonably complex feature that may be different between data paths (that is the proxies that actually pass the traffic).

So the next steps for this GEP (which can proceed at any time and is not affected by the Gateway API release cycle) are:

• Someone requests to have the work assigned to them on this issue (I've removed the current assignee because there have been no updates for some time).
• That person generates a new PR to the geps/ directory in the repo. This PR must do a few things:
• copy the template in the gep-696 directory to a new gep-1767 directory
• update all references to GEP-696 to GEP-1767, in both the Markdown and YAML files in there
• Mark this new GEP as the Provisional state, both in the Markdown and the YAML files
• Fill out the title (CORS Support), TLDR, Goals, Non-Goals and Introduction sections of the GEP only. Other sections can be left as they are in the template or filled out with "To be completed later" or similar.
• The most important part of this update is the Introduction. This section should explain what CORS is and why people want to be able to configure it, and, even more importantly, explain what each relevant data plane (proxy) does to configure CORS today. See GEP-1742 for a similar example, although this CORS GEP should also include checking if any Gateway API implementations support CORS already, and how they configure it (I believe that Envoy Gateway and Istio already do, but I'm not sure).

The purpose of this initial Provisional update is to ensure that everyone talking about CORS in Gateway API has the same understanding of the current state of the art around configuring and using CORS in both Gateway API implementations and their underlying data plane proxies. This will mean that, at a future date, we can look at doing the further work to push this GEP to Implementable and Experimental (which will be subject to the usual planning cycle and freeze periods). Up until the Provisional state is finished, though, all updates to this GEP document will not be covered by Gateway API change freezes.

Marking as good-first-issue with this todo list.

/good-first-issue

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

/remove-lifecycle stale

/assign @lianglli

Sorry for the late update. I will create a GEP asap.