Kubernetes集群内部服务HTTPS/TLS通信安全：非local证书解决方案咨询

阿华AIGC实验室

2026-5-20

解决方案：绕过Kubernetes cluster.local域名的TLS证书限制

Got it, let's tackle this TLS validation problem you're facing with your Kubernetes microservices. Since your company blocks TLS certificates with SANs containing "local", we need to work around the default cluster.local DNS setup. Here are three actionable solutions you can implement:

方案1：全局修改集群默认DNS域

这个方案彻底替换Kubernetes的默认集群DNS后缀，从根本上避免使用cluster.local，适合你能对集群进行全局配置修改的场景。

更新CoreDNS配置
编辑kube-system命名空间下的coredns ConfigMap，把默认的cluster.local替换成你公司允许的域名（比如company.internal）：

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        ready
        kubernetes company.internal in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

应用修改：

kubectl apply -f coredns-configmap.yaml

调整kubelet配置
在每个集群节点上，修改kubelet的启动参数，添加--cluster-domain=company.internal。如果是kubeadm部署的集群，可修改kubelet-config.yaml后重启kubelet服务：
```
sudo systemctl restart kubelet
```
验证修改效果
部署一个测试Pod，执行nslookup your-service.default.svc.company.internal确认解析正常。之后所有服务的DNS记录都会使用新后缀，你就可以申请包含该后缀的SAN证书了。

方案2：为服务配置自定义DNS别名

如果全局修改集群DNS域太激进，你可以为每个服务配置符合公司规范的自定义DNS别名，通过CoreDNS实现解析映射。

定义自定义域名
为目标服务设置合规的DNS名称，比如payment-service.svc.company.com（确保后缀符合公司证书政策）。

配置CoreDNS解析规则
编辑coredns ConfigMap，添加hosts块直接映射自定义域名到服务的ClusterIP（适合少量服务）：

data:
  Corefile: |
    .:53 {
        errors
        health
        hosts {
            10.96.0.10 payment-service.svc.company.com
            fallthrough
        }
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        # 保留原有其他配置...
    }

若需批量处理，可使用rewrite插件自动映射：

rewrite name regex (.*)\.default\.svc\.cluster\.local $1.svc.company.com

部署合规证书
申请包含这些自定义DNS名称的SAN证书，部署到对应服务中，服务间通信时使用新域名即可通过证书验证。

方案3：利用服务网格统一管理mTLS

如果你的微服务架构已经使用服务网格（如Istio、Linkerd），可以借助其内置的mTLS功能自动处理证书，无需手动申请合规证书。

以Istio为例：

启用全局mTLS

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: istio-system
spec:
  mtls:
    mode: STRICT
EOF