作者:吴明秘

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,分别为:

  1. 允许网段10.10.0/24的pod问test-ns1中带标签app=nginx-ns1的pod;
  2. 禁止ip为10.10.3/32的pod访问test-ns1中带标签app=nginx-ns1的pod;
  3. 禁止所有的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);

  1. 在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中文社区