Istio 授权策略排除同一命名空间中的某些应用程序

问题描述

我需要在命名空间“默认”中设置授权策略，这应该检查标头拒绝访问中是否不存在 JWT 令牌。所以我设置了一个策略“不允许”，如下所示。这将拒绝标头中没有有效令牌的所有请求。我想从这个规则中排除相同命名空间中的一些应用程序。允许访问的应用程序需要在同一个命名空间中。我可以创建这样的规则吗？任何有关此的指示都会有所帮助。尝试了几件事，但未能使其正常工作。

kind: “AuthorizationPolicy”
Metadata:
name: “allow-nothing”
namespace: default
spec:
selector:
matchLabels:
istio: ingressgateway
action: DENY
rules:

from:
source:
notRequestPrincipals: ["*"]

编辑

这是我在操作中应用的更改：notHosts、notMethods 和 notPaths

kind: "AuthorizationPolicy"
Metadata:
  name: "deny-all"
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway 
  action: DENY
  rules:
  - from:
    - source:
        notRequestPrincipals: ["*"]
  - to:
    - operation:
        notHosts: ["localhost"]
        notPaths: ["/ns/mypath"]
        notMethods: ["GET"]

当我应用此策略时，仍会触发 DENY 操作。请注意，在请求中我没有请求主体。这些是入口网关日志

[2021-05-22T06:42:34.106Z] "GET /ns/mypath HTTP/1.1" 403 - rbac_access_denied_matched_policy[ns[istio-system]-policy[deny-all]-rule[0]] - "-" 0 19 0 - "w.x.y.z" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML,like Gecko) Chrome/90.0.4430.93 Safari/537.36" "7b4eb6d0-bdc0-943f-ad81-292b65809639" "localhost" "-" - - a.b.c.d:8080 w.x.y.z:34974 - -

解决方法

您可以尝试在 notHosts 中使用 notMethods、notPaths 和 rules.to.operation 来实现这一点。

例如

apiVersion: security.istio.io/v1beta1
kind: “AuthorizationPolicy”
metadata:
  name: “allow-nothing”
  namespace: default
spec:
  selector:
    matchLabels:
      istio: ingressgateway
    action: DENY
rules:
- from:
  - source:
      notRequestPrincipals: ["*"]
- to:
  - operation:
      notHosts: ["*.example.com"]
      not_paths: ["/admin"]

应该拒绝除带有 .example.com 后缀和 /admin 路径的主机之外的所有内容的流量。

,

rbac_access_denied_matched_policy[ns[istio-system]-policy[deny-all]-rule[0]] 部分表示您的流量符合 deny-all 政策。

现在，要调查原因，您需要更多有关正在发生的事情的信息。第一步是启用调试日志，至少对于 rbac: istioctl pc log --level "rbac:debug" $POD_NAME.$NAMESPACE。如果您想获得更多日志，您可以省略 rbac:debug 部分，但您将获得很多额外的日志（并非所有日志都有用，但其中一些是例如， jwt:debug,http:debug,http2:debug 可能有用）。

启用此类日志后，我会检查几件事：

• 目标 Pod 从源 Pod 获取哪些信息？源 Pod 真的能够识别自己吗？您可能会看到类似 2021-05-14T13:35:24.759773Z debug envoy rbac checking connection: requestedServerName: ...,sourceIP: a.a.a.a:33142,directRemoteIP: a.a.a.a:33142,remoteIP: a.a.a.a:33142,localAddress: b.b.b.b:8443,ssl: none,dynamicMetadata: 的一行。你必须注意细节：例如，这里元数据信息是空的，没有使用ssl。因此，实际上无法确定正在使用哪个源主体，而且您实际上可能会失败。 （这可能是原因：如果您获得真正的答案，则允许此类日志:)）。要解决此类问题，您需要启用 mTLS。
• 这有点笼统，可能与您的用例不太相关，但我认为它仍然值得一提（因为它是非常基本且经常被忽视的东西）：一般来说，请检查您正在执行哪些政策以及流量如何由 istio sidecar 处理。如果您使用基于 HTTP 的策略，请确保流量被如此处理。很多时候，HTTP 策略应用于被视为普通 TCP 的流量，并且它们不会匹配。检查https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/。