CORS + JWT validation is broken because of wrong order of envoy filters

[woidda]

Bug Description

The problem is the OPTIONS preflight request when making non simple HTTP calls.

• CORS should take precedence over auth.
• I think CORS headers are public information, especially for public facing APIs

Istio does not return the access control headers. This hack is supposed to fix that, but I guess it is not a smart idea to have to do that hack in every istio configuration where we need to authenticate JWT tokens AND support CORS headers.

Version

$ istioctl version
client version: 1.12.1
control plane version: 1.10.1
data plane version: 1.10.1 (92 proxies)

$ kubectl version --short
Client Version: v1.22.1
Server Version: v1.21.2-eks-0389ca3

Additional Information

See also the suggestion in the automatically closed issue.

[howardjohn]

cc @yangminzhu thoughts on bypass_cors_preflight?

[woidda]

Why is bypass_cors_preflight: true not the default?

[yangminzhu]

It should be set to true by default, and I think we actually forgot to set it when we changed to use the Envoy JWT filter (previously it's enabled in the Istio JWT filter directly).

Thanks for reporting the issue, I will take this.

[SpecialYang]

I am confused that why istio predefine order of http filters, such as rbac, jwt_auth, cors, fault filters.
How can i move cors http filters to the first position before jwt_auth or rbac?