Tungsten Fabric與K8s集成指南丨創(chuàng)建安全策略

作者：吳明秘

Hi！歡迎來到Tungsten Fabric與Kubernetes集成指南系列，本文介紹如何創(chuàng)建安全策略。Tungsten Fabric與K8s集成指南系列文章，由TF中文社區(qū)為您呈現(xiàn)，旨在幫助大家了解Tungsten Fabric與K8s集成的基礎(chǔ)知識。大家在相關(guān)部署中有什么經(jīng)驗，或者遇到的問題，歡迎與我們聯(lián)系。

安全策略可以通過限制端口、網(wǎng)絡(luò)協(xié)議等方式控制任意pod之間的訪問，以及pod與service之間的訪問。在K8s集群中安全策略對應(yīng)的是Network Policy，在Tungsten Fabric中安全策略對應(yīng)的Firewall Rule，兩者是會實時同步的。

pod之間的訪問控制

安全策略的控制是全局的，跨命名空間，跨network，所以創(chuàng)建策略的時候要盡可能詳細地指定此端到彼端的一些參數(shù)，包括端口、命名空間、IP地址段等等。

根據(jù)第二章節(jié)的信息，可以知道目前有——

兩個命名空間：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已經(jīng)互通（通過新建TF router連通），k8s-ns1-pod-net01 與k8s-ns2-pod-net01已經(jīng)互通（通過TF Network Policy連通）。

首先，新增一條默認禁止訪問策略，禁止任何流量訪問test-ns1的pod，配置如下：

#pod選擇器設(shè)置為空，表示選擇所有pod，即控制整個命名空間。
#只寫了ingress生效，又把podSelector設(shè)置為空，表示拒絕其它命名空間訪問，拒絕所有入站請求。
#沒有加egress，所以默認egress是允許本命名空間所有pod出站。

創(chuàng)建策略后，驗證從test-ns2的k8s-ns2-pod-net01網(wǎng)絡(luò)是否能訪問到test-ns1的k8s-ns1-pod-net01網(wǎng)絡(luò)。

驗證過程如下圖所示，首先從test-ns2的pod去ping test-ns1的pod是可以通的，但是在創(chuàng)建了Network Policy之后，就無法ping通了，說明Network Policy限制了從其他地方的流量去訪問test-ns1的pod，而即使是test-ns1內(nèi)部的pod都無法相互訪問。

而再Tungsten Fabric的管理界面上，會看到一條新的Firewall Rule：

然后，再新增一條安全策略，允許子網(wǎng)20.10.10.0/24里的pod訪問test-ns1中有標簽為nginx-ns1的pod的80端口（test-ns1中的兩個pod均帶有此標簽），除了IP為20.10.10.3的pod，具體配置如下：

創(chuàng)建策略后，驗證從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請求均失敗了。

創(chuàng)建安全策略之后，只有pod（20.10.10.1）能成功請求pod（10.10.10.1），而pod（20.10.10.3）無法成功請求對應(yīng)的80端口，說明新建的策略是正常生效的。

Tungsten Fabric上新建了三條對應(yīng)的Firewall Rule，分別為：

1. 允許網(wǎng)段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。

三條規(guī)則組合后，就能實現(xiàn)我們預(yù)期的pod隔離效果。

pod與service之間的訪問控制

K8s的service是一個抽象概念，定義了一個服務(wù)的多個pod邏輯合集和訪問pod的策略，一般把service稱為微服務(wù)。

在此，首先在test-ns1和test-ns2中都各自新建一個service，配置如下：

執(zhí)行kubectl創(chuàng)建命令，兩個service分別在test-ns1和test-ns2中被創(chuàng)建了出來，對應(yīng)的在Tungsten Fabric的load balancing列表也會生成這兩個service的信息。

通過test-ns1的pod（10.10.10.1），可以使用curl直接請求service的域名。

現(xiàn)在通過新建一條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）在未創(chuàng)建網(wǎng)絡(luò)策略deny-service-ip之前，能夠通過curl成功請求test-ns2的service（nginx-ns2），能夠通過nslookup成功請求到kube-system的service（kube-dns）；

2. 在test-ns1命名空間中創(chuàng)建K8s的網(wǎng)絡(luò)策略deny-service-ip；

3.test-ns1的pod（10.10.1）在已創(chuàng)建deny-service-ip網(wǎng)絡(luò)策略之后，不能夠通過curl成功請求test-ns2的service（nginx-ns2），能夠通過nslookup成功請求到kube-system的service（kube-dns）。

所以網(wǎng)絡(luò)策略deny-service-ip確實是禁止了test-ns1的pod（10.10.10.1），而不會影響它訪問其他的service clusterip。

（作者來自深圳市天源景云科技有限公司）

“Tungsten Fabric+K8s集成指南”系列文章---

第一篇：部署準備與初始狀態(tài)
第二篇：創(chuàng)建虛擬網(wǎng)絡(luò)

“Tungsten Fabric+K8s輕松上手”系列文章---

第一篇：TF Carbide 評估指南--準備篇
第二篇：通過Kubernetes的服務(wù)進行基本應(yīng)用程序連接
第三篇：通過Kubernetes Ingress進行高級外部應(yīng)用程序連接
第四篇：通過Kubernetes命名空間實現(xiàn)初步的應(yīng)用程序隔離
第五篇：通過Kubernetes網(wǎng)絡(luò)策略進行應(yīng)用程序微分段

關(guān)注微信：TF中文社區(qū)