Istio中的IP黑名单 [英] IP Blacklisting in Istio

查看:444
本文介绍了Istio中的IP黑名单的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

此处在IP白名单/黑名单示例中进行了解释 https://kubernetes.io/docs/tutorials/services/source-ip/使用source.ip属性.但是,在kubernetes(在docker-for-desktop上运行的kubernetes集群)中,source.ip返回kube-proxy的IP.建议的解决方法是使用request.headers["X-Real-IP"],但是它似乎不起作用,并且会在Mac的docker-for-desktop中返回kube-proxy IP.

The IP whitelisting/blacklisting example explained here https://kubernetes.io/docs/tutorials/services/source-ip/ uses source.ip attribute. However, in kubernetes (kubernetes cluster running on docker-for-desktop) source.ip returns the IP of kube-proxy. A suggested workaround is to use request.headers["X-Real-IP"], however it doesn't seem to work and returns kube-proxy IP in docker-for-desktop in mac.

https://github.com/istio/istio/issues/7328 提到此问题并指出:

使用代理来终止客户端连接并打开与您的节点/端点的新连接.在这种情况下,源IP将始终是云LB的源IP,而不是客户端的IP.

With a proxy that terminates the client connection and opens a new connection to your nodes/endpoints. In such cases the source IP will always be that of the cloud LB, not that of the client.

使用数据包转发器,使得从客户端发送到负载平衡器VIP的请求最终在具有客户端源IP而不是中间代理的节点处结束.

With a packet forwarder, such that requests from the client sent to the loadbalancer VIP end up at the node with the source IP of the client, not an intermediate proxy.

第一类负载平衡器必须在负载平衡器和后端之间使用协议达成协议,以传达真实的客户端IP(例如HTTP X-FORWARDED-FOR标头或代理协议).

Loadbalancers in the first category must use an agreed upon protocol between the loadbalancer and backend to communicate the true client IP such as the HTTP X-FORWARDED-FOR header, or the proxy protocol.

有人可以帮忙,我们如何定义协议以从负载均衡器获取客户端IP?

Can someone please help how can we define a protocol to get the client IP from the loadbalancer?

推荐答案

也许您对kube-proxy和istio感到困惑,默认情况下,Kubernetes使用kube-proxy,但是您可以安装istio,它为每个pod注入一个新的代理来控制双向传输到吊舱内的服务.

Maybe your are confusing with kube-proxy and istio, by default Kubernetes uses kube-proxy but you can install istio that injects a new proxy per pod to control the traffic in both directions to the services inside the pod.

话虽如此,您可以在群集上安装istio并将其仅用于所需的服务,并使用istio机制将其列入黑名单

With that said you can install istio on your cluster and enable it for only the services you need and apply a blacklisting using the istio mechanisms

https://istio.io/docs/tasks/政策执行/拒绝和列出/

要使用源IP列入黑名单,我们必须让istio来管理如何获取源IP地址并使用som配置,如从文档中获取的那样:

To make a blacklist using the source IP we have to leave istio manage how to fetch the source IP address and use som configuration like this taken from the docs:

apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: whitelistip
spec:
  compiledAdapter: listchecker
  params:
    # providerUrl: ordinarily black and white lists are maintained
    # externally and fetched asynchronously using the providerUrl.
    overrides: ["10.57.0.0/16"]  # overrides provide a static list
    blacklist: false
    entryType: IP_ADDRESSES
---
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: sourceip
spec:
  compiledTemplate: listentry
  params:
    value: source.ip | ip("0.0.0.0")
---
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: checkip
spec:
  match: source.labels["istio"] == "ingressgateway"
  actions:
  - handler: whitelistip
    instances: [ sourceip ]
---

您可以使用参数providerURL来维护外部列表.

You can use the param providerURL to maintain an external list.

还要检查是否在istio的入口网关服务上使用externalTrafficPolicy: Local.

Also check to use externalTrafficPolicy: Local on the ingress-gateway servce of istio.

根据评论,我的最后建议是使用其他入口控制器以避免使用kube-proxy,我的建议是使用nginx-controller

As per comments my last advice is to use a different ingress-controller to avoid the use of kube-proxy, my recomendation is to use the nginx-controller

https://github.com/kubernetes/ingress-nginx

您可以将此入口配置为充当代理的常规nginx

You can configure this ingress as a regular nginx acting as a proxy

这篇关于Istio中的IP黑名单的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆