現代 IT 環境日益動態化。例如，Kubernetes 正在突破許多 IT 組織的可能性。

開源技術在自動化容器化應用程序的部署、可擴展性和管理方面的很多好處。特別是，IT 團隊正在利用其強大的功能、效率和靈活性來快速開發現代應用程序并完成大規模交付。

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

由于大多數團隊都有在多個區域運行的多個集群的場景——通常具有不同的分布和管理界面——企業 IT 需要考慮到需要不同級別訪問權限的開發人員、運營人員、承包商和合作伙伴團隊。

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

Kubernetes 集群的零信任訪問

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

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

• 每個集群的 Kubernetes 控制平面的核心是 Kubernetes API Server。
• API Server 用于查詢和操作所有 Kubernetes 對象的狀態。
• Kubernetes 資源對象包括命名空間、pod、配置映射等。

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

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

• 隨處啟用 TLS。
• 使用 API Server 的專用端點。
• 對 API Server 使用第三方身份驗證。
• 關閉 API Server 的防火墻入站規則，確保它被隱藏并且不能從 Internet 直接訪問。

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

• 驗證
• 授權
• 準入控制
• 記錄和審計

Kubernetes 身份驗證

在零信任的情況下，所有與 Kubernetes 集群相關的用戶級和面向服務的帳戶都必須在執行 API 調用之前進行身份驗證。Kubernetes 可以廣泛使用安全模塊和插件，以確保該平臺能夠通過團隊首選的身份驗證系統有效運行：

• HTTP 基本身份驗證
• 身份驗證代理（支持 LDAP、SAML、Kerberos 等）
• 客戶證書
• 不記名令牌
• OpenID Connect 令牌
• Webhook 令牌授權

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

對 Kubernetes 的授權

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

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

• 基于屬性的訪問控制 (ABAC) 根據用戶、環境和資源屬性的組合動態地授權訪問。
• 基于角色的訪問控制或 RBAC，根據用戶在組織中的角色（例如開發人員、管理員、安全人員等）授權訪問。

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

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

Kubernetes 準入控制

準入控制器提供了一種實現業務邏輯的方法，以改進 Kubernetes 的零信任方法。準入控制器的目的是使系統能夠自動處理創建、修改、刪除或連接到 Kubernetes 對象的請求?？赡苄枰獑⒂枚鄠€準入控制器以滿足您組織的需求，如果其中任何一個拒絕特定請求，系統也會自動拒絕它。

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

Kubernetes 的日志記錄和審計

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

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

• 無 – 不記錄此事件
• 元數據 – 記錄請求元數據
• 請求 - 記錄事件元數據和請求
• RequestResponse – 記錄事件元數據、請求和響應

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

擴展零信任架構

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

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

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

• 假設這家公司有幾百名開發人員和幾十名 IT 運維人員，手動在每個集群中添加和刪除用戶的艱巨任務會產生比解決的問題更多的問題。
• 如果發生緊急事件，補救所需的時間至關重要。如果訪問方法讓那些對問題進行故障排除的人只需要幾分鐘才能登錄到受影響的集群，那么問題可能會成倍增加。
• 由于日志數據分布在 100 個集群中，因此可能無法全面了解審計和合規性報告。

平臺團隊的注意事項

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

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

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

• 使 RBAC 超靈活：如果團隊成員更改角色，訪問權限應自動更新，這樣任何人都不會擁有過多或過少的訪問權限。
• 快速和簡化可訪問性：通過安全的單點登錄為授權用戶提供無縫訪問，從而消除對任何集群的延遲訪問。
• 即時場景的憑據：授權用戶的服務帳戶應在具有“即時”訪問權限的遠程集群上創建，并在用戶注銷后自動刪除，從而消除憑據過期的機會。

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