Kubernetes中Go服务实现双向mTLS需自主完成证书加载、链校验与客户端认证，不可依赖Istio Sidecar；服务端须设ClientAuth为RequireAndVerifyClientCert、正确配置ClientCAs和私钥权限，客户端须自定义Transport并同时提供证书与CA根，且身份校验应基于SPIFFE ID或SAN而非CN。
在 Kubernetes 中用 Go 实现服务间双向 mTLS，不是“配个证书就完事”，而是必须让 Go 服务自身加载证书、校验链、拒绝非法客户端——Istio Sidecar 只管流量劫持，不替你做证书验证逻辑。
Go 服务端必须显式配置 tls.Config 并启用强制客户端认证
哪怕 Istio 启用了 STRICT mTLS，Go 服务仍需自己校验客户端证书，否则攻击者可绕过 Sidecar 直连 Pod IP（比如通过 hostNetwork 或 debug 容器）。漏掉任一配置点，连接就会静默降级或直接失败。
-
ClientAuth必须设为tls.RequireAndVerifyClientCert；设成tls.VerifyClientCertIfGiven会导致无证书请求被放行 -
ClientCAs要填入已解析的*x509.CertPool（用ca.crt内容加载），不能传文件路径字符串 - 服务端私钥权限必须 ≤
0600，否则ListenAndServeTLS会静默 fallback 到 HTTP - 若用自签名 CA，
cert.pem的 SAN 字段必须包含服务 DNS 名（如my-svc.default.svc.cluster.local），否则客户端报certificate is valid for xxx, not yyy
Go 客户端必须同时提供证书并信任服务端 CA
Kubernetes 内部调用时，http.DefaultTransport 默认不加载任何证书，也不校验服务端身份，极易被中间人劫持。必须构造自定义 http.Transport，且 RootCAs 和 Certificates 两套材料缺一不可。
-
TLSClientConfig.Certificates需用tls.LoadX509KeyPair("client.crt", "client.key")加载，注意client.crt必须含完整证书链（leaf + intermediate） -
TLSClientConfig.RootCAs必须加载同一份ca.crt，用于验证服务端证书；设InsecureSkipVerify: true就等于关掉整个 mTLS - 别复用服务端的
server.crt或server.key当客户端凭据——它们是不同密钥对 - 若证书由 SPIRE 签发，建议从 Workload API 动态获取 SVID，避免挂载静态证书文件
证书分发和挂载路径要统一且可读
Kubernetes 中证书不能硬编码进镜像，也不能靠 initContainer 拷贝到非标准路径——Go 程序读不到就 panic。挂载点、文件名、权限三者必须协同。
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
立即学习“go语言免费学习笔记（深入）”；
- 推荐挂载到固定路径如
/etc/tls/server.crt、/etc/tls/server.key、/etc/tls/ca.crt，代码里直接读取 - ConfigMap 或 Secret 挂载后，文件权限默认是
0644，但私钥必须 ≤0600；可用fsGroup或runAsUser配合defaultMode: 0600修正 - gRPC 客户端用
credentials.NewTLS(&tls.Config{})时，同样依赖这些路径下的文件，不要假设它能自动发现 - 若用 cert-manager，确保
Issuer的usages包含client auth和server auth，否则证书会被拒绝
身份提取不能只看 CN，得用 SPIFFE ID 或 SAN 扩展字段
Go 标准库不会自动把证书信息注入 context，服务端收到请求后，必须手动从 peer.AuthInfo（gRPC）或 http.Request.TLS（HTTP）里解析证书链，并基于可信字段做策略判断。
- 别用
Subject.CommonName做权限控制——它易伪造，且 RFC 已弃用 - 优先检查证书的
SPIFFE ID（如spiffe://example.org/ns/default/sa/my-svc），可通过X509v3 Subject Alternative Name扩展字段携带 - gRPC Interceptor 中用
peer.FromContext(ctx).AuthInfo.(credentials.TLSInfo).State.VerifiedChains[0][0]获取客户端证书 - HTTP handler 中用
r.TLS.PeerCertificates拿到客户端证书，再校验其URIs或DNSNames
最常被忽略的一点：mTLS 不是“开了就安全”，而是每个 Go 服务都得自己写逻辑去提取、校验、授权；Sidecar 只负责加密传输，不负责身份语义。证书生命周期、SPIFFE ID 绑定、RBAC 策略执行，全得在 Go 代码里闭环。
