use wildcard to match alloworigins

[zhaohuabing]

The current CORS api uses regex to match the allowed origins. This PR changes this behavior to use wildcard matching instead. Using wildcard matching is more intuitive and easier to use, and also aligns with the gateway api hostname matching.

before:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: cors
spec:
  cors:
    allowMethods:
    - GET
    - HEAD
    - PUT
    - PATCH
    - POST
    - DELETE
    allowOrigins:
    - type: RegularExpression
      value: .*\.example\.com
    allowCredentials: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: backend

after:

apiVersion: gateway.envoyproxy.io/v1alpha1
kind: SecurityPolicy
metadata:
  name: cors
spec:
  cors:
    allowMethods:
    - GET
    - HEAD
    - PUT
    - PATCH
    - POST
    - DELETE
    allowOrigins:
    - https://*.example.com
    allowCredentials: true
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: backend

related:
#2350
#2312

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (8c2112f) 64.68% compared to head (c33fda9) 64.65%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2389      +/-   ##
==========================================
- Coverage   64.68%   64.65%   -0.04%     
==========================================
  Files         114      114              
  Lines       16618    16605      -13     
==========================================
- Hits        10750    10736      -14     
- Misses       5190     5193       +3     
+ Partials      678      676       -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[arkodg]

LGTM thanks to simplifying this API field
adding a release-note tag so we highlight this breaking change in the release notes

[jaynis]

Could it be that the validation pattern which has been added to the CRD in this MR prevents the allowance of requests from any origin, e.g. https://*? If so, was this intended?

[arkodg]

hey @jaynis, thanks for root causing the issue :) can you raise a separate GH issue for this, outlining your use case

[jaynis]

Hi @arkodg. I can surely create a separate issue but I was wondering whether it might make sense to revert this PR altogether. I appreciate the effort which @zhaohuabing put into this PR and generally into this project but the implementation before featured regexes and therefore was much more powerful and closer to envoys implementation. This has been changed to a glob notation with a quite strict validation regex which only allows wildcarded subdomains. And internally this is converted back to a regex again. I do not consider this much of an improvement.

Also, it is debatable whether it makes sense to align the hostname validation with the CORS validation (which was one of the goals of this PR) because CORS is not a mere hostname but additionally contains the URI scheme and an optional port.

[zhaohuabing]

@jaynis Thanks for the feedback, and sorry for the breaking API changes.
EG decided to use wildcard match to replace regex because we have already seen some users reporting issues with CORS because of the regex is not aligned with their existing experience and against their intuitive expectations while configuring CORS. For example, these two mentioned in this PR. #2350 and #2312

We are afraid that if we keep the regex, we will see more users reporting similar issues and we need to continue to debug and explain how to use regex to them. We think it is better to use wildcard match to avoid these issues.

Could you please help to provide more details about your use case? Could it be solved by wildcard match?

[jaynis]

Thank you for this clarification @zhaohuabing 👍 . If this was a design decision based on community feedback I am totally fine with this implementation. I personally find regexes more intuitive, but this might be just my personal taste.

I will come up with a PR which extends the current wildcard approach with the functionality which I need and then we can discuss there whether it makes sense to merge it or not 😃 .

[arkodg]

thanks @jaynis, I think relaxing CEL validation to support * makes sense, we just need to make sure we add another constraint of not allowing * to be set when Access-Control-Allow-Credentials is true
https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/11-Client-side_Testing/07-Testing_Cross_Origin_Resource_Sharing