Istio HTTP授权配置：验证用户为资源所有者

完全没问题，Istio的Authorization Policy正好能帮你实现服务授权解耦，同时覆盖你提到的两种场景：基于角色/组的权限控制，以及资源所有者的身份校验。而且完全不需要业务服务介入这些逻辑，所有校验都由Istio在流量层面完成。

先理清楚前提 #

你提到Kong作为API网关已经处理了JWT解析，把用户信息（比如x-username）放到请求头里——这一步非常关键，Istio可以直接读取这些请求头来做授权判断，不需要再处理JWT的逻辑。

1. 基于角色/组的常规授权配置 #

首先，你可以先配置基础的角色/组校验，比如只允许特定组的用户访问某个服务的特定路径。示例配置如下：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: service-role-auth
  namespace: your-namespace
spec:
  selector:
    matchLabels:
      app: your-service # 目标服务的标签
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["*"] # 因为Kong已经处理了JWT，这里允许所有经过网关的请求
    to:
    - operation:
        paths: ["/api/*"] # 要保护的路径
    when:
    - key: request.headers[x-group]
      values: ["admin", "editor"] # 允许的用户组

2. 资源所有者身份校验（重点） #

对于你提到的/user/{userID}/resource这类路径，需要校验路径中的userID和请求头x-username是否匹配——Istio的Authorization Policy支持直接提取路径参数，并和请求头做对比，完美解决这个需求。

下面是结合了角色校验+所有者校验的完整示例：

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: service-owner-auth
  namespace: your-namespace
spec:
  selector:
    matchLabels:
      app: your-service
  action: ALLOW
  rules:
  # 规则1：允许管理员访问所有用户的资源
  - from:
    - source:
        requestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/user/*/resource"]
    when:
    - key: request.headers[x-group]
      values: ["admin"]
  # 规则2：普通用户只能访问自己的资源（userID和x-username匹配）
  - from:
    - source:
        requestPrincipals: ["*"]
    to:
    - operation:
        paths: ["/user/{userID}/resource"] # 这里定义路径参数userID
    when:
    - key: request.path_params.userID # 提取路径中的userID参数
      values: ["{{request.headers[x-username]}}"] # 和x-username请求头的值匹配
    - key: request.headers[x-group]
      values: ["user"] # 限制普通用户组

关键细节说明 #

• 路径参数提取：Istio会自动解析路径中的{userID}参数，通过request.path_params.userID引用它。
• 动态值匹配：{{request.headers[x-username]}}是Istio的变量引用语法，用来获取请求头x-username的值，实现动态匹配。
• 规则逻辑：每个rules条目是独立的OR关系，同一个rules里的when条件是AND关系——也就是说，规则2需要同时满足userID=x-username和x-group=user才会允许访问。
• 拒绝策略：如果需要返回401而非默认的403，可以把action设为DENY，并配置对应的拒绝规则，但通常用ALLOW策略更直观。

这样配置之后，所有流量都会先经过Istio的授权校验，不符合条件的请求会直接被拦截返回错误，业务服务完全不需要处理任何授权相关的逻辑，完美实现了解耦。

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