NGINX Ingress 控制器 v5.4.0 中的 CORS 策略:适用于 VirtualServer 和 Ingress 的模式

从NGINX Ingress控制器v5.4.0开始，CORS行为可以通过Policy资源统一定义，然后复用在VirtualServer和Ingress上。简单来说，就是先创建一个包含spec.cors的Policy，再通过spec.policies或nginx.org/policies注释把它关联到流量资源上。

从NGINX Ingress控制器（NIC）v5.4.0起，你可以在Policy资源中一次性定义CORS行为，然后应用到VirtualServer和Ingress两种流量路径上。

本文重点介绍：

• NGINX Ingress控制器中CORS策略的工作原理。
• 如何在VirtualServer和Ingress上配置使用。

为什么要使用CORS政策？

很多团队一开始都是每个资源单独配置CORS，结果很快就发现配置不一致、难以维护。用专门的Policy来管理CORS，好处很明显：

• 允许的源、方法、头部有了单一的真实来源，不会出现口径不一的问题。
• 跨服务和命名空间可以重复使用，省去重复劳动。
• 审核更清晰，CORS行为与路由逻辑完全隔离，改动时不用担心误伤。

NGINX Ingress控制器中CORS策略的工作原理

整体流程分三步：

1. 创建一个Policy资源，配置spec.cors。
2. 在定义流量时把它连上去：
   • 对于VirtualServer，通过spec.policies（也可以在路由/分流策略级别覆盖）。
   • 对于Ingress，通过nginx.org/policies注释。
3. NGINX Ingress控制器自动渲染出对应的NGINX CORS配置，为预检请求和实际跨域请求返回正确的头部。

CORS政策示例：

引用CORS政策的VirtualServer示例：

CORS政策在Ingress下的引用示例：

需要记住的重要行为：

• CORS政策可以同时作用于VirtualServer和Ingress。
• 在VirtualServer中，路由/分流策略级别的policy会覆盖规范级别的同类型policy。
• 如果使用了allowCredentials: true，那么allowOrigin必须明确指定具体的源，不能使用通配符*。

预防大多数问题的生产检查

上线前，务必验证以下几点：

• 对于未允许的源，不应返回Access-Control-Allow-Origin头部。
• 当allowCredentials: true时，只使用显性来源（不要用*）。