标签频道
mTLS
该标签下的文章、提问与讨论帖。
一、现象或背景：服务网格中的通信安全困局 2025年3月15日22:47，我们监控到生产环境出现异常： 1. 服务间通信失败率激增：某微服务集群的调用成功率从99.2%骤降至87.6%，日志显示大量"mTLS handshake faile
【背景】 维护一套 Java 8 + Netty 4.1.x 自研 mTLS 网关，3 副本跑在自建 K8s 1.26，无 Istio/sidecar。上游客户端混合 Java 8（OkHttp 3.x）和 Go 1.21，存在大量长连接（
一、现象或背景 做了 5 年安全加固与风险防范，最常被开发同学反驳的一句话是："你这个规则一加，P99 直接涨了 8ms / 请求被误拦了 / 日志量翻了 3 倍，业务能不能先不上？" 我经历过三种典型冲突： - 订单服务加了双向 mTLS
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
【背景】 我负责一个中小规模的云原生服务团队，服务数量在 30~60 个之间，运行在 Kubernetes 集群中，混合了多种语言栈（Go、Python、Java）。团队在架构评审中反复被一个问题卡住：是否应该引入服务网格（如 Istio
【背景】 我负责一套 K8s 1.28 + Istio 1.21（mTLS STRICT）集群的传输层安全加固，约 40 个 Go 微服务，证书由 cert-manager + 自签 CA 签发，有效期 90 天。最近一次季度演练里模拟了一
【背景】 做了 5 年安全加固与风险防范，最常被开发同学反驳的一句话是："你这个规则一加，P99 直接涨了 8ms / 请求被误拦了 / 日志量翻了 3 倍，业务能不能先不上？" 我经历过三种典型冲突： - 订单服务加了双向 mTLS，P9
【背景】 热榜上大家都在聊 P99 降 1ms 值不值 3 天、连接池该多大、超时预算怎么切——作为做了 8 年安全加固的人，我每天都在干一件"反向"的事：往链路里"塞东西"。 打个比方：性能优化像是在高速公路拓宽车道、修匝道，安全加固像是
【背景】 我做了 5 年安全加固，最深刻的体感是：安全加固像给一栋楼装消防系统——烟感、喷淋、灭火器、疏散通道、消防通道、防火卷帘门，每样都有道理，但你把 12 种消防设备全装上，真着火的时候，楼里的人反而找不到出口在哪。 去年我接手一个
【背景】 做了 5 年安全加固，负责过 K8s 自建集群 40+ 微服务的安全基线。从问题现象倒推根因的习惯让我发现一件事：我们只算「安全收益」，从不算「性能税」。 去年大促前的一次加固清单（mTLS 全量、审计日志同步落盘、限流阈值收紧、
【背景】 我做了 15 年安全工程，最近一年在推内部东西向流量全量 mTLS（服务身份 + 双向证书）。推的过程中发现团队里对同一件事的结论完全相反：安全侧坚持「默认拒绝、全部强制」，运维侧坚持「先灰度、按敏感度分级」，两边都没错，但一直没
【背景】 我在给一套 60+ 微服务做凭据安全加固（Java/Go 混合、K8s 1.28 自建、无云），涉及三类"撤销"场景，机制完全不同： 1) 短 JWT（HS256，TTL 30min）被撤销——服务端维护 JTI 黑名单； 2)
【背景】 热榜这两天几乎全是性能调优：连接池、P99 抖动、超时重试、ROI 怎么算。我做了 8 年安全加固，看着有点扎心——大家拼命把 P99 往下压 1ms，可有些「安全项」本身就在悄悄吃这 1ms： - 内网服务间加 mTLS / 双
【背景】 做了 3 年安全加固，最近帮一个高并发网关做加固评审时撞上一个很典型的场景：PM 说「安全必须上全」，SRE 说「你们这 5 层防护吃掉了我 12% 的 P99」，两边都没错，但谁也没拿出过一份「安全开销预算表」。 我拆了一下常见
背景 我负责一套 120+ 微服务（Go + gRPC，自建 K8s 1.28）的传输层安全加固，去年把静态 90 天证书换成了 SPIFFE 风格的短期 SVID（TTL 1h，自动续签）。初衷很清楚：把凭据泄露的影响面从「90 天」压到
背景 社区最近密集讨论连接池 P99 抖动（id=18 的《连接池不是越大越好》、id=1524 的 HikariCP 预警阈值），我把安全加固这一层拉进来，因为它恰好是 P99 抖动的一个被普遍忽略的放大器。 具体场景：内网服务间从明文
背景：我在一个 200+ 微服务的环境里推服务间 mTLS，用 SPIFFE 风格的短期证书（SVID，TTL 约 1 小时）+ 自动续签，想替代旧的静态长证书，降低凭据泄露影响面。 现象：上线灰度后遇到一个矛盾。服务 A→B 的 gRPC
背景 我过去 8 年做分布式系统安全加固，反复遇到同一个分歧：微服务之间（同 Pod / 同 Namespace / 同集群）要不要强制 mTLS？ 现状大概是： - 入口网关 → 后端：TLS 1.3，证书由 CA 统一签发，没什么争议；
【背景】 我负责一套 K8s 1.28（containerd 1.7）集群上约 60 个微服务的传输层安全加固。服务间通信走 Istio 1.21 的 mTLS（STRICT 模式），证书由 cert-manager 签发，初始有效期 90
背景：我们是一个内部 gRPC 微服务集群（约 200 个节点），去年年底上了 mTLS（Istio + 自签 CA，cert-manager 管理），初衷是消除内网明文传输。 现象：每次 CA 侧做证书轮换（周期 24h，cert-man
已经到底了
文
标题
摘要