Kubernetes istio授权策略拒绝规则问题

我定义了以下第一个策略来拒绝命名空间foo中对workload1的所有请求，除非它们来自workload2或workload3 尝试从workload2访问workload1时，我得到RBAC:访问被拒绝。但当使用如下所示的允许策略重写它们时，从workload2到workload1的访问成功

我想知道这是为什么，因为这两条规则应该是等价的（取自源代码中的字段被AND组合在一起的地方）

apiVersion:security.istio.io/v1beta1 种类：授权政策 元数据： 名称：入口策略 名称空间：foo 规格： 选择器： 火柴标签： 应用程序：工作负载1 行动：拒绝 规则： -发件人： -资料来源： notPrincipals:[“cluster.local/ns/foo/sa/workload2”] -资料来源： NotPrinciples:[“cluster.local/ns/foo/sa/workload3”] --- apiVersion:security.istio.io/v1beta1 种类：授权政策 元数据： 名称：入口策略 名称空间：foo 规格： 选择器： 火柴标签： 应用程序：工作负载1 行动：允许 规则： -发件人： -资料来源： 主体：[“cluster.local/ns/foo/sa/workload2”] -资料来源： 主体：[“cluster.local/ns/foo/sa/workload3”]根据：

Istio授权策略支持对网格中的工作负载进行访问控制

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

• 如果存在任何与请求匹配的拒绝策略，请拒绝该请求
• 如果工作负载没有允许策略，请允许请求
• 如果任何允许策略与请求匹配，请允许请求
• 拒绝请求

因此，如果首先评估拒绝策略。您的请求可能会先被拒绝，然后再次被允许。这就是为什么在添加允许策略后，从workload2到workload1的访问成功了

---

---

我的问题是-这两个授权策略似乎是相同的，我想验证一下，因为我的行为不同

是的，它们是一样的，如果你删除其中的一个源，它会按照你的期望工作

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name:  ingress-policy
  namespace: foo
spec:
 selector:
   matchLabels:
     app: workload1
 action: DENY
 rules:
   - from:
     - source:
        notPrincipals: ["cluster.local/ns/foo/sa/workload2"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: foo
spec:
 selector:
   matchLabels:
     app: workload1
 action: ALLOW
 rules:
   - from:
     - source:
        principals: ["cluster.local/ns/foo/sa/workload2"]

测试结果

DENY - > notPrincipals[workload2]     ->      workload2 -> 200, workload3 -> 403
DENY - > principals[workload2]        ->      workload2 -> 403, workload3 -> 200

ALLOW -> notPrincipals[workload2]     ->      workload2 -> 403, workload3 -> 200
ALLOW -> principals[workload2]        ->      workload2 -> 200, workload3 -> 403

DENY - > notPrincipals[workload2,workload3]     ->      workload2 -> 200, workload3 -> 200
DENY - > Principals[workload2,workload3]        ->      workload2 -> 403, workload3 -> 403

ALLOW -> notPrincipals[workload2,workload3]     ->      workload2 -> 403, workload3 -> 403
ALLOW -> Principals[workload2,workload3]        ->      workload2 -> 200, workload3 -> 200

---

如果要添加两个源，

workload2

和

workload3

，则使用一个源和几个主体

使用以下命令：

 rules:
   - from:
     - source:
        notPrincipals: ["cluster.local/ns/foo/sa/workload2","cluster.local/ns/foo/sa/workload3"]

---

与此相反：

rules:
  - from:
    - source:
       notPrincipals: ["cluster.local/ns/foo/sa/workload2"]
    - source:
       notPrincipals: ["cluster.local/ns/foo/sa/workload3"]

---

测试结果

DENY - > notPrincipals[workload2]     ->      workload2 -> 200, workload3 -> 403
DENY - > principals[workload2]        ->      workload2 -> 403, workload3 -> 200

ALLOW -> notPrincipals[workload2]     ->      workload2 -> 403, workload3 -> 200
ALLOW -> principals[workload2]        ->      workload2 -> 200, workload3 -> 403

DENY - > notPrincipals[workload2,workload3]     ->      workload2 -> 200, workload3 -> 200
DENY - > Principals[workload2,workload3]        ->      workload2 -> 403, workload3 -> 403

ALLOW -> notPrincipals[workload2,workload3]     ->      workload2 -> 403, workload3 -> 403
ALLOW -> Principals[workload2,workload3]        ->      workload2 -> 200, workload3 -> 200

根据：

Istio授权策略支持对网格中的工作负载进行访问控制

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

• 如果存在任何与请求匹配的拒绝策略，请拒绝该请求
• 如果工作负载没有允许策略，请允许请求
• 如果任何允许策略与请求匹配，请允许请求
• 拒绝请求

因此，如果首先评估拒绝策略。您的请求可能会先被拒绝，然后再次被允许。这就是为什么在添加允许策略后，从workload2到workload1的访问成功了

---

---

我的问题是-这两个授权策略似乎是相同的，我想验证一下，因为我的行为不同

是的，它们是一样的，如果你删除其中的一个源，它会按照你的期望工作

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name:  ingress-policy
  namespace: foo
spec:
 selector:
   matchLabels:
     app: workload1
 action: DENY
 rules:
   - from:
     - source:
        notPrincipals: ["cluster.local/ns/foo/sa/workload2"]

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: ingress-policy
  namespace: foo
spec:
 selector:
   matchLabels:
     app: workload1
 action: ALLOW
 rules:
   - from:
     - source:
        principals: ["cluster.local/ns/foo/sa/workload2"]

测试结果

DENY - > notPrincipals[workload2]     ->      workload2 -> 200, workload3 -> 403
DENY - > principals[workload2]        ->      workload2 -> 403, workload3 -> 200

ALLOW -> notPrincipals[workload2]     ->      workload2 -> 403, workload3 -> 200
ALLOW -> principals[workload2]        ->      workload2 -> 200, workload3 -> 403

DENY - > notPrincipals[workload2,workload3]     ->      workload2 -> 200, workload3 -> 200
DENY - > Principals[workload2,workload3]        ->      workload2 -> 403, workload3 -> 403

ALLOW -> notPrincipals[workload2,workload3]     ->      workload2 -> 403, workload3 -> 403
ALLOW -> Principals[workload2,workload3]        ->      workload2 -> 200, workload3 -> 200

---

如果要添加两个源，

workload2

和

workload3

，则使用一个源和几个主体

使用以下命令：

 rules:
   - from:
     - source:
        notPrincipals: ["cluster.local/ns/foo/sa/workload2","cluster.local/ns/foo/sa/workload3"]

---

与此相反：

rules:
  - from:
    - source:
       notPrincipals: ["cluster.local/ns/foo/sa/workload2"]
    - source:
       notPrincipals: ["cluster.local/ns/foo/sa/workload3"]

---

测试结果

DENY - > notPrincipals[workload2]     ->      workload2 -> 200, workload3 -> 403
DENY - > principals[workload2]        ->      workload2 -> 403, workload3 -> 200

ALLOW -> notPrincipals[workload2]     ->      workload2 -> 403, workload3 -> 200
ALLOW -> principals[workload2]        ->      workload2 -> 200, workload3 -> 403

DENY - > notPrincipals[workload2,workload3]     ->      workload2 -> 200, workload3 -> 200
DENY - > Principals[workload2,workload3]        ->      workload2 -> 403, workload3 -> 403

ALLOW -> notPrincipals[workload2,workload3]     ->      workload2 -> 403, workload3 -> 403
ALLOW -> Principals[workload2,workload3]        ->      workload2 -> 200, workload3 -> 200

---

我没有添加允许策略--我将拒绝替换为允许。另外，如果一个策略拒绝了请求，那么另一个策略将不允许该请求。Hi@Revital Eres，那么问题是什么？如果没有拒绝，为什么在允许的情况下阻止workload2的访问？关于第二部分

如果请求被一个策略拒绝，那么另一个策略就不能允许它。

我已经测试过了，在我添加了deny和allow策略之后，它的工作原理与下面的文档中的一样，因此如果只有deny，它将返回

RBAC:access denied

，但是如果有deny+allow策略，它将返回

HTTP/1.1200 OK

。如果你想看这个例子，请告诉我，也许我错了，但我认为它的工作原理与上述文档中提到的一样。我的问题是-似乎这两个授权策略是相同的，我想验证一下，因为我的行为不同。嗨，回顾！很抱歉，一开始我不理解你，我复制了你的案例并找到了解决方法，现在它按照你希望的方式工作。看看我编辑过的答案。我没有添加允许策略——我用允许替换了拒绝。另外，如果一个策略拒绝了请求，那么另一个策略将不允许该请求。Hi@Revital Eres，那么问题是什么？如果没有拒绝，为什么在允许的情况下阻止workload2的访问？关于第二部分

如果请求被一个策略拒绝，那么另一个策略就不能允许它。

我已经测试过了，在我添加了deny和allow策略之后，它的工作原理与下面的文档中的一样，因此如果只有deny，它将返回

RBAC:access denied

，但是如果有deny+allow策略，它将返回

HTTP/1.1200 OK

。如果你想看这个例子，请告诉我，也许我错了，但我认为它的工作原理与上述文档中提到的一样。我的问题是-似乎这两个授权策略是相同的，我想验证一下，因为我的行为不同。嗨，回顾！很抱歉，一开始我不理解你，我复制了你的案例并找到了解决方法，现在它按照你希望的方式工作。看看我编辑过的答案。