Kubernetes零信任架構

導讀	鑑於Kubernetes的分散式和擴充套件性，IT必須盡一切可能確保訪問安全，以避免正在發生的錯誤。

現代IT環境日益動態化。例如Kubernetes正在突破許多IT組織的可能性。開源技術在自動化容器化應用程式的部署、可擴充套件性和管理方面的很多好處。特別是，IT 團隊正在利用其強大的功能、效率和靈活性來快速開發現代應用程式並完成大規模交付。

但是在Kubernetes環境中強化安全實踐的過程是一個日益嚴峻的挑戰。隨著越來越多的開發和生產Kubernetes叢集分佈在本地資料中心、多個公共雲提供商和邊緣位置，這種相對較新的動態操作模型為訪問控制帶來了極大的複雜性。

由於大多數團隊都有在多個區域執行的多個叢集的場景——通常具有不同的分佈和管理介面——企業 IT 需要考慮到需要不同級別訪問許可權的開發人員、運營人員、承包商和合作夥伴團隊。

鑑於Kubernetes的分散式和擴充套件性，IT必須盡一切可能確保訪問安全，以避免正在發生的錯誤。下面，我們將看看如何應用Kubernetes零信任原則來保護整個環境，如何為容器提供零信任安全性。

假設在網路中和網路之間訪問的所有人員、系統和服務都是不可信的安全模型，零信任正在成為防止惡意攻擊的最佳技術。基於身份驗證、授權和加密技術，零信任的目的是不斷驗證安全配置和狀態，以確保跨環境的可信。

以下是對 Kubernetes 工作原理的基本瞭解：

1. 1、每個叢集的 Kubernetes 控制平面的核心是 Kubernetes API Server。

1. 2、API Server 用於查詢和操作所有 Kubernetes 物件的狀態。

1. 3、Kubernetes 資源物件包括名稱空間、pod、配置對映等。

控制對API Server的訪問是管理Kubernetes訪問和實現零信任的關鍵功能。保護對Kubernetes叢集的訪問的第一步是使用傳輸層安全性 (TLS) 保護進出API Servre的流量。

實現零信任的 API 伺服器最佳實踐：

1. 1、隨處啟用 TLS。

1. 2、使用 API Server 的專用端點。

1. 3、對 API Server 使用第三方身份驗證。

1. 4、關閉 API Server 的防火牆入站規則，確保它被隱藏並且不能從 Internet 直接訪問。

在保護傳輸層之後，Kubernetes 還包括必要的鉤子來實現零信任和控制每個 Kubernetes 叢集的 API Server 訪問。這些鉤子代表了 Kubernetes 強化安全態勢的四個關鍵領域：

1. 1、驗證

1. 2、授權

1. 3、准入控制

1. 4、記錄和審計

在零信任的情況下，所有與 Kubernetes 叢集相關的使用者級和麵向服務的帳戶都必須在執行 API 呼叫之前進行身份驗證。Kubernetes 可以廣泛使用安全模組和外掛，以確保該平臺能夠透過團隊首選的身份驗證系統有效執行：

1. 1、HTTP 基本身份驗證

1. 2、身份驗證代理（支援 LDAP、SAML、Kerberos 等）

1. 3、客戶證照

1. 4、不記名令牌

1. 5、OpenID Connect 令牌

1. 6、Webhook 令牌授權

身份驗證的常見最佳實踐包括啟用至少兩種身份驗證方法（多因素身份驗證或 MFA）和定期輪換客戶端證照。

必須允許每個具有身份驗證訪問許可權的使用者或服務帳戶在 Kubernetes 叢集中執行任何可能的操作。零信任的想法是，只有經過身份驗證的使用者具有完成所請求操作的必要許可權，才能授權請求。對於發出的每個請求，此模型將需要指定 Kubernetes 叢集中的使用者名稱、操作和受影響的物件。

Kubernetes 支援多種授權方法，包括：

1. 基於屬性的訪問控制 (ABAC) 根據使用者、環境和資源屬性的組合動態地授權訪問。

1. 基於角色的訪問控制或 RBAC，根據使用者在組織中的角色（例如開發人員、管理員、安全人員等）授權訪問。

組織最常使用 RBAC，因為它的實用性允許更輕鬆的管理控制並提供大多數用例所需的粒度。在行業內，以最低許可權啟用 RBAC 是很常見的。

ABAC 可以提供額外的粒度，但需要額外的時間和資源來正確定義和配置。但是，使用 ABAC 方法解決問題可能更具挑戰性。因此，通常以最低許可權啟用 RBAC。

准入控制器提供了一種實現業務邏輯的方法，以改進 Kubernetes 的零信任方法。准入控制器的目的是使系統能夠自動處理建立、修改、刪除或連線到 Kubernetes 物件的請求。可能需要啟用多個准入控制器以滿足您組織的需求，如果其中任何一個拒絕特定請求，系統也會自動拒絕它。

當今可用的各種內建准入控制器為團隊提供了許多用於執行策略和實施各種操作的選項。動態控制器可以快速修改請求以遵守已建立的規則集。例如，ResourceQuota 准入控制器觀察傳入的請求並確保它們不違反已在名稱空間的 ResourceQuota 物件中列出的約束。

審計功能提供了叢集內執行的操作的跟蹤記錄，這對於 Kubernetes 安全態勢至關重要。這些功能可以跟蹤任何使用者、應用程式和控制平面本身的任何操作。

有四種不同型別的審計級別：

1. 1、無 – 不記錄此事件

1. 2、後設資料 – 記錄請求後設資料

1. 3、請求 - 記錄事件後設資料和請求

1. 4、RequestResponse – 記錄事件後設資料、請求和響應

除了指定審計級別之外，團隊還可以控制記錄審計事件的位置。當日志後端將事件寫入叢集的本地檔案系統時，webhook 後端會將審計事件傳送到外部日誌系統。

雖然上述不同的方法和實踐提供了建立零信任環境的能力，但當 Kubernetes 的足跡擴充套件到幾個叢集之外時，正確配置和對齊這些單獨的元素成為一個更重大的挑戰。當涉及多個工作負載和 Kubernetes 分佈時，事情會變得特別複雜。這一挑戰並不新鮮，但如今已為許多公司所共有。

例如，讓我們考慮一個場景，一家公司管理著 100 個 Kubernetes 叢集——從開發到 QA 到預生產再到生產——並且這些叢集需要在地理位置上靠近其全球客戶群，以便應用程式能夠處理實時影片和音訊資料。

在確保使用者安全訪問 Kubernetes 叢集方面，該公司可能會遇到三個問題：

1. 假設這家公司有幾百名開發人員和幾十名 IT 運維人員，手動在每個叢集中新增和刪除使用者的艱鉅任務會產生比解決的問題更多的問題。

1. 如果發生緊急事件，補救所需的時間至關重要。如果訪問方法讓那些對問題進行故障排除的人只需要幾分鐘才能登入到受影響的叢集，那麼問題可能會成倍增加。

1. 由於日誌資料分佈在 100 個叢集中，因此可能無法全面瞭解審計和合規性報告。

企業平臺團隊的眾多目標之一是幫助全球分佈的 IT 團隊從一箇中心位置管理其所有叢集中的使用者訪問。其目的是有效地保護和管理對 Kubernetes 基礎設施的訪問，同時使審計日誌記錄和合規性報告更加簡單。

平臺團隊應考慮為 Kubernetes 實施零信任，以確保應用和實施前面描述的最佳實踐來保護整個 Kubernetes 環境。透過消除在每個叢集上手動應用最佳實踐的需要，IT 組織可以以更低的風險大規模執行 Kubernetes。

在為 Kubernetes 設計零信任時，平臺團隊需要考慮以下三個好處：

1. 1、使RBAC超靈活：如果團隊成員更改角色，訪問許可權應自動更新，這樣任何人都不會擁有過多或過少的訪問許可權。

1. 2、快速和簡化可訪問性：透過安全的單點登入為授權使用者提供無縫訪問，從而消除對任何叢集的延遲訪問。

1. 3、即時場景的憑據：授權使用者的服務帳戶應在具有“即時”訪問許可權的遠端叢集上建立，並在使用者登出後自動刪除，從而消除憑據過期的機會。

一兩個叢集時並不會存在明顯的安全風險，但隨著 Kubernetes 叢集和容器化應用程式數量的增加。因此，平臺團隊需要在其整個 Kubernetes 基礎架構中為叢集和應用程式啟用集中的企業級安全和控制。

原文來自：