做者:宋淨超html
Cilium是一個純開源軟件,沒有哪家公司提供商業化支持,也不是由某一公司開源,該軟件用於透明地保護使用Linux容器管理平臺(如Docker和Kubernetes)部署的應用程序服務之間的網絡鏈接。linux
Cilium的基礎是一種名爲BPF的新Linux內核技術,它能夠在Linux自己動態插入強大的安全可見性和控制邏輯。因爲BPF在Linux內核中運行,所以能夠應用和更新Cilium安全策略,而無需對應用程序代碼或容器配置進行任何更改。git
基於微服務的應用程序分爲小型獨立服務,這些服務使用HTTP、gRPC、Kafka等輕量級協議經過API相互通訊。可是,現有的Linux網絡安全機制(例如iptables)僅在網絡和傳輸層(即IP地址和端口)上運行,而且缺少對微服務層的可見性。github
Cilium爲Linux容器框架(如Docker和Kubernetes)帶來了API感知網絡安全過濾。使用名爲BPF的新Linux內核技術,Cilium提供了一種基於容器/容器標識定義和實施網絡層和應用層安全策略的簡單而有效的方法。docker
注:Cilium中文意思是「纖毛「,它十分細小而又無處不在。編程
柏克萊封包過濾器(Berkeley Packet Filter,縮寫 BPF),是類Unix系統上數據鏈路層的一種原始接口,提供原始鏈路層封包的收發,除此以外,若是網卡驅動支持洪泛模式,那麼它可讓網卡處於此種模式,這樣能夠收到網絡上的全部包,無論他們的目的地是否是所在主機。參考維基百科和eBPF簡史。安全
如下是Cilium的特性。服務器
基於身份的安全性微信
Cilium可見性和安全策略基於容器編排系統的標識(例如,Kubernetes中的Label)。在編寫安全策略、審計和故障排查時,不再用擔憂網絡子網或容器IP地址了。網絡
卓越的性能
BPF利用Linux底層的強大能力,經過提供Linux內核的沙盒可編程性來實現數據路徑,從而提供卓越的性能。
API協議可見性+安全性
傳統防火牆僅根據IP地址和端口等網絡標頭查看和過濾數據包。Cilium也能夠這樣作,但也能夠理解並過濾單個HTTP、gRPC和Kafka請求,這些請求將微服務拼接在一塊兒。
專爲擴展而設計
Cilium是爲擴展而設計的,在部署新pod時不須要節點間交互,而且經過高度可擴展的鍵值存儲進行全部協調。
現代數據中心應用程序的開發已經轉向面向服務的體系結構(SOA),一般稱爲
這種向高度動態的微服務的轉變過程,給確保微服務之間的鏈接方面提出了挑戰和機遇。傳統的Linux網絡安全方法(例如iptables)過濾IP地址和TCP/UDP端口,但IP地址常常在動態微服務環境中流失。容器的高度不穩定的生命週期致使這些方法難以與應用程序並排擴展,由於負載均衡表和訪問控制列表要不斷更新,可能增加成包含數十萬條規則。出於安全目的,協議端口(例如,用於HTTP流量的TCP端口80)不能再用於區分應用流量,由於該端口用於跨服務的各類消息。
另外一個挑戰是提供準確的可見性,由於傳統系統使用IP地址做爲主要識別工具,其在微服務架構中的壽命可能才僅僅幾秒鐘,被大大縮短。
利用Linux BPF,Cilium保留了透明地插入安全可視性+強制執行的能力,但這種方式基於服務/pod/容器標識(與傳統系統中的IP地址識別相反),而且能夠根據應用層進行過濾 (例如HTTP)。所以,經過將安全性與尋址分離,Cilium不只能夠在高度動態的環境中應用安全策略,並且除了提供傳統的第3層和第4層分割以外,還能夠經過在HTTP層運行來提供更強的安全隔離。 。
BPF的使用使得Cilium可以以高度可擴展的方式實現以上功能,即便對於大規模環境也不例外。
可以保護現代應用程序協議,如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地址。
什麼時候使用此模式:此模式適用於高級用戶,須要瞭解底層網絡基礎結構。此模式適用於:
本地IPv6網絡
與雲網絡路由器配合使用
若是您已經在運行路由守護進程
應用程序容器和外部服務之間的流量的分佈式負載均衡。負載均衡使用BPF實現,容許幾乎無限的規模,而且若是未在源主機上執行負載均衡操做,則支持直接服務器返回(DSR)。
注意:負載均衡須要啓用鏈接跟蹤。這是默認值。
可見性和故障排查是任何分佈式系統運行的基礎。雖然咱們喜歡用tcpdump
和 ping
,它們很好用,但咱們努力爲故障排除提供更好的工具。包括如下工具:
使用元數據進行事件監控:當數據包被丟棄時,該工具不只僅報告數據包的源IP和目標IP,該工具還提供發送方和接收方的完整標籤信息等。
策略決策跟蹤:爲何丟棄數據包或拒絕請求。策略跟蹤框架容許跟蹤運行工做負載和基於任意標籤訂義的策略決策過程。
經過Prometheus導出指標:經過Prometheus導出關鍵指標,以便與現有儀表板集成。
網絡插件集成:CNI、libnetwork
容器運行時:containerd
Kubernetes:NetworkPolicy、Label、Ingress、Service
日誌記錄:syslog、fluentd
微信羣:聯繫我入羣
Slack:servicemesher.slack.com 須要邀請才能加入
Twitter: twitter.com/servicemesh…
GitHub:github.com/
更多Service Mesh諮詢請掃碼關注微信公衆號ServiceMesher。