fix(cors): add 'vary: origin' header if not set by backend

[aslafy-z]

What this PR does / why we need it:

CORS with multiple allowed origin need to serve the 'Vary: Origin' header.
This can be done on the backend side, however, users delegates the CORS setup to their ingress.
For security reason, we disable their use of the snippet annotations, so they can't use it to insert the header.
This change conditionally add the 'Vary' header to 'Origin', if the header is not defined by the backend and the configured allowed origins matches one of these conditions:

• set to any (*)
• set to more than one entry
• contains a wildcard

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• CVE Report (Scanner found CVE and adding report)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation only

Which issue/s this PR fixes

relates to #8469 (comment)

How Has This Been Tested?

• Automatic tests only

Checklist:

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I've read the CONTRIBUTION guide
• I have added unit and/or e2e tests to cover my changes.
• All new and existing tests passed.

[netlify]

✅ Deploy Preview for kubernetes-ingress-nginx canceled.

Name	Link
🔨 Latest commit	cb71d7e
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-ingress-nginx/deploys/6552063a7da865000846b1f3

[k8s-ci-robot]

This issue is currently awaiting triage.

If Ingress contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.

[k8s-ci-robot]

Hi @aslafy-z. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[larivierec]

That might actually be it.

https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#access-control-allow-origin

I might have missed it when going through the docs.
There are some tests in Go that will need to be modified however

[larivierec]

Should be roughly around this area for cors annotations.

https://github.com/kubernetes/ingress-nginx/blob/main/test/e2e/annotations/cors.go#L430

[aslafy-z]

@larivierec I implemented a test, feel free to give a look :)

[aslafy-z]

I fixed the tests @larivierec
Can you give a new look? Thank you

[larivierec]

Looks good. One thing though, I've seen you've written a new e2e test for your functionality however, all other e2e tests using wildcards should also respond with vary.

I'm pretty sure there should be a couple more to modify. Can you have another look?

[aslafy-z]

@larivierec I'm wondering if it will not made more complex to read the other tests with "unrelated" checks. What do you think? Do you think I should add ValueEqual("Vary", []string{"Origin"}) on all HttpTestClient calls that targets a backend with a wildcard as the allowed origin?

[larivierec]

I don't think that's a good idea.
You should only add the header where it actually applies.

For example, the ones that don't have a wildcard domain, won't have the vary header.

If you add it tests will fail.

[aslafy-z]

@larivierec ones that have a wildcard domains are not the only impacted with this change.
All the requests to CORS enabled backends will get this Vary header. This Vary header is useful for wildcard and static lists cases (eg: *.foo.com or bar.foo.com, baz.foo.com).
So, if I follow your proposal, in the current situation, the Vary header check would need to be added to all endpoints and we would need to add Access-Control-Allow-Headers, Access-Control-Max-Age, Access-Control-Allow-Credentials and more to all the calls.

If possible I'd prefer to not return that Vary header when the allowed origins contains a single static entry but I found no easy way of doing so. Any idea?

[larivierec]

ok, you may be right.
however, if you look at mozilla docs for CORS you can clearly see it's whenever there could be a dynamic result.

Like you mentioned, when there's more than 1 allow origin and also when there's a wildcard.
Single allow origins, should not return the vary: origin

Here's a snippet from the mozilla docs:

If the server specifies a single origin (that may dynamically change based on the requesting origin as part of an allowlist) rather than the "*" wildcard, then the server should also include Origin in the [Vary](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Vary) response header to indicate to clients that server responses will differ based on the value of the [Origin](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin) request header.

I think you'd have to add some extra logic in the build cors origin regex to set the vary header when there's more than one cors origin or cors origins is a *.

https://github.com/kubernetes/ingress-nginx/blob/main/internal/ingress/controller/template/template.go#L1738C1-L1756C2

In the section above, and this will will modify the result of the template tests and e2e tests.

Your fix might be as simple as adding a new line and adding the header.
Essentially, this section generates the cors for the nginx.conf that is used by the ingress-nginx controller.

I hope this helps a bit. :)

[aslafy-z]

@larivierec I added a conditional to only insert this header when needed and added tests to validate it. Please give a new look.

[larivierec]

lgtm
:)

[aslafy-z]

@rikatz can you please have a look?

[zifeo]

@rikatz Is there something missing from that PR or can it go forward?

[larivierec]

I left my review a year ago, hopefully the maintainers might find time to look at the issue

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: aslafy-z, larivierec
Once this PR has been reviewed and has the lgtm label, please assign gacko for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment