网络策略制定了 Pod 组之间以及与外部网络端点之间的通信,就像是 Kubernetes 的防火墙。本文针对网络策略,介绍了如何增强网络策略以控制出口(Egress)。
作者:Viswajith Venugopal
翻译:Bach(才云)
校对:bot(才云)、星空下的文仔(才云)
Kubernetes 中的网络策略用于指定 Pod 组之间以及其与外部网络端点之间的通信,它就像是 Kubernetes 的防火墙。与大多数 Kubernetes 对象一样,网络策略非常灵活,功能也很强大。如果了解应用程序中服务的确切通信模式,我们就可以通过网络策略将通信限制在我们想要范围之内。
K8sMeetupIngress 与 Egress
网络策略可用于指定 Pod 的入口(Ingress)流量和出口(Egress)流量,其规则如下:
如果允许集群外部网络端点到 Pod 的通讯,那么该端点可以访问 Pod。
如果允许 Pod 到集群外部网络端点的通讯,那么 Pod 也可以访问该端点。
如果 Pod(A)到 Pod(B)的流量被允许,那么流量可以通过 A 的出口以及 B 的入口。注意这是单向的,流量从 B 到 A,那么只能从 B 的出口到 A 的入口。
设置 Ingress
在完成入口网络策略的设置并成功运行后,我们再设置出口网络策略。这样做的原因有两个:首先,一次执行两项操作比较困难,而且我们很难知道是由于入口还是出口配置导致的网络连接失败;其次,出口网络策略通常更难以实施。限制出口可能会引发各种错误,从而影响应用程序运行。
虽然确定网络端点到 Pod 的通讯非常简单,但要确定 Pod 到网络端点的连接方式会比较复杂。之所以出现这一问题,这是因为:作为常规功能的一部分,Deployment 通常会查询一堆外部服务,根据它们在访问这些服务时处理超时的方式,功能可能会受到一些细微而又难以观察的影响。
- Deployment 需要能够与 DNS 服务器通信,以便和其他任何服务器通信,除非这些服务器直接通过 IP 与服务联系。
对 Pod Egress 进行隔离
每个网络策略都有一个 podSelector 字段,该字段会选择一组(0 个或多个)Pod。当网络策略选择了一个 Pod 时,就称该网络策略适用于该 Pod。
此外,每个网络策略都可以根据 policyTypes 字段的值应用于入口和出口。如果 YAML 中未指定此字段,它的值会基于策略中的入口、出口规则默认设置,但默认设置并不靠谱,我们最好进行明确的设置。 一般情况下,如果没有任何出口网络策略适用于 Pod,那么它就是非隔离的出口。这里要注意,隔离是针对入口和出口独立评估的。一个 Pod 的入口和出口可以都隔离,也可以都不隔离,甚至进行单个隔离。如果一个 Pod 的出口没有进行隔离,那么所有的流量都可以从这个 Pod 中出来。 当一个出口网络策略适用于某个 Pod 时,该 Pod 的出口就会被隔离。对于隔离的 Pod,只有在网络策略允许的情况下,才允许网络出口,也就是网络策略白名单。 设置出口网络策略的第一步是对 Pod 进行出口隔离。我们最好先应用“默认拒绝所有”的策略,将所有 Pod 的出口都隔离了。apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-deny-all-egressspec: podSelector: {} egress: - to: ports: - protocol: TCP port: 53 - protocol: UDP port: 53 policyTypes: - Egress
不过要注意,默认情况下这个策略允许流量连接到任意 IP 上的 53 端口,以方便 DNS 查找。因此,尽管它可以防止出口出现问题,但不能防止数据泄露,因为攻击者可以将数据发送到 53 端口。
如果想知道 Pod 使用的是哪些 DNS 服务器,我们可以通过缩小访问范围进行确定。
例如,要将 DNS 范围缩小到仅提供 kube-dns 服务,可以执行以下操作:
标记 kube-system 命名空间:
kubectl label namespace kube-system networking/namespace=kube-system
应用以下网络策略:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: default-deny-all-egressspec: podSelector: {} egress: - to: - namespaceSelector: matchLabels: networking/namespace: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: TCP port: 53 - protocol: UDP port: 53 policyTypes: - Egress
重要提示:由于网络策略是带命名空间资源,因此每个命名空间都需要创建此策略。我们可以运行以下命令:
kubectl -n <namespace> create -f <filename>
另外,最好不要将其应用于 kube-system 命名空间,因为它可能会影响集群功能。
K8sMeetup明确 Pod 到互联网的出口
在每个命名空间中都采用了 default-deny-all-egress (默认拒绝所有出口)策略后,Pod 将无法连接到互联网,但是在大多数的应用程序中,会有一些 Pod 需要连接到互联网。对此,有一种设置方法:为允许连接互联网的 Pod 指定标签,并创建一个针对这些标签的网络策略。例如,以下网络策略允许具有 networking/allow-internet-egress=true 标签的 Pod 发送流量至所有网络端点(包括集群外部的端点)。另外,还是要注意,我们必须为每个命名空间创建该策略:
apiVersion: networking.k8s.io/v1kind: NetworkPolicymetadata: name: internet-egressspec: podSelector: matchLabels: networking/allow-internet-egress: "true" egress: - {} policyTypes: - Egress
这个策略比默认设置具有更高的安全性。不过对于更严格的策略集,理想情况下最好指定更细粒度的 CIDR 块,并明确列出允许的端口和协议。
K8sMeetup
明确 Pod 间的点对点通信
如果将 Pod 隔离,然后明确 Pod 到 Pod 之间的通信之后,在应用正常工作时,我们会发现,在使用 default-deny-all-egress 策略后,所有的通信都被限制了。对此,我们在入口方向上将每个连接放入白名单后,还需要把出口方向上的连接也放入白名单。无论是遵循上面的建议,允许所有名称空间内部通信,还是将各个 Pod 之间的连接列入白名单,或者采用自定义的方法,对于构建的每个入口策略,都需要制定相应的出口策略。
K8sMeetup补充出口网络策略
对于从一组 Pod 到另一组 Pod 之间进行通信的入口策略,构建对应的出口策略非常简单。首先,将 policyTypes 字段更改为仅包含 Egress 的数组,将 spec.podSelector 放在 spec.egress.to.podSelector 中,删除 ingress.from,并将从中提取的 ingress.from.podSelector 放到新的出口策略 spec.podSelector 中。这样就完成了命名空间内的一个入口策略。
至于跨命名空间的策略,如果已经用 network/namespace: 用标签标记了每个命名空间:kubectl label namespace networking/namespace=
那么,我们需要在入口策略中选择 ingress.from.namespaceselector 的命名空间作为出口策略的 metadata.namespace,并将在入口策略的 metadata.namespace 中指定的命名空间,放到出口策略的 egress.to.namespaceSelector 字段中。
这是一个例子:
https://www.stackrox.com/post/2020/01/kubernetes-egress-network-policies/
推荐阅读:
![d9abd84e5e827f15b047d6219700471e.png](https://img-blog.csdnimg.cn/img_convert/d9abd84e5e827f15b047d6219700471e.png)
![732af9e5c22a1f6ba2953ae0cab3a2e7.png](https://img-blog.csdnimg.cn/img_convert/732af9e5c22a1f6ba2953ae0cab3a2e7.png)