譯者 | 李睿

審校 | 孫淑娟

人們可以想象有這樣一座巨大的堡壘，這個(gè)堡壘有厚重的墻壁、堅(jiān)固的大門，以及瞭望塔和護(hù)城河，以免受攻擊。堡壘有多層防御可以阻止攻擊者，雖然攻擊者可能會(huì)游過護(hù)城河，但必須翻越高墻才能進(jìn)入堡壘。因此，攻擊者可能只會(huì)破壞單層防御，但多層防御會(huì)使其難以進(jìn)入堡壘。

如果仔細(xì)觀察，發(fā)現(xiàn)這些防御層都做了阻止攻擊者入侵這樣一件事。這正是保護(hù)應(yīng)用程序所需要的——防止未經(jīng)授權(quán)的訪問的多層防御。談到Kubernetes訪問控制，需要管理許多不同的組件。Kubernetes集群本質(zhì)上是復(fù)雜和動(dòng)態(tài)的，這使得它們很容易受到網(wǎng)絡(luò)攻擊。

本文探討對(duì)多個(gè)Kubernetes集群進(jìn)行訪問時(shí)如何管理的基本注意事項(xiàng)，有助于企業(yè)更好地規(guī)劃Kubernetes的整體安全性。

隔離Kubernetes API服務(wù)器

在Kubernetes集群中，通常是采用控制平臺(tái)控制節(jié)點(diǎn)，用節(jié)點(diǎn)控制Pod，用Pod控制容器，用容器控制應(yīng)用程序。但是能夠控制平臺(tái)的是什么?Kubernetes公開了允許企業(yè)配置整個(gè)Kubernetes集群的API，因此保護(hù)對(duì)Kubernetes API的訪問是保持Kubernetes安全性方面最關(guān)鍵的考慮因素之一。由于Kubernetes完全由API驅(qū)動(dòng)，因此控制和限制誰可以訪問集群以及允許他們執(zhí)行哪些操作是第一道防線。

以下來看看Kubernetes訪問控制的三個(gè)步驟。在身份驗(yàn)證過程開始之前，確保正確配置網(wǎng)絡(luò)訪問控制和TLS連接是首要任務(wù)。

(1)API認(rèn)證

訪問控制的第一步是驗(yàn)證請(qǐng)求。建議盡可能使用外部身份驗(yàn)證服務(wù)。例如，如果企業(yè)已經(jīng)使用身份提供程序(IdP)管理用戶帳戶，例如Okta、GSuite和Azure AD，以對(duì)用戶進(jìn)行身份驗(yàn)證。Kubernetes API服務(wù)器并不保證身份驗(yàn)證程序的運(yùn)行順序，因此確保用戶只綁定到單個(gè)身份驗(yàn)證方法非常重要。對(duì)以前使用過的身份驗(yàn)證方法和令牌進(jìn)行定期檢查，如果不再使用，則將其停用，這一點(diǎn)也很重要。

(2)API授權(quán)

一旦通過身份驗(yàn)證，Kubernetes會(huì)檢查請(qǐng)求是否被授權(quán)?；诮巧脑L問控制(RBAC)是授權(quán)API訪問的首選方式。在默認(rèn)情況下，應(yīng)該了解四個(gè)內(nèi)置的Kubernetes角色——集群管理員(cluster-admin)、管理員(admin)、編輯(edit)、查看(view)。集群角色可用于設(shè)置集群資源(例如節(jié)點(diǎn))的權(quán)限，而其角色可用于命名空間資源(例如pod)。Kubernetes中的RBAC具有一定的復(fù)雜性和人工操作。

(3)準(zhǔn)入控制

在成功驗(yàn)證和授權(quán)執(zhí)行特定任務(wù)后，最后一步是準(zhǔn)入控制以修改或驗(yàn)證請(qǐng)求。Kubernetes提供了幾個(gè)模塊來幫助定義和自定義允許在集群上運(yùn)行的內(nèi)容，例如資源請(qǐng)求限制和強(qiáng)制執(zhí)行Pod安全策略。準(zhǔn)入控制器還可用于通過Webhook擴(kuò)展Kubernetes API服務(wù)器，以實(shí)現(xiàn)高級(jí)安全性，例如實(shí)現(xiàn)圖像掃描。

基于角色的訪問控制(RBAC)

Kubernetes被如此大規(guī)模采用的原因之一是因?yàn)樯鐓^(qū)的蓬勃發(fā)展和定期更新。Kubernetes 1.6中引入的關(guān)鍵更新之一是基于角色的訪問控制(RBAC)。雖然基本身份驗(yàn)證和授權(quán)由RBAC負(fù)責(zé)，但角色的創(chuàng)建和維護(hù)在多個(gè)集群環(huán)境中變得至關(guān)重要。如果將內(nèi)置集群管理角色授予任何用戶，他們實(shí)際上可以在集群中執(zhí)行任何操作。管理和跟蹤角色和訪問權(quán)限是一項(xiàng)挑戰(zhàn)。

對(duì)于具有大型多集群環(huán)境的企業(yè)，將創(chuàng)建和刪除大量資源，這通常會(huì)增加未使用或丟失角色無人看管的風(fēng)險(xiǎn)。而在將來創(chuàng)建新角色時(shí)，某些非活動(dòng)角色綁定可能會(huì)意外授予權(quán)限。發(fā)生這種情況是因?yàn)榻巧壎梢砸貌辉俅嬖诘慕巧?。將來如果使用相同的角色名稱，這些未使用的角色綁定可以授予原本不應(yīng)該存在的權(quán)限。

集群的復(fù)雜性和動(dòng)態(tài)性

隨著集群、角色和用戶數(shù)量的增加，確?？刂菩枰脩?、組、角色和權(quán)限的適當(dāng)可見性。每次添加新角色時(shí)，都需要配置額外的規(guī)則。對(duì)于大型企業(yè)來說，這可能意味著需要管理數(shù)百甚至數(shù)千條規(guī)則。由于缺乏一個(gè)集中的系統(tǒng)來管理集群中的所有角色，這是管理員面臨最糟糕的噩夢(mèng)。

Kubernetes受歡迎的原因之一是它本質(zhì)上是可擴(kuò)展的。它配備了開箱即用的安全工具，允許應(yīng)用程序和基礎(chǔ)設(shè)施根據(jù)需求進(jìn)行擴(kuò)展。這意味著Kubernetes集群可以是短暫的，可以立即創(chuàng)建和銷毀。每次創(chuàng)建或銷毀集群時(shí)，都必須為特定用戶配置訪問權(quán)限。如果對(duì)集群的訪問沒有得到適當(dāng)?shù)墓芾恚@可能會(huì)導(dǎo)致安全漏洞，可能會(huì)授予對(duì)整個(gè)集群的未經(jīng)授權(quán)的訪問權(quán)限。

結(jié)論

如今的大多數(shù)團(tuán)隊(duì)分布在企業(yè)內(nèi)的不同業(yè)務(wù)部門。在通常情況下，開發(fā)人員、測(cè)試人員、業(yè)務(wù)分析師和顧問都可能在同一個(gè)應(yīng)用程序上工作——每個(gè)人都需要訪問不同的集群或同一集群的不同組件。為不同用戶提供正確級(jí)別的訪問權(quán)限，并在必要時(shí)撤銷該訪問權(quán)限非常重要。

Kubernetes是一個(gè)由節(jié)點(diǎn)、集群、Pod、容器、卷等多個(gè)組件組成的協(xié)調(diào)良好的系統(tǒng)。在規(guī)模上，可以將數(shù)百個(gè)這樣的組件分布在世界各地的多個(gè)集群中。識(shí)別“誰”需要“什么”，訪問“哪個(gè)”資源變得具有挑戰(zhàn)性。只有到那時(shí)，才會(huì)意識(shí)到對(duì)Kubernetes安全工具的需求，它不僅可以與企業(yè)的基礎(chǔ)設(shè)施無縫集成，還可以提供一種安全且統(tǒng)一的方式來管理對(duì)多個(gè)集群的訪問。

原文標(biāo)題：??Multi-Cluster Kubernetes Management and Access??，作者：Kyle Hunter