現(xiàn)代 IT 環(huán)境變得越來越動態(tài)。舉例來說，Kubernetes 拓展了許多組織的可能性邊界。開源技術(shù)在容器化應(yīng)用程序自動部署、擴(kuò)展性和管理方面有諸多好處。特別地，IT 團(tuán)隊(duì)可以利用其強(qiáng)大的功能、有效性和靈活性快速開發(fā)現(xiàn)代應(yīng)用程序并大規(guī)模交付。

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

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

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

Kubernetes 集群零信任訪問

零信任是一個安全模型，它會自動假設(shè)所有在網(wǎng)絡(luò)中或網(wǎng)絡(luò)間進(jìn)行操作的人、系統(tǒng)和服務(wù)都是不可信任的。零信任正成為預(yù)防惡意攻擊的最佳技術(shù)。以身份驗(yàn)證、授權(quán)和加密技術(shù)為基礎(chǔ)，零信任的目的是持續(xù)驗(yàn)證安全配置和態(tài)勢，確保整個環(huán)境值得信任。

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

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

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

• 啟用所有地方的 TLS。
• 使用 API 服務(wù)器的私有端點(diǎn)。
• API 服務(wù)器使用第三方身份驗(yàn)證。
• 關(guān)閉 API 服務(wù)器的防火墻入站規(guī)則，確保它是隱形的，不能直接從 Internet 訪問。在確保傳輸層安全后，Kubernetes 還要包含必要的鉤子，用于實(shí)現(xiàn)零信任，并控制對每個 Kubernetes 集群的 API 服務(wù)器的訪問。這些鉤子代表了 Kubernetes 堅(jiān)固安全態(tài)勢的 4 個關(guān)鍵領(lǐng)域：
• 身份驗(yàn)證
• 授權(quán)
• 準(zhǔn)入控制
• 日志和審計(jì)

Kubernetes 身份驗(yàn)證

在零信任原則下，所有與 Kubernetes 集群關(guān)聯(lián)的用戶賬號和服務(wù)賬號在執(zhí)行 API 調(diào)用之前都要進(jìn)行身份驗(yàn)證。有許多安全模塊和插件可以保證 Kubernetes 平臺在團(tuán)隊(duì)首選的身份驗(yàn)證系統(tǒng)下有效運(yùn)行：

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

Kubernetes 授權(quán)

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

• 基于屬性的訪問控制（ABAC）根據(jù)用戶、環(huán)境和資源屬性的組合動態(tài)進(jìn)行訪問授權(quán)。
• 基于角色的訪問控制（RBAC）根據(jù)用戶在組織中的角色（如開發(fā)人員、管理員、安全員等）進(jìn)行訪問授權(quán)。組織最常用的方式是 RBAC，因?yàn)樗軐?shí)用，管控也比較簡單，而且提供了大多數(shù)情況所需的粒度。在行業(yè)中，常見的做法是啟用最小權(quán)限的 RBAC。

ABAC 提供了額外的粒度，但也需要額外的時間和資源來定義并做適當(dāng)?shù)呐渲谩Ｈ欢?，ABAC 方法的問題排查更具挑戰(zhàn)性。因此，常見的做法是啟用最小權(quán)限的 RBAC。

Kubernetes 準(zhǔn)入控制

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

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

Kubernetes 日志和審計(jì)

審計(jì)等級有 4 種類型：

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

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

雖然上面介紹的方法和實(shí)踐可以提供創(chuàng)建零信任環(huán)境的能力，但當(dāng)要管理的 Kubernetes 集群很多時，恰當(dāng)?shù)嘏渲煤驼{(diào)整所有這些元素將變得更具挑戰(zhàn)性。當(dāng)涉及多工作負(fù)載和 Kubernetes 發(fā)行版時，情況會變得尤其復(fù)雜。這不是一項(xiàng)新挑戰(zhàn)，是如今許多公司都面臨的問題。

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

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

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

平臺團(tuán)隊(duì)注意事項(xiàng)

在企業(yè)平臺團(tuán)隊(duì)的眾多目標(biāo)中，其中一個是使全球的分布式 IT 團(tuán)隊(duì)能夠集中管理用戶對其所有集群的訪問。目的是，既有效地保護(hù)和管理對 Kubernetes 基礎(chǔ)設(shè)施的訪問，又大幅簡化審計(jì)日志和合規(guī)性報告。

平臺團(tuán)隊(duì)?wèi)?yīng)考慮實(shí)現(xiàn) Kubernetes 零信任訪問，確保之前介紹的最佳實(shí)踐得以應(yīng)用和執(zhí)行，從而保證整個 Kubernetes 環(huán)境的安全。避免手動在每個集群上應(yīng)用最佳實(shí)踐，那樣可以大幅減低 IT 組織在大規(guī)模操作 Kubernetes 時的風(fēng)險。

平臺團(tuán)隊(duì)在設(shè)計(jì) Kubernetes 零信任訪問時應(yīng)考慮以下三個方面的收益：

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

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

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