現(xiàn)代 IT 環(huán)境日益動態(tài)化。例如，Kubernetes 正在突破許多 IT 組織的可能性。

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

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

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

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

Kubernetes 集群的零信任訪問

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

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

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

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

實現(xiàn)零信任的 API 服務(wù)器最佳實踐：

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

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

• 驗證
• 授權(quán)
• 準(zhǔn)入控制
• 記錄和審計

Kubernetes 身份驗證

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

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

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

對 Kubernetes 的授權(quán)

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

Kubernetes 支持多種授權(quán)方法，包括：

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

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

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

Kubernetes 準(zhǔn)入控制

準(zhǔn)入控制器提供了一種實現(xiàn)業(yè)務(wù)邏輯的方法，以改進 Kubernetes 的零信任方法。準(zhǔn)入控制器的目的是使系統(tǒng)能夠自動處理創(chuàng)建、修改、刪除或連接到 Kubernetes 對象的請求。可能需要啟用多個準(zhǔn)入控制器以滿足您組織的需求，如果其中任何一個拒絕特定請求，系統(tǒng)也會自動拒絕它。

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

Kubernetes 的日志記錄和審計

審計功能提供了集群內(nèi)執(zhí)行的操作的跟蹤記錄，這對于 Kubernetes 安全態(tài)勢至關(guān)重要。這些功能可以跟蹤任何用戶、應(yīng)用程序和控制平面本身的任何操作。

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

• 無 – 不記錄此事件
• 元數(shù)據(jù) – 記錄請求元數(shù)據(jù)
• 請求 - 記錄事件元數(shù)據(jù)和請求
• RequestResponse – 記錄事件元數(shù)據(jù)、請求和響應(yīng)

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

擴展零信任架構(gòu)

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

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

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

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

平臺團隊的注意事項

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

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

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

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

一兩個集群時并不會存在明顯的安全風(fēng)險，但隨著 Kubernetes 集群和容器化應(yīng)用程序數(shù)量的增加。因此，平臺團隊需要在其整個 Kubernetes 基礎(chǔ)架構(gòu)中為集群和應(yīng)用程序啟用集中的企業(yè)級安全和控制。