溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
作者：吳明秘
Hi！歡迎來到Tungsten Fabric與Kubernetes集成指南系列，本文介紹如何創建安全策略。Tungsten Fabric與K8s集成指南系列文章，由TF中文社區為您呈現，旨在幫助大家了解Tungsten Fabric與K8s集成的基礎知識。大家在相關部署中有什么經驗，或者遇到的問題，歡迎與我們聯系。
安全策略可以通過限制端口、網絡協議等方式控制任意pod之間的訪問，以及pod與service之間的訪問。在K8s集群中安全策略對應的是Network Policy，在Tungsten Fabric中安全策略對應的Firewall Rule，兩者是會實時同步的。
安全策略的控制是全局的，跨命名空間，跨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，分別為：
三條規則組合后，就能實現我們預期的pod隔離效果。
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）；
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中文社區
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
