本文已超過一年。較舊的文章可能包含過時的內容。請檢查頁面中的資訊自發布以來是否已變得不正確。
從網路政策到安全政策
Kubernetes 網路原則
Kubernetes 支援新的網路原則 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 封包期間驗證的 nonce，並且可以防禦中間人或重播攻擊。
Trireme 實作直接與 Kubernetes 控制平面通訊，無需外部控制器，並接收關於原則更新和 pod 實例化的通知，以便它可以維護原則的本機快取並在需要時更新授權規則。Trireme 组件之间不需要任何共享状态进行同步。Trireme 可以部署为每个工作节点的独立进程，也可以使用 Daemon Sets。在後一種情況下，Kubernetes 負責 Trireme pod 的生命週期。
Trireme 的簡潔性源自於將安全性原則與網路傳輸分離。原則強制執行直接連結到連線上存在的標籤，而與用於使 pod 通訊的網路方案無關。這種身分連結使營運商能夠極其靈活地使用他們喜歡的任何網路方案，而無需將安全性原則強制執行與網路實作細節聯繫起來。此外，跨聯合叢集實作安全性原則變得簡單且可行。
Kubernetes 和 Trireme 部署
Kubernetes 在其擴展能力以及為容器和微服務部署提供可擴展的安全性支援方面是獨一無二的。Trireme 為強制執行這些原則提供了一種簡單、安全且可擴展的機制。
您可以透過使用提供的 Daemon Set 在 Kubernetes 之上部署和試用 Trireme。您需要根據您的叢集架構修改一些 YAML 參數。所有步驟都在部署 GitHub 資料夾中詳細描述。同一個資料夾包含一個範例三層原則，您可以使用它來測試流量模式。
若要了解更多資訊、下載程式碼並參與專案，請造訪