Tungsten Fabric与K8s集成指南丨创建安全策略
作者：吴明秘
Hi！欢迎来到Tungsten Fabric与Kubernetes集成指南系列，本文介绍如何创建安全策略。 Tungsten Fabric与K8s集成指南系列文章，由TF中文社区为您呈现，旨在帮助大家了解Tungsten Fabric与K8s集成的基础知识。大家在相关部署中有什么经验，或者遇到的问题，欢迎与我们联系。
安全策略可以通过限制端口、网络协议等方式控制任意pod之间的访问，以及pod与service之间的访问。在K8s集群中安全策略对应的是Network Policy，在Tungsten Fabric中安全策略对应的Firewall Rule，两者是会实时同步的。
pod之间的访问控制
安全策略的控制是全局的，跨命名空间，跨network，所以创建策略的时候要尽可能详细地指定此端到彼端的一些参数，包括端口、命名空间、IP地址段等等。
根据第二章节的信息，可以知道目前有——
两个命名空间：test-ns1 test-ns2
三个network：k8s-ns1-pod-net01 k8s-ns1-pod-net02 k8s-ns2-pod-net01
四个pod：
nginx01-ns1-net01
nginx01-ns1-net02
nginx01-ns2-net01
nginx02-ns2-net01
而k8s-ns1-pod-net01与k8s-ns1-pod-net02已经互通（通过新建TF router连通），k8s-ns1-pod-net01 与k8s-ns2-pod-net01已经互通（通过TF Network Policy连通）。
首先，新增一条默认禁止访问策略，禁止任何流量访问test-ns1的pod，配置如下：
#pod选择器设置为空，表示选择所有pod，即控制整个命名空间。
#只写了ingress生效，又把podSelector设置为空，表示拒绝其它命名空间访问，拒绝所有入站请求。
#没有加egress，所以默认egress是允许本命名空间所有pod出站。
创建策略后，验证从test-ns2的k8s-ns2-pod-net01网络是否能访问到test-ns1的k8s-ns1-pod-net01网络。
验证过程如下图所示，首先从test-ns2的pod去ping test-ns1的pod是可以通的，但是在创建了Network Policy之后，就无法ping通了，说明Network Policy限制了从其他地方的流量去访问test-ns1的pod，而即使是test-ns1内部的pod都无法相互访问。
而再Tungsten Fabric的管理界面上，会看到一条新的Firewall Rule：
然后，再新增一条安全策略，允许子网20.10.10.0/24里的pod访问test-ns1中有标签为nginx-ns1的pod的80端口（test-ns1中的两个pod均带有此标签），除了IP为20.10.10.3的pod，具体配置如下：
创建策略后，验证从test-ns2的pod是否能访问到test-ns1的pod的80端口。
验证过程如下图所示，首先从test-ns2的两个pod（20.10.10.1和20.10.10.3）用curl去请求test-ns1 pod（10.10.10.1）的80端口，未新建安全策略前，curl请求均失败了。
创建安全策略之后，只有pod（20.10.10.1）能成功请求pod（10.10.10.1），而pod（20.10.10.3）无法成功请求对应的80端口，说明新建的策略是正常生效的。
Tungsten Fabric上新建了三条对应的Firewall Rule，分别为：
- 允许网段10.10.0/24的pod问test-ns1中带标签app=nginx-ns1的pod；
- 禁止ip为10.10.3/32的pod访问test-ns1中带标签app=nginx-ns1的pod；
- 禁止所有的pod访问test-ns1中带标签app=nginx-ns1的pod。
三条规则组合后，就能实现我们预期的pod隔离效果。
pod与service之间的访问控制
K8s的service是一个抽象概念，定义了一个服务的多个pod逻辑合集和访问pod的策略，一般把service称为微服务。
在此，首先在test-ns1和test-ns2中都各自新建一个service，配置如下：
执行kubectl创建命令，两个service分别在test-ns1和test-ns2中被创建了出来，对应的在Tungsten Fabric的load balancing列表也会生成这两个service的信息。
通过test-ns1的pod（10.10.10.1），可以使用curl直接请求service的域名。
现在通过新建一条K8s的Network Policy，去禁止test-ns1的pod（10.10.10.1）去访问test-ns2的service（nginx-ns2）。
禁止test-ns1的pod（10.10.10.1）请求test-ns2的service（nginx-ns2）的ClusterIP（10.96.0.12），具体配置如下：
验证流程：
1.test-ns1的pod（10.10.1）在未创建网络策略deny-service-ip之前，能够通过curl成功请求test-ns2的service（nginx-ns2），能够通过nslookup成功请求到kube-system的service（kube-dns）；
2. 在test-ns1命名空间中创建K8s的网络策略deny-service-ip；
3.test-ns1的pod（10.10.1）在已创建deny-service-ip网络策略之后，不能够通过curl成功请求test-ns2的service（nginx-ns2），能够通过nslookup成功请求到kube-system的service（kube-dns）。
所以网络策略deny-service-ip确实是禁止了test-ns1的pod（10.10.10.1），而不会影响它访问其他的service clusterip。
（作者来自深圳市天源景云科技有限公司）
“Tungsten Fabric+K8s集成指南”系列文章——
第一篇：部署准备与初始状态
第二篇：创建虚拟网络
“Tungsten Fabric+K8s轻松上手”系列文章——
第一篇：TF Carbide 评估指南–准备篇
第二篇：通过Kubernetes的服务进行基本应用程序连接
第三篇：通过Kubernetes Ingress进行高级外部应用程序连接
第四篇：通过Kubernetes命名空间实现初步的应用程序隔离
第五篇：通过Kubernetes网络策略进行应用程序微分段
关注微信：TF中文社区
