内网服务间必须启用mtls而非依赖ip白名单或服务注册身份；go中需显式配置clientauth: tls.requireandverifyclientcert和服务端clientcas、客户端certificates及rootcas，结合spiffe id校验与网关rbac策略实现可信通信。
内网服务之间默认不设防，但生产环境里必须主动隔离——不是“要不要做”，而是“怎么做才不漏、不卡、不拖慢”。
服务间通信必须启用 mTLS
HTTP 或 gRPC 明文调用在内网同样危险，中间人攻击在容器网络或宿主机层面完全可行。mTLS 是目前 Go 微服务间最可靠的身份双向验证手段。
-
mTLS要求服务端和客户端都提供证书，且互相校验对方的 CA 签名；仅靠 IP 白名单或服务注册身份（如 Consul tag）无法替代 - Go 标准库
http.Transport和grpc.Dial都支持TLSConfig，但必须显式设置VerifyPeerCertificate回调或启用ClientAuth: tls.RequireAndVerifyClientCert - 证书生命周期管理是难点：自建 CA + cert-manager 自动轮换比手动生成更可持续；Go-Chassis 和 go-micro 的
tls.Config支持从文件或内存加载，但不自动 reload，需配合 fsnotify 或重启触发
服务发现层不能绕过认证校验
注册中心（如 etcd、Nacos、Consul）本身不是安全边界，服务发现结果若未绑定认证上下文，就等于把“谁可以调用谁”交给了 DNS 或 KV 存储。
- 注册时必须携带可验证的身份凭证，比如签名过的 service token 或 SPIFFE ID；
go-zero的rpcx插件、go-micro的auth选项都支持在注册前注入认证信息 - 客户端拉取实例列表后，不能直接连接；需先通过
Auth.Authenticate()或自定义中间件校验目标服务的证书 Subject 或 SAN 字段是否匹配预期 identity - 常见错误：用服务名（如
"user-service"）做权限判断——这容易被伪造；应基于证书中嵌入的 SPIFFE URI（如spiffe://example.org/ns/default/sa/user）做策略匹配
API 网关或 Sidecar 必须做第一层策略拦截
内网流量不经过网关/Sidecar 就等于裸奔。哪怕所有服务都启用了 mTLS，也得有统一入口做 RBAC、限流、审计日志。
- Go 生态常用方案：
go-chassis的rbac插件、go-zero的gateway模块、或自研基于casbin的策略中间件；关键是要把策略判定逻辑下沉到 TLS 握手之后、业务 handler 之前 - 策略规则必须包含至少三项：调用方证书标识（
Subject）、被调用接口路径（/v1/users/:id）、HTTP 方法或 gRPC 方法名（UserService/GetUser） - 注意性能陷阱：
casbin默认使用内存模型，策略变更需 reload；高并发下建议用redis适配器或预编译策略树，避免每次请求都解析 policy CSV
本地开发与测试环境别跳过证书验证
用 tls.InsecureSkipVerify = true 过开发阶段，等于给上线埋雷——很多团队直到压测才发现证书链校验失败，或误把测试 CA 当生产 CA。
- 开发时可用
mkcert生成本地可信 CA，并为每个服务生成对应域名证书（如user.local,order.local），这样http.Client和grpc.ClientConn不用改代码就能走完整校验流程 - 测试用例中要覆盖证书过期、CN 不匹配、CA 不受信等场景，用
testify/assert检查返回的*url.Error是否含"x509:"错误前缀，而不是只测成功路径 - CI 流水线里加一步：
openssl x509 -in cert.pem -checkend 86400，确保部署包里的证书剩余有效期大于 24 小时
真正难的不是配置 mTLS 或写一条 casbin 规则，而是让每个服务启动时自动加载正确的证书、密钥、CA 包，且不把私钥硬编码进镜像——这需要和 CI/CD、密钥管理（Vault / KMS）、容器运行时（如 Kubernetes initContainer）深度耦合。漏掉任意一环，内网就只是“物理隔离”，而非“逻辑可信”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
