Cert-Manager中Vault Issuer的TLS服务器名称可配置化解析

在Kubernetes环境中使用Cert-Manager与OpenBao/Vault集成时，开发者常遇到一个典型场景：当Vault服务采用ACME颁发的TLS证书时，由于证书仅对公网域名有效（如example.com），而集群内部通过Service域名（如vault.vault.svc.cluster.local）访问时会出现证书验证失败。Cert-Manager默认会直接使用配置的server地址进行TLS验证，这在混合网络环境中可能引发信任链断裂问题。

核心问题剖析

传统方案中，Cert-Manager的Vault Issuer组件会严格校验服务端TLS证书的Subject Alternative Name (SAN)。若Vault部署同时暴露公网和集群内服务：

1. 公网入口：证书匹配但需经负载均衡器转发，增加延迟
2. 集群内入口：证书不匹配cluster.local后缀导致验证失败

这种矛盾迫使管理员不得不选择：

• 为内部通信开放公网出口（安全隐患）
• 或维护两套证书体系（运维复杂）

技术解决方案

Cert-Manager v1.18.0-alpha.0引入的关键改进是允许分离服务地址与TLS验证标识。通过新增tlsServerName字段，实现：

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: vault-issuer
spec:
  vault:
    server: https://vault.vault.svc.cluster.local:8200
    tlsServerName: vault.example.com  # 显式指定TLS校验域名
    path: pki/sign/example-dot-com

架构优势

1. 网络拓扑优化：内部流量保持Service域名路由，避免绕行公网
2. 安全增强：维持TLS严格校验的同时，消除不必要的网络暴露
3. 证书管理简化：只需维护公网证书，无需为内部通信签发特殊证书

实现原理

该特性在PKI握手阶段通过SNI(Server Name Indication)扩展实现：

1. TCP连接仍建立到server指定的集群内端点
2. TLS握手时通过tlsServerName传递预期CN(Common Name)
3. 证书校验时比对服务端证书与显式声明的域名

最佳实践建议

对于生产环境部署：

1. 网络策略：限制Vault Service仅对Cert-Manager Pod开放
2. 证书配置：确保证书包含SAN记录（如DNS:vault.example.com）
3. 版本验证：先在测试环境验证v1.18.0-alpha.0的兼容性

此改进显著提升了Cert-Manager在混合云场景下的适应性，使安全策略与网络拓扑能够解耦设计。后续版本可能会将该模式扩展至其他Issuer类型，形成统一的TLS验证策略框架。