0

我们正在将现有的 k8s 服务转换为使用 istio 和 knative。这些服务接收来自外部用户以及集群内部的请求。我们正在尝试设置 IstioAuthorizationPolicy以实现以下要求：

  1. 某些路径（如 docs/healthchecks）不需要任何特殊的标头或任何东西，并且必须可以从任何地方访问
  2. knative 需要访问的健康和指标收集路径必须只能由 knative 控制器访问
  3. 来自集群外部的任何请求（knative-serving/knative-ingress-gateway基本上通过）必须包含与预共享密钥匹配的密钥标头
  4. 来自集群内任何服务的任何请求都可以访问所有路径

以下是我正在尝试的示例。我能够满足前 3 个要求，但不能满足最后一个要求...

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: my-svc
  namespace: my-ns
spec:
  selector:
    matchLabels:
      serving.knative.dev/service: my-svc
  action: "ALLOW"
  rules:
    - to:
        - operation:
            methods:
              - "GET"
            paths:
              - "/docs"
              - "/openapi.json"
              - "/redoc"
              - "/rest/v1/healthz"

    - to:
        - operation:
            methods:
              - "GET"
            paths:
              - "/healthz*"
              - "/metrics*"
      when:
        - key: "request.headers[User-Agent]"
          values:
            - "Knative-Activator-Probe"
            - "Go-http-client/1.1"

    - to:
        - operation:
            paths:
              - "/rest/v1/myapp*"
      when:
        - key: "request.headers[my-key]"
          values:
            - "asjhfhjgdhjsfgjhdgsfjh"

    - from:
        - source:
            namespaces:
              - "*"

我们没有对 istio-knative 设置默认提供的 mTLS 配置进行任何更改，因此假设当前 mtls 模式为PERMISSIVE.

涉及的技术堆栈的详细信息

  • AWS EKS - 版本 1.21
  • Knative Serving - 1.1 版（使用 Istio 1.11.5）
4

1 回答 1

0

我不是 Istio 专家，但您可能能够基于入口网关（有一个仅侦听 ClusterIP 地址的网关）或基于集群内的 SourceIP 来表达最后一个策略。对于后者，我想测试 Istio 是否使用实际的 SourceIP 而不是替换Forwarded标头的 IP 地址（不同的合理配置）。

于 2022-02-15T14:37:23.533 回答