Cilium——具備API感知的網路和安全性管理軟體
作者：宋淨超
Cilium是一個純開源軟體，沒有哪家公司提供商業化支援，也不是由某一公司開源，該軟體用於透明地保護使用Linux容器管理平臺（如Docker和Kubernetes）部署的應用程式服務之間的網路連線。
Cilium的基礎是一種名為BPF的新Linux核心技術，它可以在Linux本身動態插入強大的安全可見性和控制邏輯。由於BPF在Linux核心中執行，因此可以應用和更新Cilium安全策略，而無需對應用程式程式碼或容器配置進行任何更改。
基於微服務的應用程式分為小型獨立服務，這些服務使用 HTTP 、 RPC/">gRPC 、 Kafka 等輕量級協議通過API相互通訊。但是，現有的Linux網路安全機制（例如iptables）僅在網路和傳輸層（即IP地址和埠）上執行，並且缺乏對微服務層的可見性。
Cilium為Linux容器框架（如 ofollow,noindex"> Docker 和 Kubernetes） 帶來了API感知網路安全過濾。使用名為 BPF 的新Linux核心技術，Cilium提供了一種基於容器/容器標識定義和實施網路層和應用層安全策略的簡單而有效的方法。
注 ：Cilium中文意思是“纖毛“，它十分細小而又無處不在。
BPF
柏克萊封包過濾器 （Berkeley Packet Filter，縮寫 BPF），是類Unix系統上資料鏈路層的一種原始介面，提供原始鏈路層封包的收發，除此之外，如果網絡卡驅動支援洪泛模式，那麼它可以讓網絡卡處於此種模式，這樣可以收到網路上的所有包，不管他們的目的地是不是所在主機。參考維基百科和 eBPF簡史 。
特性
以下是Cilium的特性。
基於身份的安全性
Cilium可見性和安全策略基於容器編排系統的標識（例如，Kubernetes中的Label）。在編寫安全策略、審計和故障排查時，再也不用擔心網路子網或容器IP地址了。
卓越的效能
BPF利用Linux底層的強大能力，通過提供Linux核心的沙盒可程式設計性來實現資料路徑，從而提供卓越的效能。
API協議可見性+安全性
傳統防火牆僅根據IP地址和埠等網路標頭檢視和過濾資料包。Cilium也可以這樣做，但也可以理解並過濾單個HTTP、gRPC和Kafka請求，這些請求將微服務拼接在一起。
專為擴充套件而設計
Cilium是為擴充套件而設計的，在部署新pod時不需要節點間互動，並且通過高度可擴充套件的鍵值儲存進行所有協調。
為什麼選擇Cilium？
現代資料中心應用程式的開發已經轉向面向服務的體系結構（SOA），通常稱為
微服務
，其中大型應用程式被分成小型獨立服務，這些服務使用HTTP等輕量級協議通過API相互通訊。微服務應用程式往往是高度動態的，作為持續交付的一部分部署的滾動更新期間單個容器啟動或銷燬，應用程式擴充套件/縮小以適應負載變化。
這種向高度動態的微服務的轉變過程，給確保微服務之間的連線方面提出了挑戰和機遇。傳統的Linux網路安全方法（例如iptables）過濾IP地址和TCP/UDP埠，但IP地址經常在動態微服務環境中流失。容器的高度不穩定的生命週期導致這些方法難以與應用程式並排擴充套件，因為負載均衡表和訪問控制列表要不斷更新，可能增長成包含數十萬條規則。出於安全目的，協議埠（例如，用於HTTP流量的TCP埠80）不能再用於區分應用流量，因為該埠用於跨服務的各種訊息。
另一個挑戰是提供準確的可見性，因為傳統系統使用IP地址作為主要識別工具，其在微服務架構中的壽命可能才僅僅幾秒鐘，被大大縮短。
利用Linux BPF，Cilium保留了透明地插入安全可視性+強制執行的能力，但這種方式基於服務/pod/容器標識（與傳統系統中的IP地址識別相反），並且可以根據應用層進行過濾 （例如HTTP）。因此，通過將安全性與定址分離，Cilium不僅可以在高度動態的環境中應用安全策略，而且除了提供傳統的第3層和第4層分割之外，還可以通過在HTTP層執行來提供更強的安全隔離。 。
BPF的使用使得Cilium能夠以高度可擴充套件的方式實現以上功能，即使對於大規模環境也不例外。
功能概述
透明的保護API
能夠保護現代應用程式協議，如REST/HTTP、gRPC和Kafka。傳統防火牆在第3層和第4層執行，在特定埠上執行的協議要麼完全受信任，要麼完全被阻止。Cilium提供了過濾各個應用程式協議請求的功能，例如：
-
允許所有帶有方法
GET和路徑/public/.*的HTTP請求。拒絕所有其他請求。 -
允許
service1在Kafka topic上生成topic1，service2消費topic1。拒絕所有其他Kafka訊息。 -
要求HTTP標頭
X-Token: [0-9]+出現在所有REST呼叫中。
詳情請參考7層協議。
基於身份來保護服務間通訊
現代分散式應用程式依賴於諸如容器之類的技術來促進敏捷性並按需擴充套件。這將導致在短時間內啟動大量應用容器。典型的容器防火牆通過過濾源IP地址和目標埠來保護工作負載。這就要求不論在叢集中的哪個位置啟動容器時都要操作所有伺服器上的防火牆。
為了避免受到規模限制，Cilium為共享相同安全策略的應用程式容器組分配安全標識。然後，該標識與應用程式容器發出的所有網路資料包相關聯，從而允許驗證接收節點處的身份。使用鍵值儲存執行安全身份管理。
安全訪問外部服務
基於標籤的安全性是叢集內部訪問控制的首選工具。為了保護對外部服務的訪問，支援入口（ingress）和出口（egress）的傳統基於CIDR的安全策略。這允許限制對應用程式容器的訪問以及對特定IP範圍的訪問。
簡單網路
一個簡單的扁平第3層網路能夠跨越多個叢集連線所有應用程式容器。使用主機範圍分配器可以簡化IP分配。這意味著每個主機可以在主機之間沒有任何協調的情況下分配IP。
支援以下多節點網路模型：
-
Overlay ：基於封裝的虛擬網路產生所有主機。目前VXLAN和Geneve已經完成，但可以啟用Linux支援的所有封裝格式。
何時使用此模式：此模式具有最小的基礎架構和整合要求。它幾乎適用於任何網路基礎架構，唯一的要求是主機之間可以通過IP連線。
-
本機路由 ：使用Linux主機的常規路由表。網路必須能夠路由應用程式容器的IP地址。
何時使用此模式：此模式適用於高階使用者，需要了解底層網路基礎結構。此模式適用於：
負載均衡
應用程式容器和外部服務之間的流量的分散式負載均衡。負載均衡使用BPF實現，允許幾乎無限的規模，並且如果未在源主機上執行負載均衡操作，則支援直接伺服器返回（DSR）。
注意 ：負載均衡需要啟用連線跟蹤。這是預設值。
監控和故障排除
可見性和故障排查是任何分散式系統執行的基礎。雖然我們喜歡用 tcpdump 和 ping ，它們很好用，但我們努力為故障排除提供更好的工具。包括以下工具：
-
使用元資料進行事件監控：當資料包被丟棄時，該工具不僅僅報告資料包的源IP和目標IP，該工具還提供傳送方和接收方的完整標籤資訊等。
-
策略決策跟蹤：為什麼丟棄資料包或拒絕請求。策略跟蹤框架允許跟蹤執行工作負載和基於任意標籤定義的策略決策過程。
-
通過Prometheus匯出指標：通過Prometheus匯出關鍵指標，以便與現有儀表板整合。
整合
-
網路外掛整合： CNI 、 libnetwork
-
容器執行時： containerd
-
日誌記錄：syslog、fluentd
參考
ServiceMesher社群資訊
微信群：聯絡我入群
社群官網： www.servicemesher.com
Slack： servicemesher.slack.com 需要邀請才能加入
Twitter: twitter.com/servicemesh…
GitHub： github.com/
更多Service Mesh諮詢請掃碼關注微信公眾號ServiceMesher。
