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