我是Istio的新手。我正在通过JWT实施授权。对于有效的JWT令牌,DENY操作不会得到反映。我添加了JWT有效负载和授权政策以供参考。 我正在使用kubernetes v1.18.3版和Istio 1.6.2。我正在minikube上运行集群。
我首先在入口网关上应用了以下规则:
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服务吗?
预期的行为是什么?
答案 0 :(得分:1)
根据istio documentation:
Istio授权策略可对网格中的工作负载进行访问控制。
授权策略同时支持允许和拒绝策略。当允许和拒绝策略同时用于工作负载时,将首先评估拒绝策略。评估由以下规则决定:
- 如果有任何符合请求的DENY策略,请拒绝该请求。
- 如果没有适用于工作负载的ALLOW策略,请允许该请求。
- 如果有任何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。
对不起,我迟到了,已经离开了一段时间。