Kubernetes集群服务间HTTP请求身份认证方案相关咨询

仅入口校验JWT、内部服务不做任何认证是否足够？ #

结论：完全不够，存在极高的安全风险
常见风险点包括：

• 攻击者只要绕过入口（比如利用容器逃逸漏洞、恶意部署测试Pod、集群RBAC配置错误导致内部端口暴露），就能伪造任意用户ID调用所有内部服务，没有任何阻拦
• 无法限制内部服务的调用权限，比如一个仅能查询用户基础信息的低权限服务，没有认证的情况下可以随意调用支付、用户数据删除等高敏感接口
• 出现安全事件后无法溯源，仅能拿到用户ID，无法确认请求是从哪个服务发起的，很难定位问题根因

服务间HTTP请求是否需要配置身份认证机制？ #

结论：必须配置
不管你是否采用零信任架构，内部服务通信的身份认证都是必要的基础安全能力，能够阻挡绝大多数内部横向渗透、越权调用的风险。

可选认证方案说明 #

不需要强行选择单一方案，可以根据业务安全等级组合使用：

1. 透传原始JWT + 本地签名校验 #

适合大部分中等安全要求的通用业务：

• 入口校验JWT完成后，直接把原始JWT放到请求头里透传给后续所有内部调用链路
• 内部服务不需要重复请求AWS Cognito做校验，只需要用提前缓存的Cognito公钥，本地校验JWT的签名有效性、过期时间即可，性能开销可以忽略
• 优势：不需要引入额外组件，复用现有Cognito能力，从根源上避免用户ID被伪造的问题
• 注意：禁止直接解析JWT的payload内容就信任，必须完成签名和有效期校验才能使用

2. 服务间mTLS双向认证 #

适合金融、政务等高安全等级要求的业务：

• 借助K8s生态的cert-manager等工具，给每个内部服务颁发唯一的客户端、服务端证书
• 服务间发起HTTP请求时双向校验证书，确认对方的服务身份合法
• 可以配合JWT透传一起使用，同时校验服务身份和用户身份，防护等级最高
• 优势：就算JWT意外泄露，攻击者没有对应服务的合法证书也无法发起跨服务调用

3. 服务网格自带的身份认证能力 #

适合已经引入Istio、Linkerd等服务网格的集群：

• 服务网格控制面自动给每个服务颁发唯一的身份令牌，请求调用时自动注入和校验身份，业务代码几乎不需要做任何改造
• 可以配套配置细粒度的授权规则，比如仅允许服务A调用服务B的/api/query接口，进一步控制风险
• 优势：对业务无侵入，还能同时获得流量治理、可观测等其他服务网格能力

绝对不推荐仅透传用户ID不加任何校验的做法，这种方案相当于将所有内部服务完全暴露在集群内部风险下，只要任意一个节点被攻破，整个集群的服务都会失去防护。

内容的提问来源于stack exchange，提问作者Moshe Shaham