标签频道
mTLS
该标签下的文章、提问与讨论帖。
背景：我们是一套典型微服务架构，流量入口是 API 网关 → BFF → 各业务服务，服务间用服务网格做 mTLS 互信，网关层已完成 JWT 校验并把调用方身份（uid / tenantId）塞进 X-User-Id、X-Tenant-I
【背景】 我做了 3 年云原生架构，服务从 8 个长到 60+ 个，横跨自建 K8s 和托管集群。最近两次架构评审都被同一个问题卡住：要不要上 Service Mesh（Istio / Linkerd 这一类）。一边是安全团队要 mTLS、
背景 社区最近有关于服务网格 mTLS 证书 90 天强制轮换的讨论，也有大量超时重试、连接池调优的实战经验。这些话题背后其实有一个更底层的架构分歧：安全能力和可观测性，到底应该由 Sidecar 承载，还是让应用自己内嵌 SDK？ 我在过
先说背景。 社区里已经聊了不少安全加固的"该不该做"——默认拒绝、最小权限、一票否决权、CVE 分级，都很精彩。但我最近帮两个团队做安全基线落地时，撞上了一个更"肉疼"的问题：安全加固的性能账单，没人算过账。 打个比方：你给一栋楼装了防盗门
【背景】 我在给一套内部服务做安全加固，目标是"证书 90 天强制轮换 + 轮换期间业务无感"。栈是 Go 1.22 + gRPC，跑在 3 节点自建 K8s 1.28，没有 Istio，mTLS 由应用层自己用 crypto/tls 的
先说背景。我做了 10 年分布式系统，安全加固是日常，但越做越觉得一个悖论：我们加的每一层防护，本身都在引入新的故障点和攻击面。 打个比方：你给房子装了防盗门、猫眼、门铃、电子锁、指纹锁、监控摄像头、报警联动——每一样都是"安全"，但小偷现
【背景】 我维护一套内部 API 网关：Java 8 + Netty 4.1.x，3 副本跑在 3 节点自建 K8s 1.26，没有 Istio / sidecar，mTLS 由网关自己用 SslContextBuilder 做。上游客户端
【背景】 我们在 K8s 1.27 + Istio 1.20（ambient/waypoint 未启用，走 sidecar 模式）里给一批内部服务开了 STRICT mTLS，服务间走 gRPC。目标是"证书到期自动轮换、业务无感知"。CA
【背景】 我负责 12 个微服务（Go + gRPC，跑在 3 节点自建 K8s 1.28，无云），服务间通信走 mTLS：CA 自签，每服务一对 RSA-2048 证书（CN=服务名），客户端与 sidecar 各自校验对端。安全基线要求
背景 我们是一个 40 人团队、约 60 个 Java/Go 微服务，跑在 8 节点自建 K8s 1.28（containerd，CNI 是 Calico）。目前集群内东西向流量全是明文 HTTP，安全团队要求年底前把服务间通信升级为 mT
先抛个背景：最近帮几个团队做安全加固，发现一个特别普遍的现象——外部入口有网关、有鉴权、有审计，可一旦流量进了内网，服务之间的调用就像"进了自家小区的门"，基本是裸奔：HTTP 明文、无 token、无签名，谁都能调谁。 我打个比方：这就像
文
标题
摘要