建站
咨詢
售后
建站咨詢
新聞中心
保護(hù)集群
成都創(chuàng)新互聯(lián)10多年成都企業(yè)網(wǎng)站定制服務(wù);為您提供網(wǎng)站建設(shè),網(wǎng)站制作,網(wǎng)頁設(shè)計(jì)及高端網(wǎng)站定制服務(wù),成都企業(yè)網(wǎng)站定制及推廣,對(duì)成都發(fā)電機(jī)維修等多個(gè)領(lǐng)域擁有豐富的網(wǎng)站制作經(jīng)驗(yàn)的網(wǎng)站建設(shè)公司。
本文檔涉及與保護(hù)集群免受意外或惡意訪問有關(guān)的主題，并對(duì)總體安全性提出建議。
在開始之前
你必須擁有一個(gè) Kubernetes 的集群，同時(shí)你的 Kubernetes 集群必須帶有 kubectl 命令行工具。 建議在至少有兩個(gè)節(jié)點(diǎn)的集群上運(yùn)行本教程，且這些節(jié)點(diǎn)不作為控制平面主機(jī)。 如果你還沒有集群，你可以通過 Minikube 構(gòu)建一個(gè)你自己的集群，或者你可以使用下面任意一個(gè) Kubernetes 工具構(gòu)建：
- Katacoda
- 玩轉(zhuǎn) Kubernetes
要檢查版本，請(qǐng)輸入 ?kubectl version?。
控制對(duì) Kubernetes API 的訪問
因?yàn)?nbsp;Kubernetes 是完全通過 API 驅(qū)動(dòng)的，所以，控制和限制誰可以通過 API 訪問集群， 以及允許這些訪問者執(zhí)行什么樣的 API 動(dòng)作，就成為了安全控制的第一道防線。
為所有 API 交互使用傳輸層安全 （TLS）
Kubernetes 期望集群中所有的 API 通信在默認(rèn)情況下都使用 TLS 加密， 大多數(shù)安裝方法也允許創(chuàng)建所需的證書并且分發(fā)到集群組件中。 請(qǐng)注意，某些組件和安裝方法可能使用 HTTP 來訪問本地端口， 管理員應(yīng)該熟悉每個(gè)組件的設(shè)置，以識(shí)別可能不安全的流量。
API 認(rèn)證
安裝集群時(shí)，選擇一個(gè) API 服務(wù)器的身份驗(yàn)證機(jī)制，去使用與之匹配的公共訪問模式。 例如，小型的單用戶集群可能希望使用簡(jiǎn)單的證書或靜態(tài)承載令牌方法。 更大的集群則可能希望整合現(xiàn)有的、OIDC、LDAP 等允許用戶分組的服務(wù)器。
所有 API 客戶端都必須經(jīng)過身份驗(yàn)證，即使它是基礎(chǔ)設(shè)施的一部分，比如節(jié)點(diǎn)、代理、調(diào)度程序和卷插件。 這些客戶端通常使用 服務(wù)帳戶 或 X509 客戶端證書，并在集群?jiǎn)?dòng)時(shí)自動(dòng)創(chuàng)建或是作為集群安裝的一部分進(jìn)行設(shè)置。
API 授權(quán)
一旦通過身份認(rèn)證，每個(gè) API 的調(diào)用都將通過鑒權(quán)檢查。 Kubernetes 集成基于角色的訪問控制（RBAC）組件， 將傳入的用戶或組與一組綁定到角色的權(quán)限匹配。 這些權(quán)限將動(dòng)作（get、create、delete）和資源（Pod、Service、Node）進(jìn)行組合，并可在名字空間或者集群范圍生效。 Kubernetes 提供了一組可直接使用的角色，這些角色根據(jù)客戶可能希望執(zhí)行的操作提供合理的責(zé)任劃分。 建議你同時(shí)使用 Node 和 RBAC 兩個(gè)鑒權(quán)組件，再與 NodeRestriction 準(zhǔn)入插件結(jié)合使用。
與身份驗(yàn)證一樣，簡(jiǎn)單而廣泛的角色可能適合于較小的集群，但是隨著更多的用戶與集群交互， 可能需要將團(tuán)隊(duì)劃分到有更多角色限制的、 單獨(dú)的名字空間中去。
就鑒權(quán)而言，很重要的一點(diǎn)是理解對(duì)象上的更新操作如何導(dǎo)致在其它地方發(fā)生對(duì)應(yīng)行為。 例如，用戶可能不能直接創(chuàng)建 Pod，但允許他們通過創(chuàng)建 Deployment 來創(chuàng)建這些 Pod， 這將讓他們間接創(chuàng)建這些 Pod。 同樣地，從 API 刪除一個(gè)節(jié)點(diǎn)將導(dǎo)致調(diào)度到這些節(jié)點(diǎn)上的 Pod 被中止，并在其他節(jié)點(diǎn)上重新創(chuàng)建。 原生的角色設(shè)計(jì)代表了靈活性和常見用例之間的平衡，但須限制的角色應(yīng)該被仔細(xì)審查， 以防止意外的權(quán)限升級(jí)。如果內(nèi)置的角色無法滿足你的需求，則可以根據(jù)使用場(chǎng)景需要?jiǎng)?chuàng)建特定的角色。
控制對(duì) Kubelet 的訪問
Kubelet 公開 HTTPS 端點(diǎn)，這些端點(diǎn)提供了對(duì)節(jié)點(diǎn)和容器的強(qiáng)大的控制能力。 默認(rèn)情況下，Kubelet 允許對(duì)此 API 進(jìn)行未經(jīng)身份驗(yàn)證的訪問。
生產(chǎn)級(jí)別的集群應(yīng)啟用 Kubelet 身份認(rèn)證和授權(quán)。
控制運(yùn)行時(shí)負(fù)載或用戶的能力
Kubernetes 中的授權(quán)故意設(shè)計(jì)成較高抽象級(jí)別，側(cè)重于對(duì)資源的粗粒度行為。 更強(qiáng)大的控制是 策略 的形式呈現(xiàn)的，根據(jù)使用場(chǎng)景限制這些對(duì)象如何作用于集群、自身和其他資源。
限制集群上的資源使用
資源配額（Resource Quota）限制了賦予命名空間的資源的數(shù)量或容量。 資源配額通常用于限制名字空間可以分配的 CPU、內(nèi)存或持久磁盤的數(shù)量， 但也可以控制每個(gè)名字空間中存在多少個(gè) Pod、Service 或 Volume。
限制范圍（Limit Range） 限制上述某些資源的最大值或者最小值，以防止用戶使用類似內(nèi)存這樣的通用保留資源時(shí)請(qǐng)求不合理的過高或過低的值， 或者在沒有指定的情況下提供默認(rèn)限制。
控制容器運(yùn)行的特權(quán)
Pod 定義包含了一個(gè)安全上下文， 用于描述一些訪問請(qǐng)求，如以某個(gè)節(jié)點(diǎn)上的特定 Linux 用戶（如 root）身份運(yùn)行， 以特權(quán)形式運(yùn)行，訪問主機(jī)網(wǎng)絡(luò)，以及一些在宿主節(jié)點(diǎn)上不受約束地運(yùn)行的其它控制權(quán)限等等。
你可以配置 Pod 安全準(zhǔn)入來在某個(gè) 名字空間中 強(qiáng)制實(shí)施特定的 Pod 安全標(biāo)準(zhǔn)（Pod Security Standard）， 或者檢查安全上的缺陷。
一般來說，大多數(shù)應(yīng)用程序需要對(duì)主機(jī)資源的有限制的訪問， 這樣它們可以在不訪問主機(jī)信息的情況下，成功地以 root 賬號(hào)（UID 0）運(yùn)行。 但是，考慮到與 root 用戶相關(guān)的特權(quán)，在編寫應(yīng)用程序容器時(shí)，你應(yīng)該使用非 root 用戶運(yùn)行。 類似地，希望阻止客戶端應(yīng)用程序從其容器中逃逸的管理員，應(yīng)該應(yīng)用 Baseline 或 Restricted Pod 安全標(biāo)準(zhǔn)。
限制網(wǎng)絡(luò)訪問
基于名字空間的網(wǎng)絡(luò)策略 允許應(yīng)用程序作者限制其它名字空間中的哪些 Pod 可以訪問自身名字空間內(nèi)的 Pod 和端口。 現(xiàn)在已經(jīng)有許多支持網(wǎng)絡(luò)策略的 Kubernetes 網(wǎng)絡(luò)驅(qū)動(dòng)。
配額（Quota）和限制范圍（Limit Range）也可用于控制用戶是否可以請(qǐng)求節(jié)點(diǎn)端口或負(fù)載均衡服務(wù)。 在很多集群上，節(jié)點(diǎn)端口和負(fù)載均衡服務(wù)也可控制用戶的應(yīng)用程序是否在集群之外可見。
此外也可能存在一些基于插件或基于環(huán)境的網(wǎng)絡(luò)規(guī)則，能夠提供額外的保護(hù)能力。 例如各節(jié)點(diǎn)上的防火墻、物理隔離集群節(jié)點(diǎn)以防止串?dāng)_或者高級(jí)的網(wǎng)絡(luò)策略等。
限制云元數(shù)據(jù) API 訪問
云平臺(tái)（AWS, Azure, GCE 等）經(jīng)常將 metadata 本地服務(wù)暴露給實(shí)例。 默認(rèn)情況下，這些 API 可由運(yùn)行在實(shí)例上的 Pod 訪問，并且可以包含 該云節(jié)點(diǎn)的憑據(jù)或配置數(shù)據(jù)（如 kubelet 憑據(jù)）。 這些憑據(jù)可以用于在集群內(nèi)升級(jí)或在同一賬戶下升級(jí)到其他云服務(wù)。
在云平臺(tái)上運(yùn)行 Kubernetes 時(shí)，需要限制對(duì)實(shí)例憑據(jù)的權(quán)限，使用 網(wǎng)絡(luò)策略 限制 Pod 對(duì)元數(shù)據(jù) API 的訪問，并避免使用配置數(shù)據(jù)來傳遞機(jī)密信息。
控制 Pod 可以訪問的節(jié)點(diǎn)
默認(rèn)情況下，對(duì) Pod 可以運(yùn)行在哪些節(jié)點(diǎn)上是沒有任何限制的。 Kubernetes 給最終用戶提供了 一組豐富的策略用于控制 Pod 所放置的節(jié)點(diǎn)位置， 以及基于污點(diǎn)的 Pod 放置和驅(qū)逐。 對(duì)于許多集群，使用這些策略來分離工作負(fù)載可以作為一種約定，要求作者遵守或者通過工具強(qiáng)制。
對(duì)于管理員，Beta 階段的準(zhǔn)入插件 ?PodNodeSelector? 可用于強(qiáng)制某名字空間中的 Pod 使用默認(rèn)的或特定的節(jié)點(diǎn)選擇算符。 如果最終用戶無法改變名字空間，這一機(jī)制可以有效地限制特定工作負(fù)載中所有 Pod 的放置位置。
保護(hù)集群組件免受破壞
本節(jié)描述保護(hù)集群免受破壞的一些常用模式。
限制訪問 etcd
擁有對(duì) API 的 etcd 后端的寫訪問權(quán)限相當(dāng)于獲得了整個(gè)集群的 root 權(quán)限， 讀訪問權(quán)限也可能被利用，實(shí)現(xiàn)相當(dāng)快速的權(quán)限提升。 對(duì)于從 API 服務(wù)器訪問其 etcd 服務(wù)器，管理員應(yīng)該總是使用比較強(qiáng)的憑證，如通過 TLS 客戶端證書來實(shí)現(xiàn)雙向認(rèn)證。 通常，我們建議將 etcd 服務(wù)器隔離到只有 API 服務(wù)器可以訪問的防火墻后面。
Caution: 允許集群中其它組件對(duì)整個(gè)主鍵空間（keyspace）擁有讀或?qū)憴?quán)限去訪問 etcd 實(shí)例， 相當(dāng)于授予這些組件集群管理員的訪問權(quán)限。 對(duì)于非主控組件，強(qiáng)烈推薦使用不同的 etcd 實(shí)例，或者使用 etcd 的訪問控制列表 來限制這些組件只能讀或?qū)懼麈I空間的一個(gè)子集。
啟用審計(jì)日志
審計(jì)日志是 Beta 特性， 負(fù)責(zé)記錄 API 操作以便在發(fā)生破壞時(shí)進(jìn)行事后分析。 建議啟用審計(jì)日志，并將審計(jì)文件歸檔到安全服務(wù)器上。
限制使用 alpha 和 beta 特性
Kubernetes 的 alpha 和 beta 特性還在努力開發(fā)中，可能存在導(dǎo)致安全漏洞的缺陷或錯(cuò)誤。 要始終評(píng)估 alpha 和 beta 特性可能給你的安全態(tài)勢(shì)帶來的風(fēng)險(xiǎn)。 當(dāng)你懷疑存在風(fēng)險(xiǎn)時(shí)，可以禁用那些不需要使用的特性。
經(jīng)常輪換基礎(chǔ)設(shè)施證書
一項(xiàng)機(jī)密信息或憑據(jù)的生命期越短，攻擊者就越難使用該憑據(jù)。 在證書上設(shè)置較短的生命期并實(shí)現(xiàn)自動(dòng)輪換是控制安全的一個(gè)好方法。 使用身份驗(yàn)證提供程序時(shí)，應(yīng)該使用那些可以控制所發(fā)布令牌的合法時(shí)長的提供程序， 并盡可能設(shè)置較短的生命期。 如果在外部集成場(chǎng)景中使用服務(wù)帳戶令牌，則應(yīng)該經(jīng)常性地輪換這些令牌。 例如，一旦引導(dǎo)階段完成，就應(yīng)該撤銷用于配置節(jié)點(diǎn)的引導(dǎo)令牌，或者取消它的授權(quán)。
在啟用第三方集成之前，請(qǐng)先審查它們
許多集成到 Kubernetes 的第三方軟件或服務(wù)都可能改變你的集群的安全配置。 啟用集成時(shí)，在授予訪問權(quán)限之前，你應(yīng)該始終檢查擴(kuò)展所請(qǐng)求的權(quán)限。 例如，許多安全性集成中可能要求查看集群上的所有 Secret 的訪問權(quán)限， 本質(zhì)上該組件便成為了集群的管理員。 當(dāng)有疑問時(shí)，如果可能的話，將要集成的組件限制在某指定名字空間中運(yùn)行。
如果執(zhí)行 Pod 創(chuàng)建操作的組件能夠在 ?kube-system? 這類名字空間中創(chuàng)建 Pod， 則這類組件也可能獲得意外的權(quán)限，因?yàn)檫@些 Pod 可以訪問服務(wù)賬戶的 Secret， 或者，如果對(duì)應(yīng)服務(wù)帳戶被授權(quán)訪問寬松的 PodSecurityPolicy， 它們就能以較高的權(quán)限運(yùn)行。
如果你使用 Pod 安全準(zhǔn)入， 并且允許任何組件在一個(gè)允許執(zhí)行特權(quán) Pod 的名字空間中創(chuàng)建 Pod，這些 Pod 就可能從所在的容器中逃逸，利用被拓寬的訪問權(quán)限來實(shí)現(xiàn)特權(quán)提升。
你不應(yīng)該允許不可信的組件在任何系統(tǒng)名字空間（名字以 ?kube-? 開頭）中創(chuàng)建 Pod， 也不允許它們?cè)谠L問權(quán)限授權(quán)可被利用來提升特權(quán)的名字空間中創(chuàng)建 Pod。
對(duì) Secret 進(jìn)行靜態(tài)加密
一般情況下，etcd 數(shù)據(jù)庫包含了通過 Kubernetes API 可以訪問到的所有信息， 并且可能為攻擊者提供對(duì)你的集群的狀態(tài)的較多的可見性。 你要始終使用經(jīng)過充分審查的備份和加密方案來加密備份數(shù)據(jù)， 并考慮在可能的情況下使用全盤加密。
Kubernetes 支持靜態(tài)數(shù)據(jù)加密。 該功能在 1.7 版本引入，并在 1.13 版本成為 Beta。 它會(huì)加密 etcd 里面的 ?Secret? 資源，以防止某一方通過查看 etcd 的備份文件查看到這些 Secret 的內(nèi)容。雖然目前該功能還只是 Beta 階段， 在備份未被加密或者攻擊者獲取到 etcd 的讀訪問權(quán)限時(shí)，它仍能提供額外的防御層級(jí)。
接收安全更新和報(bào)告漏洞的警報(bào)
請(qǐng)加入 kubernetes-announce 組，這樣你就能夠收到有關(guān)安全公告的郵件。
本文標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes保護(hù)集群
地址分享：http://www.fisionsoft.com.cn/article/cdjjdpg.html
