NetworkPolicy¶
在 Kubernetes 中要实现容器之间网络的隔离,是通过一个专门的 API 对象 NetworkPolicy
(网络策略)来实现的,要让网络策略生效,就需要特定的网络插件支持,目前已经实现了 NetworkPolicy
的网络插件包括 Calico、Weave 和 kube-router 等项目,但是并不包括 Flannel 项目。所以说,如果想要在使用 Flannel 的同时还使用 NetworkPolicy 的话,你就需要再额外安装一个网络插件,比如 Calico 项目,来负责执行 NetworkPolicy。由于我们这里使用的是 Flannel 网络插件,所以首先需要安装 Calico 来负责网络策略。
安装 Calico¶
首先确定 kube-controller-manager 配置了如下的两个参数:
......
spec:
containers:
- command:
- kube-controller-manager
- --allocate-node-cidrs=true
- --cluster-cidr=10.244.0.0/16
......
然后下载需要使用的资源清单文件:
$ curl https://docs.projectcalico.org/v3.10/manifests/canal.yaml -O
如果之前配置的 pod CIDR 就是 10.244.0.0/16
网段,则可以跳过下面的配置,如果不同则可以使用如下方式进行替换:
$ POD_CIDR="<your-pod-cidr>" \
$ sed -i -e "s?10.244.0.0/16?$POD_CIDR?g" canal.yaml
然后直接安装即可:
$ kubectl apply -f canal.yaml
网络策略¶
默认情况下 Pod 是可以接收来自任何发送方的请求,也可以向任何接收方发送请求。而如果我们要对这个情况作出限制,就必须通过 NetworkPolicy
对象来指定。
如下资源清单文件所示,我们这里定义了一个网络策略资源清单文件:(test-networkpolicy.yaml)
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: test-network-policy
namespace: default
spec:
podSelector:
matchLabels:
role: db
policyTypes:
- Ingress
- Egress
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
- ports:
- protocol: TCP
port: 80
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
与所有其他的 Kubernetes 资源对象一样,NetworkPolicy 需要 apiVersion
、kind
和 metadata
字段,我们通过 spec.podSelector
字段定义这个 NetworkPolicy 的限制范围,因为 NetworkPolicy 目前只支持定义 ingress
规则,所以这里的 podSelector
本质上是为该策略定义 “目标pod”, 比如我们这里 matchLabels:role=db
表示的就是当前 Namespace 里携带了 role=db
标签的 Pod。而如果你把 podSelector
字段留空:
spec:
podSelector: {}
那么这个 NetworkPolicy 就会作用于当前 Namespace 下的所有 Pod。
然后每个 NetworkPolicy 包含一个 policyTypes
列表,可以是一个 Ingress
、Egress
或者都包含,该字段表示给当前策略是否应用于所匹配的 Pod 的入口流量、出口流量或者二者都包含,如果没有指定 policyTypes
,则默认情况下表示 Ingress
入口流量,如果配置了任何出口流量规则,则将指定为 Egress
。
规则
一旦 Pod 被 NetworkPolicy 选中,那么这个 Pod 就会进入“拒绝所有”(Deny All)
的状态,即这个 Pod 既不允许被外界访问,也不允许对外界发起访问,所以 NetworkPolicy 定义的规则,其实就是“白名单”了。
比如上面示例表示的是该隔离规则只对 default 命名空间下的,携带了 role=db
标签的 Pod 有效。限制的请求类型包括 ingress(流入)和 egress(流出)。
ingress: 每个 NetworkPolicy 包含一个 ingress 规则的白名单列表。其中的规则允许同时匹配 from
和 ports
部分的流量。比如上面示例中我们配置的入口流量规则如下所示:
ingress:
- from:
- ipBlock:
cidr: 172.17.0.0/16
except:
- 172.17.1.0/24
- namespaceSelector:
matchLabels:
project: myproject
- podSelector:
matchLabels:
role: frontend
- ports:
- protocol: TCP
port: 80
这里的 ingress 规则中我们定义了 from
和 ports
,表示允许流入的白名单
和端口,上面我们也说了 Kubernetes 会拒绝任何访问被隔离 Pod 的请求,除非这个请求来自于以下“白名单”里的对象,并且访问的是被隔离 Pod 的 8- 端口。而这个允许流入的白名单
中指定了三种并列的情况,分别是:ipBlock
、namespaceSelector
和 podSelector
:
- default 命名空间下面带有
role=frontend
标签的 Pod - 带有
project=myproject
标签的 Namespace 下的任何 Pod - 任何源地址属于
172.17.0.0/16
网段,且不属于172.17.1.0/24
网段的请求。
egress: 每个 NetworkPolicy 包含一个 egress 规则的白名单列表。每个规则都允许匹配 to
和 port
部分的流量。比如我们这里示例规则的配置:
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/24
ports:
- protocol: TCP
port: 5978
表示 Kubernetes 会拒绝被隔离 Pod 对外发起任何请求,除非请求的目的地址属于 10.0.0.0/24
网段,并且访问的是该网段地址的 5978
端口。
测试¶
比如现在我们创建一个 Pod,带有 role=db
的 Label 标签:(test-networkpolicy-pod.yaml)
apiVersion: v1
kind: Pod
metadata:
name: test-networkpolicy
labels:
role: db
spec:
containers:
- name: testnp
image: nginx
直接创建这个 Pod:
$ kubectl apply -f test-networkpolicy-pod.yaml
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-a 1/1 Running 4 4h3m 10.244.1.236 ydzs-node1 <none> <none>
pod-b 1/1 Running 4 4h3m 10.244.2.123 ydzs-node2 <none> <none>
test-networkpolicy 1/1 Running 0 4m49s 10.244.3.2 ydzs-node3 <none> <none>
这个时候我们用一个已经存在的 Pod 来对这个 Pod 发起一个网络请求:
$ kubectl exec pod-a wget 10.244.3.2
Connecting to 10.244.3.2 (10.244.3.2:80)
saving to 'index.html'
index.html 100% |********************************| 612 0:00:00 ETA
'index.html' saved
我们可以看到可以成功请求,这个时候我们来创建上面的 NetworkPolicy 对象:
$ kubectl apply -f test-networkpolicy.yaml
networkpolicy.networking.k8s.io/test-network-policy created
这个时候我们创建了一个网络策略,由于匹配了网络策略的就会拒绝所有的网络请求,需要通过白名单来进行开启请求,由于我们这里的测试 Pod 明显没有在白名单之中,所以就会拒绝网络请求了:
$ kubectl exec pod-a wget 10.244.3.2
Connecting to 10.244.3.2 (10.244.3.2:80)
# 请求会一直 hang 住
这个时候我们可以用 NetworkPolicy 白名单里面匹配的 Pod 来对上面的 Pod 发起网络请求,比如在带有标签 project=myproject
的 Namespace 下面的 Pod 来发起网络请求,或者给 pod-a 加上一个 role=frontend
的标签:
$ kubectl label pod pod-a role=frontend
pod/pod-a labeled
这个时候重新发起一个网络请求可以看到已经可以成功了,因为我们访问的 Pod 进程默认的端口就是 80 端口,是匹配白名单的:
$ kubectl exec pod-a -- wget 10.244.3.2 -O-
Connecting to 10.244.3.2 (10.244.3.2:80)
writing to stdout
- 100% |********************************| 612 0:00:00 ETA
written to stdout
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>
我们可以看到已经成功了,Kubernetes 的 NetworkPolicy 实现了访问控制,依赖的底层是依靠网络插件添加 iptables 规则来进行控制的,但是在每个节点上都需要配置大量 iptables 规则,加上不同维度控制的增加,导致运维、排障难度较大,所以如果不是特别需要的场景,最好不要使用了。