【问题标题】:Granular policy over istio egress trafic针对 istio 出口流量的粒度策略
【发布时间】:2020-01-09 12:05:56
【问题描述】:

我有安装了 Istio 的 kubernetes 集群。我有两个 pod,例如 sleep1 和 sleep2(安装了 curl 的容器)。我想将 istio 配置为允许从 sleep1 到 www.google.com 的流量,并禁止从 sleep2 到 www.google.com 的流量。

所以,我创建了 ServiceEntry:

---
apiVersion: networking.istio.io/v1alpha3
kind: ServiceEntry
metadata:
  name: google
spec:
  hosts: 
  - www.google.com
  - google.com
  ports: 
  - name: http-port
    protocol: HTTP
    number: 80
  resolution: DNS

网关

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: istio-egressgateway
spec:
  selector:
    istio: egressgateway
  servers:
  - port:
      number: 80
      name: http-port
      protocol: HTTP
    hosts:
    - "*"

两个虚拟服务(mesh->egress、egress->google)

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mesh-to-egress
spec:
  hosts: 
  - www.google.com
  - google.com
  gateways:
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-system.svc.cluster.local
        port:
          number: 80
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: egress-to-google-int
spec:
  hosts: 
  - www.google.com
  - google.com
  gateways:
  - istio-egressgateway
  http:
  - match: 
    - gateways:
      - istio-egressgateway
      port: 80
    route:
    - destination:
        host: google.com
        port:
          number: 80
      weight: 100

因此,我可以从两个 pod 中 curl google。

问题又来了:我可以允许从 sleep1 到 www.google.com 的流量并禁止从 sleep2 到 www.google.com 的流量吗?我知道这可能与 kubernetes NetworkPolicy 和黑/白名单 (https://istio.io/docs/tasks/policy-enforcement/denial-and-list/) 有关,但是这两种方法都禁止(允许)到特定 ips 的流量,或者我错过了什么?

【问题讨论】:

    标签: kubernetes load-balancing istio servicemesh


    【解决方案1】:

    您可以为sleep1sleep2 创建不同的服务帐户。然后你create an RBAC policy 限制对istio-egressgateway 策略的访问,所以sleep2 将无法通过出口网关访问任何出口流量。这应该与禁止来自集群的任何不来自出口网关的出口流量一起使用。见https://istio.io/docs/tasks/traffic-management/egress/egress-gateway/#additional-security-considerations

    如果您想允许sleep2 访问其他服务,但不允许www.google.com,您可以使用Mixer 规则和处理程序,请参阅this blog post。它展示了如何允许特定的 URL 路径指向特定的服务帐户。

    【讨论】:

      【解决方案2】:

      我认为您在拒绝选项上可能走在正确的轨道上。 它也不限于IP,因为我们可能会看到Simple DenialAttribute-based Denial 的基于属性的示例

      因此,例如,如果我们为 Sleep2 编写一个简单的拒绝规则 -> www.google.com:

      apiVersion: "config.istio.io/v1alpha2"
      kind: handler
      metadata:
        name: denySleep2Google
      spec:
        compiledAdapter: denier
        params:
          status:
            code: 7
            message: Not allowed
      ---
      apiVersion: "config.istio.io/v1alpha2"
      kind: instance
      metadata:
        name: denySleep2GoogleRequest
      spec:
        compiledTemplate: checknothing
      ---
      apiVersion: "config.istio.io/v1alpha2"
      kind: rule
      metadata:
        name: denySleep2
      spec:
        match: destination.service.host == "www.google.com" && source.labels["app"]=="sleep2"
        actions:
        - handler: denySleep2Google
          instances: [ denySleep2GoogleRequest ]
      

      请检查一下是否有帮助。 此外,“规则”条目中的“匹配”字段基于属性周围的 istio 表达式语言。一些词汇可以在this doc找到。

      【讨论】:

      • 不,很遗憾,它不起作用。我仍然可以从 sleep2 访问谷歌页面。另外,我已经尝试删除“目标”条件并只保留源标签,但这仍然不起作用
      • 我明白了。为了更好地了解情况,您的 global.outboundTrafficPolicy.mode 是 ALLOW_ANY 还是 REGISTRY_ONLY?仅当模式为 REGISTRY_ONLY 时,才会对外部服务强制执行这些策略。您可以查看此documentation。据我所知,我们需要先执行 REGISTRY_ONLY,然后再应用黑名单。请尝试一下,看看它是否会发光。
      • REGISTRY_ONLY(来自原始帖子的 google 的 +ServiceEntry)。我想尝试另一个答案的解决方案,也许我的 pod 的流量可以绕过出口
      • 好的。如果您想稍后重新访问我上面建议的样本丹尼尔,match 部分中的destination.service.host 可能不正确。有空的时候试试connection.requested_server_name
      猜你喜欢
      • 2019-02-04
      • 2012-12-28
      • 2019-10-05
      • 2020-04-03
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多