介紹
Grab 的實時資料平臺團隊，也稱為 Coban，一直在為所有 Grab 垂直領域運營大型 Kafka 叢集，重點關注確保一流的效能和 99。99% 的可用性。
安全一直是 Grab 的首要任務之一，隨著欺詐者的不斷髮展，越來越需要繼續加強我們的資料流平臺的安全性。其中一種方法是從純粹的基於網路的訪問控制轉變為預設情況下最先進的安全和零信任，例如：
身份驗證
：在任何進一步的通訊之前，首先建立和確定任何遠端系統（客戶端和伺服器）的身份。
授權
：基於最小許可權原則授予對Kafka的訪問許可權；預設情況下不提供訪問許可權。Kafka 客戶端與列入白名單的 Kafka 主題和許可權相關聯 - 消費或生產 - 他們嚴格需要。此外，授予的訪問許可權是可審計的。
機密性
：所有傳輸中的流量都經過加密。
解決方案
我們決定使用相互傳輸層安全 （mTLS） 進行身份驗證和加密。mTLS 使客戶端能夠對伺服器進行身份驗證，而伺服器則能夠相互對客戶端進行身份驗證。
Kafka 支援其他身份驗證機制，如 OAuth，或 Salted Challenge Response Authentication Mechanism （SCRAM），但我們選擇 mTLS，因為它能夠離線驗證對等方的身份。這種驗證能力意味著系統不需要主動連線到驗證伺服器來確定對等方的身份。這使得能夠在不同的網路環境中執行，其中所有各方不一定都可以訪問這樣的中央機構。
我們選擇了Hashicorp Vault 及其PKI 引擎 來動態生成客戶端和伺服器的證書。這使我們能夠為客戶端強制使用短期證書，這是一種減輕客戶端證書被洩露或惡意共享的潛在影響的方法。我們說零信任，對吧？
對於授權，我們選擇了基於策略的訪問控制 （PBAC），這是一種比基於角色的訪問控制 （RBAC） 更具可擴充套件性的解決方案，並選擇了開放策略代理 （OPA） 作為我們的策略引擎，以獲得廣泛的社群支援。
為了將 mTLS 和 OPA 與 Kafka 整合，我們利用了Strimzi，Kafka on Kubernetes 運營商。在之前的文章中，我們提到了 Strimzi 並暗示了它如何幫助實現可擴充套件性和雲不可知論。內建安全性無疑是我們採用 Strimzi 的另一個驅動力。
伺服器認證
圖 1 - 內部叢集通訊的伺服器身份驗證過程
我們首先為每個環境（暫存、生產等）設定一個根證書頒發機構 （CA）。這個 Root CA，在圖中以藍色顯示，由 Hashicorp Vault 叢集安全管理。請注意，圖中證書、金鑰、簽名箭頭和簽名的顏色在整篇文章中都是一致的。
為了保護叢集的內部通訊，例如 Kafka 代理和 Zookeeper pod 之間的通訊，Strimzi 設定了一個由根 CA 簽名的叢集 CA（步驟 1）。然後，叢集 CA 用於簽署各個 Kafka 代理和 zookeeper 證書（第 2 步）。最後，將 Root CA 的公共證書匯入到 Kafka 代理和 Zookeeper 的信任庫中（第 3 步），以便所有 Pod 在彼此進行身份驗證時可以相互驗證其證書。
Strimzi 的嵌入式 Cluster CA 在啟動新的 Kafka 和 Zookeeper pod 時動態生成有效的個人證書。簽名操作（第 2 步）由 Strimzi 自動處理。
對於 Kafka 代理的客戶端訪問，Strimzi 建立了一組不同的中間 CA 和伺服器證書，如下圖所示。
圖 2 - 客戶端訪問 Kafka 代理的伺服器身份驗證過程
圖 1 中的同一個根 CA 現在簽署了一個不同的中間 CA，Strimzi 社群稱之為客戶端 CA（步驟 1）。此命名具有誤導性，因為它實際上並未簽署任何客戶端證書，而僅簽署了在 Kafka 代理的外部偵聽器上設定的伺服器證書（第 2 步）。這些伺服器證書供 Kafka 客戶端對伺服器進行身份驗證。這一次，根 CA 的公共證書將匯入到 Kafka 客戶端信任庫（第 3 步）。
客戶端認證
圖 3 - 客戶端身份驗證過程
對於客戶端身份驗證，Kafka 客戶端首先需要向 Hashicorp Vault 進行身份驗證，並從 Vault PKI 引擎請求臨時證書（步驟 1）。然後，Vault 頒發證書並使用其根 CA 對其進行簽名（第 2 步）。使用此證書，客戶端現在可以向 Kafka 代理進行身份驗證，Kafka 代理將使用其信任庫中已有的根 CA 公共證書，如前所述（步驟 3）。
CA樹
將我們剛剛介紹的三種不同的身份驗證過程放在一起，CA 樹現在看起來像這樣。請注意，這是單個環境、單個叢集和僅兩個客戶端的簡化檢視。
圖 4 - 完整的證書頒發機構樹
如前所述，每個環境（暫存、生產等）都有自己的根 CA。在一個環境中，每個 Strimzi 叢集都有自己的一對中間 CA：叢集 CA 和客戶端 CA。在葉級，Zookeeper 和 Kafka broker pod 都有自己的證書。
在圖的右側，每個 Kafka 客戶端在需要連線到 Kafka 時都可以從 Hashicorp Vault 獲得臨時證書。每個團隊或應用程式在 Hashicorp Vault 中都有一個專用的 Vault PKI 角色，限制可以為其證書請求的內容（例如，主題、TTL 等）。
Strimzi部署
我們大量使用 Terraform 來管理和配置我們的 Kafka 和 Kafka 相關元件。這使我們能夠快速可靠地啟動新叢集並執行叢集擴充套件操作。
在底層，Strimzi Kafka 部署是一個 Kubernetes 部署。為了提高 Kafka 叢集的效能和可靠性，我們使用Kubernetes 汙點和容忍度為每個 Strimzi Kafka 代理和每個 Zookeeper pod 建立了專用的 Kubernetes 節點。這確保單個節點的所有資源都專用於單個 Kafka 代理或單個 Zookeeper pod。
我們還決定透過 Kubernetes 叢集使用單個 Kafka 叢集，以簡化管理。
客戶端設定
Coban 為來自所有 Grab 垂直領域的後端微服務團隊提供了流行的 Golang 中的 Kafka SDK，以標準化團隊如何使用 Coban Kafka 叢集。新增 mTLS 支援主要歸結為升級我們的 SDK。
我們增強的 SDK 提供預設的 mTLS 配置，對大多數團隊來說開箱即用，同時仍然允許定製，例如，出於合規性原因，對於擁有自己的 Hashicorp Vault 基礎設施的團隊。同樣，客戶可以選擇各種 Vault 身份驗證方法（例如AWS 或Kubernetes） 來向 Hashicorp Vault 進行身份驗證，甚至可以實現自己的邏輯來獲取有效的客戶端證書。
為了減輕使用者與其他應用程式或使用者惡意共享其應用程式證書的潛在風險，我們限制了任何給定證書的最大生存時間 （TTL）。這也消除了維護證書撤銷列表 （CRL） 的開銷。此外，我們的 SDK 僅將證書及其關聯的私鑰儲存在記憶體中，從不儲存在磁碟中，因此減少了攻擊面。
在我們的例子中，Hashicorp Vault 是一個依賴項。為了防止它降低我們資料流平臺的整體可用性，我們在 SDK 中添加了兩個功能 - 可配置的重試機制和在達到 TTL 的三分之二時自動更新客戶端的短期證書。升級後的 SDK 還圍繞此證書更新過程生成新指標，從而實現更好的監控和警報。
授權
圖 5 - 客戶端可以訪問 Kafka 記錄之前的授權過程
對於授權，我們將 Open Policy Agent （OPA） 設定為 Kubernetes 叢集中的獨立部署，並配置 Strimzi 以將 Kafka 代理與該 OPA 整合。
OPA 策略 - 用Rego 語言編寫 - 描述授權邏輯。它們與授權規則一起在 GitLab 儲存庫中建立，稱為資料來源（步驟 1）。每當發生變化時，GitLab CI 管道會自動建立一組策略和資料來源，並將其推送到 S3 儲存桶（第 2 步）。從那裡，它由 OPA 獲取（第 3 步）。
當客戶端（由其 TLS 證書的主題標識）嘗試使用或生成 Kafka 記錄（第 4 步）時，Kafka broker pod 在處理客戶端請求之前首先向 OPA 發出授權請求（第 5 步）。然後，授權請求的結果由 Kafka broker pod 快取以提高效能。
作為授權過程的核心元件，OPA 的部署具有與 Kafka 叢集本身相同的高可用性，即分佈在相同數量的可用區中。此外，我們決定透過 Kafka 叢集使用一個專用的 OPA，而不是在多個叢集之間共享一個唯一的全域性 OPA。這是為了減少任何 OPA 事件的爆炸半徑。
為了圍繞授權進行監控和警報，我們 在專案中提交了開源貢獻
opa-kafka-plugin
最後，作為平臺團隊，我們需要使授權成為可擴充套件的自助服務流程。因此，我們依靠 Git 儲存庫的許可權讓 Kafka 主題的所有者批准與其主題相關的資料來源更改。
需要其應用程式訪問 Kafka 主題的團隊將編寫並提交一個 JSON 資料來源，就像這樣簡單：
{ “example_topic”： { “read”： ［ “clientA。grab”， “clientB。grab” ］， “write”： ［ “clientB。grab” ］ }}
在 Git 倉庫中設定 GitLab CI 單元測試和業務邏輯檢查，以確保提交的更改有效。之後，更改將提交給主題的所有者進行審查和批准。
下一步是什麼？
此外，在授權方面，我們當前的 PBAC 設計是相當靜態的，每個主題都有一個授予訪問許可權的應用程式列表。將來，我們計劃轉向基於屬性的訪問控制 （ABAC），根據團隊和主題的元資料建立動態策略。例如，預設情況下，團隊可以被授予對他們自己的所有主題的讀寫許可權。利用 OPA 等多功能元件作為我們的授權控制器可以實現這種發展。
作者：Fabrice Harbulot · Thanh Tung Dao · Quang Minh Tran
出處：https：//engineering。grab。com/zero-trust-with-kafka
