Istio AuthorizationPolicy 拦截Kubernetes Job中Init容器请求问题排查

问题背景 #

• 环境：Kubernetes 1.27.2，Istio 1.17.2，default命名空间
• 场景：使用migration服务账号的Kubernetes Job包含Init容器（如check-db-ready）和主容器，需要访问同命名空间内独立Pod部署的数据库
• 异常现象：已配置Istio AuthorizationPolicy允许migration服务账号访问数据库，但Init容器的请求被拦截，check-db-ready容器持续卡住，日志显示：db:5432 - no response Waiting for database service
• 已验证信息：
  • Job Pod与migration服务账号的命名空间配置无误
  • 移除AuthorizationPolicy后，所有容器（含Init容器）均可正常运行
  • 该AuthorizationPolicy对同命名空间内其他普通Pod的数据库访问请求生效正常

核心原因 #

Istio默认逻辑下，Sidecar容器不会代理Init容器的出站流量。Init容器会在Sidecar启动前执行，其请求直接绕过Sidecar发送到数据库。而数据库所在Pod的Sidecar在处理请求时，无法识别Init容器的migration服务账号身份（因为请求未经过发起方Sidecar的身份注入，缺少Istio用来标识服务账号的source.principal属性），导致AuthorizationPolicy中基于服务账号的匹配规则无法命中，最终请求被拦截。

解决方法 #

方法1：让Init容器流量通过Sidecar代理 #

修改Job的Pod模板，添加Istio注解，强制Sidecar代理指定Init容器的流量：

apiVersion: batch/v1
kind: Job
metadata:
  name: migration-job
  namespace: default
spec:
  template:
    metadata:
      annotations:
        sidecar.istio.io/inject: "true"
        # 指定需要代理流量的Init容器名称，多个用逗号分隔
        sidecar.istio.io/initContainers: "check-db-ready"
        # 若Init容器使用HTTP探针，需添加此注解确保探针流量正常代理
        # sidecar.istio.io/rewriteAppHTTPProbers: "true"
    spec:
      serviceAccountName: migration
      initContainers:
      - name: check-db-ready
        image: your-check-image:tag
        # 容器其他配置...
      containers:
      - name: migration-main
        image: your-migration-image:tag
        # 容器其他配置...

此配置会让Sidecar在Init容器启动前完成初始化，并代理其出站流量，请求将携带migration服务账号的身份信息，从而匹配AuthorizationPolicy规则。

方法2：调整AuthorizationPolicy兼容Init容器流量 #

若不想修改Sidecar代理逻辑，可扩展AuthorizationPolicy的匹配规则，添加对Job Pod的直接匹配：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-migration-to-db
  namespace: default
spec:
  selector:
    matchLabels:
      app: db # 替换为你的数据库Pod标签
  action: ALLOW
  rules:
  - from:
    - source:
        serviceAccounts: ["migration"]
    # 匹配Job创建的Pod（Job生成的Pod会自动带上job-name标签）
    - source:
        podSelector:
          matchLabels:
            job-name: migration-job # 替换为你的Job名称
    to:
    - operation:
        ports: ["5432"] # 数据库端口

这样既保留了服务账号的授权规则，也允许来自该Job Pod的所有请求（包括Init容器的直接请求）。

方法3：临时放宽数据库入站规则（仅测试环境使用） #

如果是测试环境快速验证，可以临时添加允许default命名空间所有流量的规则，但生产环境不建议使用：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: allow-migration-to-db
  namespace: default
spec:
  selector:
    matchLabels:
      app: db
  action: ALLOW
  rules:
  - from:
    - source:
        serviceAccounts: ["migration"]
    - source:
        namespaces: ["default"]
    to:
    - operation:
        ports: ["5432"]

验证步骤 #

修改配置后，重新创建Job，查看Init容器日志确认是否能正常连接数据库。若使用方法1，可通过istioctl proxy-config routes <job-pod-name>命令检查Sidecar是否已代理Init容器的流量。

内容的提问来源于stack exchange，提问作者Caitlin-B