Categories
程式開發

如何通過Kubernetes網絡策略隔離1500個微服務


Monzo安全團隊撰文分享了他們實現Kubernetes網絡策略的經歷,該策略通過Calico的API為1500個微服務提供了隔離。

Monzo是一家面向移動端的數字銀行,它們在AWS上運行其核心基礎設施。除了使用Kubernetes託管其微服務外,Monzo還使用Apache Cassandra作為主要數據庫,使用Apache Kafka進行消息傳遞,並使用Go實現了其大部分程序代碼。 Monzo安全團隊將採用零信任網絡作為他們的目標之一。零信任平台的原則是,網絡內外的任何一個實體都是不被信任的,要訪問私有信息必須要經過驗證。 Monzo後端的每個服務只允許訪問一個經過預先批准的服務列表。 Monzo大約擁有1500個服務,超過9300個服務間的交互,這也讓該任務變得非常困難。在構建了一個通過分析代碼來派生策略的自定義工具集之後,Monzo團隊在Kubernetes上使用了針對Calico的網絡策略來提供隔離。

團隊首先通過隔離一個服務來測試他們的初步方案。他們編寫了一個名為rpcmap的自定義工具,這個工具可以通過分析靜態代碼來發現服務之間的依賴關係。根據Monzo後端工程師Jack Kleeman的說法,他們在集成測試或運行時選擇靜態分析的方式而不是觀察的方式,主要是因為:

Monzo有很多代碼路徑,沒有一個可以涵蓋所有內容的集成測試。在運行時,某項服務很少被調用並不意味著它從不會被調用;一間銀行可以有一些每年只運行一次的服務進程。

規則必須按照可管理和可讀的方式存儲,而且不能破壞現有的服務。 Monzo安全團隊採用了Kubernetes的NetworkPolicy來執行規則探測,並使用Calico網絡插件來實現網絡策略。這種初始方法在可測試性方面非常脆弱,並把維護規則列表的責任交由管理調用服務的團隊負責。另一個引入的缺點就是開發團隊必須手動編輯Kubernetes的配置文件。

為解決這些問題,Kleeman說:“跟Calico社區討論了網絡策略的測試問題後,我們發現可以使用Calico的一些無法被Kubernetes訪問的特性來測試我們的策略。”其中的一個特性允許流量訪問網絡策略通常不允許的內容,隨後記錄下來這種情況。 Kubernetes網絡策略通常採用選擇器和標籤的方式,在沒有採用任何策略的時候,Kubernetes允許pod之間的所有通信。 Monzo將他們的策略配置在最後運行,並監控網絡流量來確定哪些服務會丟失數據包。

此後,團隊將服務允許的流量列表切換為調用服務的一個屬性,而不是目標服務的屬性。服務通過標籤聲明它們在策略的入口(ingress)規範中需要訪問到的服務。針對那些調用大量其他服務的服務,例如監控服務,則會按照“服務類型”進行分組,按照這樣的準則,就沒有必要列出每個服務了。 rpcmap被配置為每次提交時運行,部署管道把規則文件轉換為服務標籤。團隊計劃在未來使用服務網格而不是CNI(容器網絡接口)層來實現這一點,他們已經遷移到了一個使用Envy的自定義網格。

原文鏈接:

How Monzo Isolated Their Microservices Using Kubernetes Network Policies