Cilium服務(wù)網(wǎng)格的下一代雙向認(rèn)證
mTLS的主題上，并研究Cilium如何提供基于mTLS非sidecar模式的雙向認(rèn)證，其同時具備出色的安全性和性能優(yōu)勢。
理解度｜適中
隨著技術(shù)的演進與發(fā)展，雙向認(rèn)證逐步成為安全的基石，日常生產(chǎn)、生活中使用的SSH、mTLS或IPsec等協(xié)議和技術(shù)都基于此。伴隨云原生2.0的來臨，雙向認(rèn)證將是確保Kubernetes生態(tài)和整個云原生基礎(chǔ)設(shè)施中服務(wù)之間的通信安全的理想方案。在該文中，將探究Cilium和Cilium Service Mesh是如何利用eBPF為服務(wù)提供一種新的基于身份(IBE)的雙向認(rèn)證方案，其高性能的數(shù)據(jù)平面可以支持任何網(wǎng)絡(luò)協(xié)議，而無需改變應(yīng)用程序或注入sidecar。同時我們還將探究如何通過擴展身份概念以涵蓋進程、二進制文件和執(zhí)行環(huán)境等來大規(guī)模增強安全模型，例如，只允許在非特權(quán)環(huán)境中運行的某些二進制文件相互認(rèn)證。
雙向認(rèn)證
雙向認(rèn)證是指兩方，即發(fā)送方和接收方，相互認(rèn)證對方的身份，以確保他們都是在與他們期望溝通的一方進行對話，以前稱為相互實體認(rèn)證，因為兩個或多個實體在傳輸任何數(shù)據(jù)或信息之前會驗證對方的合法性。這不能與完整性和保密性相混淆。完整性確保交換的信息沒有被篡改。保密性確保信息保持機密性。人們通常認(rèn)為 "加密 "能保證上述這三者，但它們事實上是可以割裂的。日常中，我們每天都在使用TLS來實現(xiàn)保密性、完整性和服務(wù)端認(rèn)證，但通常不依賴于雙向認(rèn)證，即TLS會話能夠確保我們與正確的服務(wù)器通信，但我們隨后依靠密碼或不同形式的認(rèn)證方式來認(rèn)證網(wǎng)絡(luò)服務(wù)。
雙向認(rèn)證通常使用公鑰和私鑰對或單一共享密鑰來實現(xiàn)。這兩種形式都依賴于使用加密的信息進行握手。下面是一個關(guān)于TLS 1.3的握手方式的例子。
在通信兩端的身份通過握手建立后，一個加密的通道被建立起來，在TLS會話期間在這兩個身份之間傳輸數(shù)據(jù)。
如上圖所示，雙向TLS（mTLS）是指在服務(wù)器端和客戶端之間使用雙向加密通道。而今，mTLS是確保云原生應(yīng)用程序中微服務(wù)之間的通信安全的首選協(xié)議，但它不是唯一的方式。IPsec使用IKE（互聯(lián)網(wǎng)密鑰交換）作為握手，對通信兩端的節(jié)點端點進行認(rèn)證，然后在它們之間建立一個加密的數(shù)據(jù)連接。
認(rèn)證：基于會話vs基于網(wǎng)絡(luò)
雙向認(rèn)證的一個關(guān)鍵因素是身份的粒度，即發(fā)放身份和證書的粒度。例如，針對護照這類身份證明文件，可以為每個人發(fā)放單獨的護照，也可以為生活在同一家庭的所有人發(fā)放一本護照，甚至可以用一本護照來識別生活在同一城鎮(zhèn)的所有人。根據(jù)你選擇的識別粒度，可以進行不同級別的認(rèn)證。
當(dāng)前雙向認(rèn)證的兩種典型模式：基于會話與基于網(wǎng)絡(luò)的認(rèn)證。
根據(jù)上述的參照表格，顯然基于會話與基于網(wǎng)絡(luò)的認(rèn)證都具備一系列的優(yōu)勢，理想狀態(tài)下，希望最好能把兩者相互結(jié)合。我們想要更好的身份認(rèn)證粒度的服務(wù)認(rèn)證，包含TLS握手的特性，并能將其與基于網(wǎng)絡(luò)的認(rèn)證方法的透明度、性能和對不同網(wǎng)絡(luò)協(xié)議的廣泛支持等特性結(jié)合起來。
切割認(rèn)證和數(shù)據(jù)傳輸
一旦將認(rèn)證握手與有效載荷傳輸分開，我們可以使用TLS 1.3作為握手協(xié)議，同時依靠IPsec或WireGuard作為性能更好、更透明的有效載荷通道。
我們獲得了兩種模式的好處，包含了許多強大的特性。
連接不再需要被終止。而基于sidecar的方法需要將每個TCP連接轉(zhuǎn)換為3段，以注入TLS。非sidecar方案不需要終止或操作連接。
無需注入sidecar。不需要運行額外的代理程序。代理服務(wù)的認(rèn)證可以由一個節(jié)點來執(zhí)行。在Cilium的解決方案中中，這個代理已經(jīng)存在。其簡化了管理，改善了資源占用，并提高了可擴展性。
支持非TCP和多播。雖然受益于TLS 1.3的強大特性，如低延遲握手，但TLS并沒有限制傳輸能力。支持UDP、ICMP和任何其他可以依托IP傳輸?shù)膮f(xié)議。
支持現(xiàn)有的身份認(rèn)證和證書管理。任何基于mTLS的認(rèn)證控制平面或身份管理系統(tǒng)都能夠兼容，以提供相應(yīng)服務(wù)。其中包括SPIFFE、Vault、SMI、Istio等。
握手緩存和重新認(rèn)證。握手可以一次完成，并進行緩存，而且經(jīng)過認(rèn)證的服務(wù)之間可以進行通信，而不會為已經(jīng)認(rèn)證的服務(wù)帶來額外的延遲，并且可以定期認(rèn)證，以完成對服務(wù)進行重新認(rèn)證。
可選的完整性和保密性。即提供可選的完整性和保密性。
上面的圖顯示了兩種模式的對照情況。左邊是傳統(tǒng)的基于sidecar的mTLS方法，依靠sidecar將TLS注入到每個連接。右邊顯示的是非sidecar的方案，有效載荷連接保持不變，而TLS認(rèn)證由Cilium單獨執(zhí)行，同時在eBPF的幫助下控制有效載荷連接。
Cilium服務(wù)網(wǎng)格雙向認(rèn)證
Cilium內(nèi)置的服務(wù)認(rèn)證服務(wù)和網(wǎng)絡(luò)策略功能，是整合SPIFFE、Vault、SMI、cert-manager或Istio等高級身份和證書管理的理想平臺，其使現(xiàn)有的身份和證書管理層可以用來管理服務(wù)身份并生成證書，然后，這些證書被用來執(zhí)行如Pods或外部工作負(fù)載（如虛擬機、物理機等）的Cilium身份之間的雙向認(rèn)證。
讓我們從配置的角度來看看如何實現(xiàn)的。我們將以SPIFFE與Cilium的為例。其允許在創(chuàng)建網(wǎng)絡(luò)策略時使用SPIFFE身份來選擇工作負(fù)載。
場景一：允許應(yīng)用2 =>應(yīng)用1雙向認(rèn)證的通信
apiVersion: 'cilium.io/v2'kind: CiliumNetworkPolicymetadata:name: 'auth-rule-spiffe-app1'spec:endpointSelector:matchLabels:spiffe://mycluster/app1: ''ingress:fromEndpoints:matchLabels:spiffe://mycluster/app2: ''
如上例所示，網(wǎng)絡(luò)策略通過SPIFFE身份指定允許的endpoints集合。這使得現(xiàn)有基于endpoint選擇器的策略變得非常簡單，并將其固化為使用基于證書的身份認(rèn)證。
額外的安全層
值得注意的是，服務(wù)層面的雙向認(rèn)證并不是簡單地取代網(wǎng)絡(luò)層的網(wǎng)絡(luò)策略。它是增加了一個額外的安全層。Cilium仍然像今天一樣識別單個endpoint，網(wǎng)絡(luò)分段仍然適用于這些單個endpoint。如果一個網(wǎng)絡(luò)策略同時指定了SPIFFE身份和端點選擇器，那么惡意的工作負(fù)載就無法通過被破壞的服務(wù)級證書來冒充該服務(wù)。
對于pod或服務(wù)的所有outbound流量，其目的地必須是pod的出口策略所允許的。假設(shè)一個特定的pod竊取了另一個pod身份的證書，這個惡意的pod不能簡單地用另一個pod來驗證自己，即使證書允許這樣做。因為出口策略阻止這種惡意訪問。
假設(shè)出口策略層通過，但目的地還是會被驗證。除了驗證目的地的證書也被竊取，當(dāng)然，這個步驟還可以進行額外的驗證，因為Cilium處于一個特殊的位置，可以代表服務(wù)進行驗證。驗證目的地的證書是否屬于一個實際目的地節(jié)點上運行的工作負(fù)載？這可以防止身份盜竊，要求攻擊者不僅要竊取服務(wù)證書和網(wǎng)絡(luò)身份，還要求攻擊者在應(yīng)該運行服務(wù)的節(jié)點上運行冒充的工作負(fù)載。
與第2步相同，但對于接收者來說，要驗證發(fā)送者的身份。同樣，驗證發(fā)送者使用的證書是來自一個應(yīng)該運行這個工作負(fù)載的節(jié)點。
最后，入口策略必須允許該流量。如果代表服務(wù)的證書被破壞了，攻擊者也必須能夠冒充一個允許的網(wǎng)絡(luò)身份。
性能測試
所有這些額外的安全對于性能有何影響？下面是在GKE上運行的Cilium與nighthawk基于不同型號的HTTP基準(zhǔn)測試中的測量結(jié)果。
沒有額外的雙向認(rèn)證（基線）
啟用WireGuard以保證完整性和保密性
由Istio提供的Sidecar mTLS模型
注意：下面的基準(zhǔn)已經(jīng)更新，還包括了Istio在禁用協(xié)議嗅探特效以使Istio進入純TCP模式。通過在Service中設(shè)置name: tcp可以達(dá)到同樣的效果。
上圖顯示了沒有任何HTTP處理的基線、配置了HTTP filter的Cilium和默認(rèn)配置（協(xié)議嗅探）的Istio的P95延遲測量值，Istio會在檢測到時自動執(zhí)行HTTP解析。
這些測試數(shù)據(jù)與Istio文檔中的延時基準(zhǔn)測試基本一致。
這第二次測量限制了對TCP的參與，并禁用了所有的HTTP處理。Cilium中的HTTP過濾器被移除。對于Istio來說，因為默認(rèn)啟用的協(xié)議嗅探可能會導(dǎo)致HTTP處理，即使沒有聲明要解析HTTP的意圖，因此，協(xié)議嗅探在本次測試中被禁用。
對于所有的測量，Istio已經(jīng)通過移除默認(rèn)的并發(fā)量限制以及移除默認(rèn)的TCP過濾器來進行調(diào)整。重現(xiàn)性能基準(zhǔn)的腳本可以在這個代碼庫中找到。
總結(jié)
由于Cilium服務(wù)網(wǎng)格的1.12版本已經(jīng)是穩(wěn)定版，這種雙向認(rèn)證方案是Cilium服務(wù)網(wǎng)格的下一個關(guān)注點。我們相信，不僅可以與現(xiàn)有的身份管理解決方案（如SPIFFE、cert-manager甚至Istio作為控制平面）進行很好的整合，還可以提供一個更優(yōu)雅、更高性能、更安全的認(rèn)證實現(xiàn)，并結(jié)合強大的數(shù)據(jù)路徑屬性。與NetworkPolicy的緊密結(jié)合提供了一個簡單易用但高度安全的通信模式，可以防止網(wǎng)絡(luò)冒充和服務(wù)身份竊取。鑒于我們已經(jīng)實現(xiàn)了所有的前提條件，預(yù)計這種雙向認(rèn)證功能將在1.13中實現(xiàn)。
由于筆者時間、視野、認(rèn)知有限，譯文難免出現(xiàn)錯誤、疏漏等問題，期待各位指正交流。
相關(guān)圖書
▊《云原生服務(wù)網(wǎng)格Istio：原理、實踐、架構(gòu)與源碼解析》
張超盟 等 編著
華為云出品，CNCF、信通院力薦
原理、實踐、架構(gòu)、源碼，4大層面多角度全解Istio
這是一本關(guān)于云原生服務(wù)網(wǎng)格Istio的前所未有詳盡的書籍。本書分為原理篇、實踐篇、架構(gòu)篇和源碼篇，由淺入深地將Istio項目庖丁解牛并呈現(xiàn)給讀者。無論是對于剛?cè)腴TIstio的讀者，還是對于已經(jīng)在產(chǎn)品中使用Istio的讀者，本書都極具參考價值。
（下單立減50，快快掃碼搶購吧！）
?
如果喜歡本文 歡迎?在看丨留言丨分享至朋友圈?三連 ?熱文推薦??
▼點擊閱讀原文，了解本書詳情~