0

我需要在命名空间“默认”中设置授权策略，这应该检查标头拒绝访问中是否不存在 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 - -
4

2 回答 2

0

您可以尝试使用notHosts,notMethods和notPathsin来实现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路径的主机之外的所有内容的流量。

于 2021-05-21T11:31:08.290 回答
0

该部分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 如何处理流量边车。如果您使用基于 HTTP 的策略，请确保流量被这样处理。很多时候，HTTP 策略应用于被视为纯 TCP 的流量，它们不会匹配。检查https://istio.io/latest/docs/ops/configuration/traffic-management/protocol-selection/。
于 2021-05-24T09:39:30.290 回答