关于Kubernetes Ingress中ssl-client-cert请求头安全性的疑问

嘿，你的担心很合理，但你的测试结果是对的——攻击者没办法直接通过手动设置ssl-client-cert请求头来伪造经过验证的客户端证书，原因如下：

• 首先，你配置的nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"对应的Nginx底层配置是proxy_set_header ssl-client-cert $ssl_client_cert;。这里的$ssl_client_cert是Nginx的内部变量，它的值只能来自Nginx自身对客户端证书的验证过程：在你auth-tls-verify-client: "optional"的配置下，客户端可以选择不传证书（此时这个变量为空）；如果客户端提供了证书且通过了Nginx的验证，这个变量才会填充有效的证书内容。
• 其次，Nginx在通过proxy_set_header设置请求头时，会完全覆盖客户端发送的同名头。也就是说，哪怕攻击者特意在请求里手动添加了ssl-client-cert头，Nginx在向上游转发请求时，会用自己生成的$ssl_client_cert变量值来设置这个头，攻击者发来的那个会被直接丢弃，根本到不了你的上游服务。
• 至于官方注解文档没明确说明这一点，是因为这属于Nginx核心代理配置的基础逻辑：当你用内部变量设置请求头时，默认不会转发客户端传来的同名头——只有当你显式使用$http_ssl_client_cert（这种格式的变量代表客户端发来的请求头）时，才会转发，但Ingress Controller的这个注解显然不会这么配置。

总结一下：你完全可以放心，上游服务收到的ssl-client-cert头要么是经过Nginx验证后的合法客户端证书，要么是空值（当客户端未提供证书时），攻击者无法通过伪造这个请求头来绕过证书验证机制。

备注：内容来源于stack exchange，提问作者mslot