【问题标题】:istio AuthorizationPolicy deny rule questionistio AuthorizationPolicy 拒绝规则问题
【发布时间】:2021-02-26 19:08:18
【问题描述】:

我定义了以下第一个策略来拒绝命名空间 foo 中对工作负载 1 的所有请求,除非它们来自工作负载 2 或工作负载 3 我得到 RBAC:尝试从工作负载 2 访问工作负载 1 时拒绝访问。但是,当使用下面显示的 ALLOW 策略重写它们时,从工作负载 2 到工作负载 1 的访问成功。

我想知道为什么这两个规则应该是等效的(取自 https://istio.io/latest/docs/reference/config/security/authorization-policy/#Rule,其中源中的字段是 AND 在一起的。)

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"]
     - source:
        notPrincipals: ["cluster.local/ns/foo/sa/workload3"]
---

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"]
     - source:
        Principals: ["cluster.local/ns/foo/sa/workload3"]

【问题讨论】:

    标签: kubernetes istio


    【解决方案1】:

    根据istio documentation

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

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

    • 如果有任何 DENY 策略与请求匹配,则拒绝该请求。
    • 如果没有针对工作负载的 ALLOW 策略,请允许该请求。
    • 如果任何 ALLOW 策略与请求匹配,则允许该请求。
    • 拒绝请求。

    因此,如果首先评估拒绝策略。您的请求可能先被拒绝,然后再次被允许。这就是您在添加允许策略后从工作负载2 访问工作负载1 成功的原因。


    我的问题是 - 这两个 AuthorizationPolicies 似乎是相同的,我想在我得到不同的行为时验证这一点。

    是的,它们是相同的,如果您删除 1 个源,它会按需要工作。

    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
    

    如果您想添加 2 个源,workload2workload3,则使用 1 个具有少量主体的源。

    使用这个:

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

     rules:
       - from:
         - source:
            principals: ["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"]
    

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

    测试结果。

    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
    

    【讨论】:

    • 我没有添加允许策略——我将拒绝替换为允许。此外,如果请求被策略拒绝,则不能被另一个策略允许。
    • 嗨@Revital Eres,有什么问题吗?如果没有否认,为什么在允许的情况下要阻止来自工作负载2的访问?关于第二部分if request is denied by a policy it can not be allowed by another one.我已经测试过了,在我添加拒绝和允许策略后,它就像下面的文档一样工作,所以如果只有拒绝它返回RBAC: access denied,但是如果有拒绝+允许策略它返回@ 987654333@。如果您想查看此示例,请告诉我,也许我错了,但我认为它的工作原理如上述文档中所述。
    • 我的问题是 - 这两个 AuthorizationPolicies 似乎是相同的,我想在我得到不同的行为时验证这一点。
    • 嗨复兴!抱歉,起初我不理解您,我复制了您的案例并找到了解决此问题的方法,现在它可以按照您希望的方式工作。看看我编辑的答案。
    猜你喜欢
    • 1970-01-01
    • 2021-04-18
    • 2023-03-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2018-06-14
    • 1970-01-01
    • 2020-08-16
    相关资源
    最近更新 更多