Istio (1.6.2) : Authorization Policy 中的 DENY 策略不适用于 Valid Token

Question

我是 Istio 的新手。我正在使用 JWT 实现授权。有效的 JWT 令牌不会反映 DENY 操作。我添加了 JWT Payload and Authorization Policy 以供参考。 我正在使用 Kubernetes 版本 v1.18.3 和 Istio 1.6.2。我在 minikube 上运行集群。

我首先在 ingressgateway 上应用了以下规则：

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: ingress-auth-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "https://dev-n63ipah2.us.auth0.com/"
    jwksUri: "https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json"
    audiences: 
    - "http://10.97.72.213/"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
 name: ingress-authz
 namespace: istio-system
spec:
 selector:
   matchLabels:
     istio: ingressgateway
 action: ALLOW
 rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["https://dev-n63ipah2.us.auth0.com/"]

之后我为 dex-ms-contact 服务申请了以下政策

JWT Payload:
{
  "iss": "https://dev-n63ipah2.us.auth0.com/",
  "sub": "sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0@clients",
  "aud": "http://10.97.72.213/",
  "iat": 1594274641,
  "exp": 1594361041,
  "azp": "sEbjHGBcZ16D0jk8wohIp7vPoT0MWTO0",
  "gty": "client-credentials"
}

RequestAuthentication:

apiVersion: "security.istio.io/v1beta1"
kind: "RequestAuthentication"
metadata:
  name: dex-ms-contact-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  jwtRules:
  - issuer: "https://dev-n63ipah2.us.auth0.com/"
    jwksUri: "https://dev-n63ipah2.us.auth0.com/.well-known/jwks.json"
    audiences: 
    - "http://10.97.72.213/"
---
apiVersion: "security.istio.io/v1beta1"
kind: "AuthorizationPolicy"
metadata:
  name: dex-ms-contact-require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: dex-ms-contact
  action: DENY
  rules:
  - when:
    - key: request.auth.claims[iss]
      values: ["https://dev-n63ipah2.us.auth0.com/"]

ingressgateway 策略运行良好。但是，当我在 dex-ms-contact 服务上应用 DENY 策略时，DENY 策略不会反映在有效的 JWT 令牌中。理想情况下，它不应该让我访问 dex-ms-contact 服务吗？

预期的行为是什么？

Answer 1

根据 istio documentation:

Istio 授权策略启用对网格中工作负载的访问控制。

授权策略同时支持允许和拒绝策略。当允许和拒绝策略同时用于工作负载时，首先评估拒绝策略。评估由以下规则确定：

1. 如果有任何 DENY 策略与请求匹配，则拒绝该请求。
2. 如果没有针对工作负载的 ALLOW 策略，请允许该请求。
3. 如果任何 ALLOW 策略与请求匹配，则允许该请求。
4. 拒绝请求。

因此考虑到首先评估拒绝策略。您的请求可能首先在工作负载策略上被拒绝，然后在网关策略上被允许，这导致完全覆盖拒绝规则。

考虑到更具体的策略评估顺序应该在 ALLOW 策略中允许什么，这可能会使您的权限模型成为可能。

希望对你有帮助。

---

编辑：

根据 istio documentation:

工作负载

operators 部署的二进制文件，用于提供服务网格应用程序的某些功能。工作负载具有名称、命名空间和唯一 ID。这些属性在使用以下attributes 的策略和遥测配置中可用：

• source.workload.name, source.workload.namespace, source.workload.uid
• destination.workload.name, destination.workload.namespace, destination.workload.uid

在 Kubernetes 中，工作负载通常对应于 Kubernetes 部署，而workload instance 对应于由部署管理的单个 pod。

抱歉回复晚了，我已经离开一段时间了。