現代 IT 環境變得越來越動態。舉例來說，Kubernetes 拓展了許多組織的可能性邊界。開源技術在容器化應用程序自動部署、擴展性和管理方面有諸多好處。特別地，IT 團隊可以利用其強大的功能、有效性和靈活性快速開發現代應用程序并大規模交付。

然而，為 Kubernetes 環境安全強化實踐提供保障的流程面臨著越來越大的挑戰。隨著分布在本地數據中心、多公有云提供商和邊緣位置的 Kubernetes 開發和生產集群數量越來越多，這種相對較新的動態操作模型給訪問控制帶來了很大的復雜性。

由于大部分團隊都有多個集群在多個位置運行——通常使用不同的發行版，有不同的管理界面——企業 IT 部門需要考慮到，開發、運營、承包商和合作伙伴團隊需要不同級別的訪問權限。

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

Kubernetes 集群零信任訪問

零信任是一個安全模型，它會自動假設所有在網絡中或網絡間進行操作的人、系統和服務都是不可信任的。零信任正成為預防惡意攻擊的最佳技術。以身份驗證、授權和加密技術為基礎，零信任的目的是持續驗證安全配置和態勢，確保整個環境值得信任。

以下是對 Kubernetes 基本工作原理的一個簡單說明：

• 對于每個集群，Kubernetes 控制平面的核心是 Kubernetes API 服務器。
• 可以調用 API 來查詢和操作所有 Kubernetes 對象的狀態。
• Kubernetes 對象包括命名空間、pod、配置信息等。API 訪問控制是管理 Kubernetes 訪問、實現零信任的關鍵功能。保障 Kubernetes 集群訪問安全的第一步是通過傳輸層安全（TLS）來保護流入 / 流出 API 服務器的流量。

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

• 啟用所有地方的 TLS。
• 使用 API 服務器的私有端點。
• API 服務器使用第三方身份驗證。
• 關閉 API 服務器的防火墻入站規則，確保它是隱形的，不能直接從 Internet 訪問。在確保傳輸層安全后，Kubernetes 還要包含必要的鉤子，用于實現零信任，并控制對每個 Kubernetes 集群的 API 服務器的訪問。這些鉤子代表了 Kubernetes 堅固安全態勢的 4 個關鍵領域：
• 身份驗證
• 授權
• 準入控制
• 日志和審計

Kubernetes 身份驗證

在零信任原則下，所有與 Kubernetes 集群關聯的用戶賬號和服務賬號在執行 API 調用之前都要進行身份驗證。有許多安全模塊和插件可以保證 Kubernetes 平臺在團隊首選的身份驗證系統下有效運行：

• HTTP Basic Auth
• 身份驗證代理（為支持 LDAP、SAML、Kerberos 等）
• 客戶端證書
• 無記名令牌（Bearer tokens）
• OpenID Connect 令牌
• Webhook Token 身份驗證常見的身份驗證最佳實踐至少會啟用兩種身份驗證方法（多因素身份驗證或 MFA）并定期輪換客戶端證書。

Kubernetes 授權

任何用戶賬號或服務賬號一旦通過身份驗證就可以訪問 Kubernetes 集群并執行任何可能的操作，這種情況一定要減少。零信任的思想是，只有當通過身份驗證的用戶有必要的權限完成所請求的動作時，才會對請求授權。對于發起的每一個請求，該模型都要求指明用戶名、動作和受影響的 Kubernetes 集群對象。Kubernetes 支持的授權方法有很多種，包括：

• 基于屬性的訪問控制（ABAC）根據用戶、環境和資源屬性的組合動態進行訪問授權。
• 基于角色的訪問控制（RBAC）根據用戶在組織中的角色（如開發人員、管理員、安全員等）進行訪問授權。組織最常用的方式是 RBAC，因為它很實用，管控也比較簡單，而且提供了大多數情況所需的粒度。在行業中，常見的做法是啟用最小權限的 RBAC。

ABAC 提供了額外的粒度，但也需要額外的時間和資源來定義并做適當的配置。然而，ABAC 方法的問題排查更具挑戰性。因此，常見的做法是啟用最小權限的 RBAC。

Kubernetes 準入控制

準入控制器提供了一種實現業務邏輯的方法，用于改進 Kubernetes 的零信任方法。它的用途是使系統可以自動響應創建、修改、刪除或連接 Kubernetes 對象的請求。有時候，可能需要啟用多個準入控制器才能滿足組織的需求，如果一個特定的請求被其中任何一個拒絕，則系統也會自動拒絕。

目前，Kubernetes 內置的各種準入控制器為團隊執行策略及實現各種操作提供了大量的選項。動態控制器可以快速修改請求，以滿足既定規則集的要求。例如，ResourceQuota 準入控制器可以監視入站請求，確保它們不會違反 ResourceQuota 對象中列出的命名空間約束。要了解更多信息，可查閱文檔“準入控制器的用法”。

Kubernetes 日志和審計

審計等級有 4 種類型：

• None —— 不記錄這個事件
• Metadata —— 記錄請求元數據
• Request —— 記錄事件元數據和請求
• RequestResponse —— 記錄事件元數據、請求和響應除了指定審計等級，團隊還可以控制被審計事件的存儲位置。日志后端會將事件寫入集群的本地文件系統，然后由 Webhook 后端將審計事件發送到一個外部日志系統。

擴展零信任架構

雖然上面介紹的方法和實踐可以提供創建零信任環境的能力，但當要管理的 Kubernetes 集群很多時，恰當地配置和調整所有這些元素將變得更具挑戰性。當涉及多工作負載和 Kubernetes 發行版時，情況會變得尤其復雜。這不是一項新挑戰，是如今許多公司都面臨的問題。

例如，讓我們考慮這樣一個情況。公司管理著 100 個 Kubernetes 集群——從開發到 QA，再到過渡，然后生產——而且，這些集群要在地理上靠近其全球客戶群，以便他們的應用程序可以處理實時的視頻和音頻數據流。

要確保 Kubernetes 集群用戶訪問安全，公司需要解決以下三個問題：

1. 假如該公司有幾百名開發人員和幾十名 IT 運維人員，每個集群添加或刪除用戶都需要手動完成，那么這項艱苦的工作所解決的問題會比所導致的問題還多。
2. 如果發生意外事件，則修復時間至關重要。如果訪問方法要耗掉問題排查人員幾分鐘的時間才允許他登錄到受影響的集群，那么問題可能會加重。
3. 由于日志分散在 100 個集群里，所以不大可能提供審計和合規性報告的全局視圖。

平臺團隊注意事項

在企業平臺團隊的眾多目標中，其中一個是使全球的分布式 IT 團隊能夠集中管理用戶對其所有集群的訪問。目的是，既有效地保護和管理對 Kubernetes 基礎設施的訪問，又大幅簡化審計日志和合規性報告。

平臺團隊應考慮實現 Kubernetes 零信任訪問，確保之前介紹的最佳實踐得以應用和執行，從而保證整個 Kubernetes 環境的安全。避免手動在每個集群上應用最佳實踐，那樣可以大幅減低 IT 組織在大規模操作 Kubernetes 時的風險。

平臺團隊在設計 Kubernetes 零信任訪問時應考慮以下三個方面的收益：

1.使 RBAC 超級靈活：如果一名團隊成員的角色變了，那么訪問權限應該自動更新，這樣，任何人的權限都不會超出或少于他的角色。

2.使訪問快速簡單：通過安全單點登錄讓授權用戶可以無縫訪問，消除訪問任何集群的延遲。

3.即時場景憑證：授權用戶的服務賬號應該在用戶訪問時在遠程集群上即時創建，并在用戶登出后自動刪除，從而避免出現證書過期的情況。隨著 Kubernetes 集群和容器化應用程序越來越多，組織將日益暴露在運營一兩個集群時并不明顯的安全風險之下。因此，平臺團隊需要為整個 Kubernetes 基礎設施的集群和應用實現集中式的企業級安全與控制。