简介
Kubernetes提供了NetworkPolicy的Feature，支持按Namespace和按Pod级别的网络访问控制。它利用label指定namespaces或pod，底层用iptables实现。这篇文章简单介绍Kubernetes NetworkPolicy在Calico上的工作原理。
1.控制面数据流
Network Policy是一种kubernetes资源，经过定义、存储、配置等流程使其生效。以下是简要流程：通过kubectl client创建network policy资源；
calico的policy-controller监听network policy资源，获取到后写入calico的etcd数据库；
node上calico-felix从etcd数据库中获取policy资源，调用iptables做相应配置。
2.资源配置模板
Network Policy支持按Pod和Namespace级别的访问控制，定义该资源可以参考以下模板。
指定pod标签访问
我们要对namespace为myns，带有"role: backend"标签的所有pod进行访问控制：只允许标签为"role: frontend"的Pod，并且TCP端口为6379的数据流入，其他流量都不允许。
指定namespaces标签访问
我们要对标签为"role: frontend"的所有Pod进行访问控制：只允许namespace标签为"user: bob"的各Pod，并且TCP端口为443的数据流入，其他流量都不允许。
3.NetworkPolicy数据结构定义
看完上边的示例，想必大家对NetworkPolicy的资源对象有一定的了解。接下来我们具体看下Kubernetes对该接口的定义：
简而言之，该资源指定了“被控制访问Pod”和“准入Pod”两类Pod，这可以从spec的podSelector和ingress-from的Selector进行配置。
接下来我们就看下Kubernetes+Calico的Network policy实现细节。
4.测试版本
以下是测试中使用的组件版本：
kubernetes:
- master: v1.9.0
- node: v1.9.0
calico:
- v2.5.0
- calico-policy-controller (quay.io/calico/kube-policy-controller:v0.7.0)
5.运行配置
calico侧，除基本配置外的新建资源：
service-account: calico-policy-controller
rbac:
- ServiceRole: calico-policy-controller
- ServiceRoleBinding: calico-policy-controller
deployment: calico-policy-controller
Kubernets侧，新建network policy资源；
6.运行状态
在原有正常工作的Kubernetes集群上，我们新加了calico-policy-controller容器，它里面主要运行controller进程：
-
calico-policy-controller
在这里插入图片描述在这里插入图片描述
我们可以看到，启动了controller进程，该进程Established两个端口：6443对应的kubernetes api-server端口；2379对应的calico etcd端口。
7.Calico-felix对policy的配置
数据包走向
下图是calico流量处理流程(从这里找到)。每个Node的calico-felix从etcd数据库拿下来policy信息，用iptables做底层实现，最主要的就是：cali-pi-[POLICY]@filter 这个Chain。
Network Policy报文处理过程中使用的标记位：
0x2000000: 是否已经经过了policy规则检测，置1表示已经过
符号解释：
from-XXX: XXX发出的报文； tw: 简写，to wordkoad endpoint； to-XXX: 发送到XXX的报文； po: 简写，policy outbound； cali-: 前缀，calico的规则链； pi: 简写，policy inbound； wl: 简写，workload endpoint； pro: 简写，profile outbound； fw: 简写，from workload endpoint； pri: 简写，profile inbound。
下面通过访问“禁止所有流量”策略的Pod，来观察对应的iptables处理：
流量进入前
流量进入后
可以看到，DROP的pkts由0变成了3。即该数据包经过MARK、cali-pi-default.web-deny-all两个target处理，被标记符合“拒绝”条件，流经到DROP被丢弃。
8.流程分析案例
以下是一个“禁止所有流量进入”的测试案例，通过它看下整体流程。
模型
DENY all traffic to an application
查看app-web的标签
在default的namespace下创建了一个名称为web的service。它的IP和标签如下：
配置policy
首先通过kubectl查看k8s资源：
再次，通过calicoctl和etcdctl查看calico资源：
查看felix进行network policy配置的日志
增加 && 删除Policy
查看node上的iptables规则
从另一pod上访问该服务
可见，访问该service的80端口失败；ping所对应的Pod试试：
Ping该Pod也是失败，达到了“禁止所有流量进入”的预期。
9.总结
Kubernetes的NetworkPolicy实现了访问控制，解决了部分网络安全的问题。但截至现在，Kubernetes、Calico对其支持尚未完全，部分特性(egress等)仍在进行中；另一方面calico的每个Node上配置大量iptables规则，加上不同维度控制的增加，导致运维、排障难度较大。所以对网络访问控制有需求的用户来讲，能否使用还需综合考虑。
参考资料：
[1] https://ahmet.im/blog/kubernetes-network-policy/
[2] https://github.com/ahmetb/kubernetes-network-policy-recipes
[3] https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#networkpolicy-v1-networking
[4] http://www.lijiaocn.com/%E9%A1%B9%E7%9B%AE/2017/04/11/calico-usage.html
