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

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

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

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

Kubernetes 集群零信任訪問(wèn)

零信任是一個(gè)安全模型，它會(huì)自動(dòng)假設(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)勢(shì)，確保整個(gè)環(huán)境值得信任。

以下是對(duì) Kubernetes 基本工作原理的一個(gè)簡(jiǎn)單說(shuō)明：

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

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

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

Kubernetes 身份驗(yàn)證

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

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

Kubernetes 授權(quán)

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

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

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

Kubernetes 準(zhǔn)入控制

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

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

Kubernetes 日志和審計(jì)

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

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

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

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

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

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

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

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

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

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

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

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

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

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