點擊下載文檔，查看本文所有相關鏈接https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case4.pdf
在大多數生產環境中，需要實施網絡訪問控制。Kubernetes提供了一種方法來描述Pod 組應該如何通過使用NetworkPolicy資源進行通信。
與Kubernetes中的大多數事情一樣，要使網絡策略正常運行，您需要一個支持它們的Kubernetes CNI插件。
使用場景
在幾乎所有環境中，爲應用程序需要通信的組件建立明確的規則，都是一個好主意。Kubernetes網絡策略規範是一種直接的方法，可讓您將NetworkPolicy直接與應用程序清單集成在一起。
NetworkPolicy定義資源的方式，使您可以精確地指定哪些網絡通信是被允許的，而哪些則不允許，同時使用podSelector定義處理在Kubernetes上運行的應用程序的動態屬性。
這意味着您的策略可以針對單個Pod或Pod組，從而將安全範圍“縮小”到Pod的大小。
嚴格定義的網絡策略與default-deny配置相結合，可以避免由於惡意應用程序入侵，和/或行爲不當，或者配置錯誤而造成的麻煩。例如，一個應用程序組件可能具有滯留的緩存DNS條目或錯誤的配置參數，導致它與錯誤的後端進行通信。或者應用程序可能會被攻陷並被用作跳板，執行偵查，嘗試橫向滲透，或者只是使用Pod對Kubernetes API的訪問權限來啓動一些加密貨幣挖礦Pod，以竊取您的計算資源。
使用網絡策略保護示例應用程序的安全
網絡策略設計的主題比本指南中允許的空間要大得多。在此示例中，我們將執行以下操作：
- 爲我們的default命名空間創建一個default-deny
Ingress策略。這意味着命名空間內的所有傳入Pods的連接必須明確被允許； - 爲每個示例應用程序組件創建一個Ingress NetworkPolicy對象，僅允許那些我們確定的對象。
步驟1：明確哪些組件應當可以相互通信
首先，我們需要提醒自己，應用程序的各個組件應該如何通信。爲此，我們將回到在簡介中看到的應用程序圖：
從該圖中可以看到：
- 外界需要到達yelb-ui的TCP端口80-（1）和（2）
- yelb-ui需要到達yelb-appserver的TCP端口4567
- yelb-appserver反過來將需要到達yelb-db的TCP端口5432，以及
- … yelb-cache的TCP端口6379。
步驟2：如何識別組件？
請記住，NetworkPolicy資源使用選擇器來識別策略適用於哪個Pod，以及該策略將要控制的流量的源和目的地是什麼。
在本演示中，我們將使用podSelectror方法，因此需要獲取應用到應用程序Pod的標籤列表。讓我們查看cnawebapp-loadbalancer.yaml示例應用程序的清單，並收集標籤：
現在準備編寫我們的策略。
部署後，這些策略將以以下方式控制應用程序組件之間的通信：
步驟3：“default-deny”策略
確保您位於沙箱控制節點上，以root用戶身份登錄，並且位於正確的目錄中：
#確認您是root賬戶
whoami | grep root || sudo -s#切換到清單目錄
cd /home/centos/yelb/deployments/platformdeployment/Kubernetes/yaml在此步驟中，我們將創建一個策略，該策略將阻止所有未明確允許的網絡通信。在這一演示中，我們將只限制Ingress流量；但實際上，您也可以控制Egress流量（但是這樣做時要注意這可能會阻止DNS查詢！）：
策略基本上說：“對於任何Pod，都應用一個沒有規則的Ingress策略”，這將導致應用這個策略的，所有流向這個命名空間Pods的傳入流量被丟棄掉。
步驟4：“yelb-ui”的策略
該yelb-ui和其他組件在某種意義上說有一些不同，因爲它是唯一一個可以被從外部訪問的組件。因此，其ingress:定義將使用ipBlock的0.0.0.0/0，以表示“每個人”：
該策略表示：“對於具有應用標籤app: yelb-ui和tier: frontend的Pods，允許傳入來自任何源IP的流量，只要它去往Pod的TCP端口80”。
步驟5：示例應用中其他Pod的策略
我們示例應用程序中的其他3個Pod僅會看到來自其他Pod的流量，因此其策略將使用帶有允許發送流量的Pod標籤的podSelector參數：
步驟6：在應用策略之前測試
爲了能有一個“前後”對比，讓我們部署示例應用程序並獲取基線：
#部署我們的應用
kubectl create -f cnawebapp-loadbalancer.yaml等待應用啓動並在外部可用：
#獲得我們程序yelb-ui Service的外部DNS名字:
kubectl get svc -o wide | grep yelb-ui | awk '{print $4}'我們應該可以看到類似a0b8dfc14916811e9b411026463a4a33-1258487840.us-west-1.elb.amazonaws.com的輸出；在網絡瀏覽器中打開它；樣本應用程序應當加載了。 接下來，我們知道所有Pod通信都是不受限制的，因此我們應該能夠從yelb-ui ping 到yelb-db——這是在應用程序正常運行且我們不進行故障排除動作的情況下，本來不應該發生的活動：
#獲得"yelb-ui"的完整Pod名字
src_pod=$(kubectl get pods | grep yelb-ui | awk '{print $1}')#獲得"yelb-db"的IP:
db_pod_ip=$(kubectl get pods -o wide | grep yelb-db | awk '{print $6}')#從"yelb-ui" ping"yelb-db":
kubectl exec -it ${src_pod} ping ${db_pod_ip}我們應該看到該ping命令正在接收響應；因此存在不受限制的網絡連接。按^ C停止命令。
步驟7：部署策略並測試結果
在最後一步，我們將部署策略並觀察其效果：
#部署網絡策略
kubectl create -f yelb-policy.yaml運行上面的命令後，請等待幾秒鐘以穩定下來。Tungsten Fabric將在後臺生成適當的安全組，並進行安裝。讓我們測試一下我們曾經可以正常運行的ping命令是否仍然有效：
#從"yelb-ui" ping “yelb-db” again:
kubectl exec -it ${src_pod} ping ${db_pod_ip}這次，我們看到沒有響應，因爲該通信現在已被該策略阻止。接下來，測試是否仍可以通過網絡瀏覽器訪問該應用——應該可以！
步驟8：探索Tungsten Fabric的安全流量組可視化
Tungsten Fabric包含一個功能，可在“項目”中實現流量可視化，在我們的案例中，該項目對應於Kubernetes Namespace。
要訪問它，請訪問Carbide Evaluation Page鏈接，用於獲取訪問沙箱控制節點——在頂部有一個名爲Contrail UI的鏈接，完成login和password的輸入。單擊鏈接，然後在左上角單擊“Monitor”圖標，然後在菜單中單擊“Security” -> “Traffic Groups”。然後在頂部的標籤鏈，在其末尾選擇“k8s-default”：
您應該看到類似於以下的圖表：
繼續測試。您看到的流，代表示例應用程序在做的事情，包括無法從 yelb-uiping到yelb-db，以及yelb-appserver的出站請求（如果我們去查看，將轉到yelb-db的DNS查詢）。
清理
一旦進行了足夠的探索，可以隨時清理：
#卸載Network Policy
kubectl delete -f yelb-policy.yaml#刪除我們的示例應用程序:
kubectl delete -f cnawebapp-loadbalancer.yaml#刪除策略清單:
rm -f yelb-policy.yaml回顧和資源
對於許多（即使不是全部）生產部署，控制應用程序的網絡通信能力至關重要。在Kubernetes上運行的應用程序實現此類控件的方法是通過NetwokPolicy資源。但是，要使這些資源真正起作用，您需要一個支持它們的CNI插件。
Tungsten Fabric提供了完整的NetworkPolicy支持，無論集成Tungsten Fabric的Kubernetes在哪裏運行，是在私有數據中心，還是在公共雲中。
網絡策略可以變得非常簡單或非常複雜，而找出最適合您的應用程序的最佳方法，就是在我們提供的用例和示例基礎上更深入地研究。這裏有一些資源可能會有所幫助：
- 網絡策略的詳細介紹
- 一個不錯的GitHub存儲庫，其中包含大量具有詳細文檔的網絡策略清單示例
- 在2019Kubecon上的演講中有一個介紹網絡策略的很好的材料
（上述資源鏈接，可點擊下載文檔查看https://tungstenfabric.org.cn/assets/uploads/files/tf-ceg-case4.pdf）
號外
TF中文社區3月Meetup活動，將聚焦Tungsten Fabric與K8s的集成，由重量級嘉賓分享Tungsten Fabric與K8s的部署和實踐，詳細演示操作過程，並解答關於Tungsten Fabric和K8s的一切問題。關注“TF中文社區”公衆號，瞭解最新活動信息。
至此，Tungsten Fabric Carbide指南文章系列文章告一段落，往期回顧——
第一篇：TF Carbide 評估指南–準備篇
第二篇：通過Kubernetes的服務進行基本應用程序連接
第三篇：通過Kubernetes Ingress進行高級外部應用程序連接
第四篇：通過Kubernetes命名空間實現初步的應用程序隔離
關注微信：TF中文社區
郵箱：[email protected]
