OpenShift中如何安全验证HTTP请求来自指定部署服务

下面是几种能确保指定服务发起请求的安全方式，按需选择：

1. 基于ServiceAccount令牌的身份验证 #

这是OpenShift原生支持的方式，无需额外组件：

• 发起请求的服务Pod会自动挂载自身的ServiceAccount令牌，路径为/var/run/secrets/kubernetes.io/serviceaccount/token
• 发起请求时，将令牌放在Authorization请求头中，格式为Bearer <token>
• 目标服务收到请求后，调用Kubernetes API验证令牌的合法性，重点检查令牌对应的ServiceAccount名称是否为指定的服务账户
• 嫌自己写验证代码麻烦的话，可以用OpenShift OAuth代理作为Sidecar注入到目标服务Pod中，它会自动完成令牌验证，只放行合法的ServiceAccount请求

2. 网络策略（NetworkPolicy）限制 #

从网络层面拦截非指定来源的请求，作为应用层验证的补充：

• 创建NetworkPolicy，匹配目标服务的Pod标签，在ingress规则中指定仅允许来源服务的Pod标签访问目标端口
• 注意：NetworkPolicy只能限制Pod级别的访问，无法直接过滤请求路径，所以最好配合应用层的路径检查一起使用
• 简化版配置示例：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-service
spec:
  podSelector:
    matchLabels:
      app: target-service
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: allowed-service
    ports:
    - protocol: TCP
      port: 8080

3. 自定义API密钥验证 #

简单直接的轻量方案：

• 生成唯一的API密钥，存储在OpenShift的Secret中
• 让发起请求的服务Pod挂载这个Secret，请求时将密钥放在自定义HTTP头（比如X-API-Key）中
• 目标服务读取请求头中的密钥，与预存的合法密钥比对，一致则放行
• 注意定期轮换密钥，避免密钥泄露，且不要把密钥硬编码到代码里

4. mTLS双向认证 #

安全性最高的方案，适合敏感请求场景：

• 借助OpenShift Service Mesh（如Istio）自动管理服务间的证书，配置规则要求服务间通信必须使用mTLS
• 目标服务会自动验证客户端证书的身份，确认发起请求的是指定服务
• 如果不用Service Mesh，也可以手动生成证书对，将客户端证书存储在发起服务的Secret中，发起请求时携带证书，目标服务验证证书的CN或SAN字段是否匹配指定服务标识

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