Traefik 3.7.16：ForwardAuth 终于支持 NTLM 与 Kerberos，同时修一个 CVE

Traefik 3.7.16 在 10 月 20 日发布，同日还发了 2.11.60。这一版只有三类内容：一个 CVE、三条 bug 修复、一条文档补充。其中一条修复值得单独讲：ForwardAuth 开始支持 NTLM 与 Kerberos。

先看 CVE

CVE fixed: Advisory GHSA-hrpp-p4fc-wwf8

发布说明没有展开细节（细节在安全公告里），处理方式照旧：升到 3.7.16 或 2.11.60。对反向代理来说，安全公告不展开是常态 —— 它的攻击面在配置层，写太细等于给攻击者画图。

ForwardAuth 与「企业内网」的老问题

真正有意思的是这条：

[authentication, service, k8s/ingress-nginx] 在 ForwardAuth 与 ingress-nginx 的 auth-url 中支持 NTLM 和 Kerberos（#14091）

ForwardAuth 的工作方式很朴素：把每个请求转发给一个认证服务，看它返回什么。返回 2xx 就放行，返回 401/403 就拒绝，顺带把响应头里的用户信息带回上游。

http:
  middlewares:
    sso:
      forwardAuth:
        address: "http://auth.internal/verify"
        authResponseHeaders:
          - X-Auth-User
          - X-Auth-Groups

问题出在企业内网：很多认证后端用的是 NTLM 或 Kerberos（域集成认证），而这两种协议的握手不是「一问一答」—— 它们需要连接保持 + 多轮：

协议	需要什么	之前的失败方式
Basic	一次请求带 Authorization	正常
NTLM	连接级状态，多轮 401 → 带 token 重试	每次转发都是新连接，握手永远完成不了
Kerberos	依赖 Negotiate 与 SPN，通常需要 keep-alive	同上，且 SPN 与实际连接的主机名要匹配

所以「ForwardAuth 支持 NTLM/Kerberos」不是加个开关，而是在转发层保留连接与握手状态。这也是为什么它同时改了 ingress-nginx 的 auth-url —— 那条路径原本是照着 nginx 的 auth_request 语义实现的，而 nginx 那边同样不保留状态。

为什么这条对国内用户也有用

看起来是「Windows 域」的专属需求，但实际上：

• 很多公司内部的 Nexus、Artifactory、GitLab 都接了 LDAP/AD；
• 只要认证后端是 IIS 或 Windows 集成认证，就会遇到 NTLM；
• 而在 Kubernetes 里，网关（Traefik）与认证后端往往不在同一个 namespace，中间还隔一层 Service —— 连接复用是第一个被牺牲的东西。

这类问题的通用形态值得记住：代理层默认是「无状态转发」，而一些认证协议天生需要「有状态连接」。两者的矛盾不会报错，只会表现为「浏览器弹认证框，输对了也进不去」。

另外两条

• k8s/gatewayapi：修 Gateway API conformance 测试套件在 containerd image store 下的启动问题（#14089）。这类修复只影响跑一致性测试的人，但它是「能不能宣称 conformant」的前提。
• 文档：明确 ingress-nginx 的 configuration-snippet 里支持 rewrite（#14070）。这条属于「早就能用但没人写下来」的知识。

我的判断

如果你的认证后端是 AD/IIS，这个版本解决的是一个长期只能靠「绕过去」的问题（常见绕法是让 nginx 单独做一层反代，或者干脆把认证放到应用里）。值得专门安排一次升级验证。

如果不用 NTLM/Kerberos，那就只有 CVE 这一条 —— 但仍然要升。反向代理的补丁版从来不建议「等下个版本一起」。