本文發表於一年多前。舊文章可能包含過時內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
從網路策略到安全策略
Kubernetes 網路策略
Kubernetes 支援一種新的網路策略 API，該 API 提供了一個複雜的模型來隔離應用程式並減少其攻擊面。此功能由 SIG-Network 小組開發，透過使用 Kubernetes 構建的內建標籤和選擇器，可以非常輕鬆優雅地定義網路策略。
Kubernetes 將這些網路策略的實現留給了第三方，並且沒有提供預設實現。
我們希望引入一種思考“安全”和“網路策略”的新方式。我們希望表明安全性和可達性是兩個不同的問題，並且使用端點（例如 Pod 標籤）定義的安全策略不一定需要使用網路原語來實現。
我們 Aporeto 的大多數人都擁有網路/SDN 背景，我們知道如何使用傳統的網路和防火牆來實現這些策略：將 Pod 身份和策略定義轉換為網路限制，例如 IP 地址、子網等。
然而，我們也從過去的經驗中瞭解到，使用外部控制平面也會帶來一系列全新的挑戰：ACL 的分發需要 Kubernetes 工作節點之間非常緊密的同步；每次例項化新的 Pod 時，都需要更新所有其他與新 Pod 有關的策略的 Pod 上的 ACL。非常緊密的同步從根本上來說是一個二次狀態問題，雖然共享狀態機制可以在較小規模下工作，但在大規模叢集中通常存在收斂、安全和最終一致性問題。
從網路策略到安全策略
在 Aporeto，我們透過將網路與策略解耦，對網路策略執行採取了不同的方法。我們將我們的解決方案 Trireme 開源，它將網路策略轉換為授權策略，併為 Pod 之間的任何通訊實現透明的身份驗證和授權功能。它不是使用 IP 地址來識別 Pod，而是為每個 Pod 定義一個經過加密簽名的身份，即其關聯標籤的集合。它不是使用 ACL 或資料包過濾器來執行策略，而是使用授權功能，其中容器只能從身份與策略要求匹配的容器接收流量。
Trireme 中的身份驗證和授權功能覆蓋在 TCP 協商序列上。身份（即標籤集）被捕獲為 JSON Web Token (JWT)，由本地金鑰簽名，並在 Syn/SynAck 協商期間交換。接收工作節點驗證 JWT 是否由受信任的機構簽名（身份驗證步驟），並根據策略的快取副本驗證連線是否可以接受。一旦連線被接受，其餘流量將透過 Linux 核心流動，並受到它可能提供的所有保護（如果需要，包括 conntrack 功能）。當前的實現使用一個簡單的使用者空間程序，該程序捕獲初始協商資料包並將授權資訊作為有效負載附加。JWT 包含在 Ack 資料包期間驗證的隨機數，可以防禦中間人或重放攻擊。
Trireme 實現直接與 Kubernetes 主節點通訊，無需外部控制器，並接收策略更新和 Pod 例項化通知，以便它可以維護策略的本地快取並根據需要更新授權規則。Trireme 元件之間不需要任何需要同步的共享狀態。Trireme 可以作為獨立程序部署在每個工作節點中，也可以使用 Daemon Sets 部署。在後一種情況下，Kubernetes 負責 Trireme Pod 的生命週期。
Trireme 的簡潔性源於將安全策略與網路傳輸分離。策略執行直接與連線上存在的標籤相關聯，而與用於 Pod 通訊的網路方案無關。這種身份連結為操作員提供了巨大的靈活性，可以使用他們喜歡的任何網路方案，而無需將安全策略執行與網路實現細節繫結。此外，在聯合叢集中實施安全策略變得簡單可行。
Kubernetes 和 Trireme 部署
Kubernetes 在其擴充套件能力和為容器和微服務部署提供可擴充套件安全支援方面是獨一無二的。Trireme 提供了一種簡單、安全且可擴充套件的機制來執行這些策略。
您可以使用提供的 Daemon Set 在 Kubernetes 之上部署和試用 Trireme。您需要根據叢集架構修改一些 YAML 引數。所有步驟都在 部署 GitHub 資料夾 中詳細描述。同一資料夾包含一個 3 層策略示例，您可以使用它來測試流量模式。
要了解更多資訊、下載程式碼並參與專案，請訪問