Kubernetes 是一個可用于微服務的開源容器編排平臺。當我們想要部署容器化應用程序、自動化管理和擴展應用程序時，Kubernetes 非常有用。

在容器中運行單個微服務而不是在同一虛擬機中運行多個進程幾乎總是更安全。每當我們在 Kubernetes 中啟動任何 pod 時，該 pod 都會托管在節(jié)點內(nèi)。Kubernetes 中有兩種類型的節(jié)點可用。第一個是Master節(jié)點，第二個是Worker節(jié)點。應用程序代碼在集群內(nèi)部的工作節(jié)點中運行。工作節(jié)點托管 Pod 并將資源報告發(fā)送給主節(jié)點。顧名思義，主節(jié)點是所有工作節(jié)點的主節(jié)點，工作節(jié)點是主節(jié)點的從節(jié)點。Master節(jié)點和Worker節(jié)點共同組成一個集群。

什么是 Kubernetes 安全性？

Kubernetes主要搞云環(huán)境，包括集群、容器、云和代碼。本質(zhì)上，代碼、集群和容器的結(jié)合關系到 Kubernetes 的安全性。因此，特性包括云環(huán)境中的容器安全、集群安全、訪問控制和應用安全，圍繞這些特性構建 Kubernetes 集群安全。

經(jīng)常掃描整個系統(tǒng)以識別漏洞和錯誤配置，以立即確保系統(tǒng)安全。此外，Kubernetes API 和 Pod 容器安全性是 Kubernetes 安全性的重要方面，這對于商業(yè)安全解決方案來說是必需的，使 Kubernetes 具有彈性和可擴展性，并包含有價值的信息。

Kubernetes 安全嗎？

眾所周知，組織正在向云邁進，這里的云指的是 Kubernetes。Kubernetes 在行業(yè)中的使用正在增加。根據(jù)云原生計算基金會 (CNCF) 的最新年度調(diào)查，83% 的組織使用 Kubernetes。在這 83% 的組織中，23% 的組織使用超過 11 個 Kubernetes 集群進行生產(chǎn)。

隨著 Kubernetes 使用的增加，與 Kubernetes 集群相關的安全問題和擔憂也迅速增加。紅帽企業(yè)對 500 名 DevOps 專業(yè)人員進行了調(diào)查，以檢查 Kubernetes 的安全性和采用情況。該調(diào)查得出以下結(jié)論：

• 大約 94% 的 DevOps 專業(yè)人員至少報告過一起安全事件。
• 由于安全問題，其中 54% 推遲了應用程序的發(fā)布。
• 大約 59% 的人表示，安全性是使用 Kubernetes 集群最大的擔憂。

Kubernetes 安全最佳實踐：4C 安全模型

在為 Kubernetes 安全創(chuàng)建縱深防御策略時，必須安裝各種安全措施。即使是相同的方法也被云原生安全性所遵循和推薦。云原生系統(tǒng)將其安全態(tài)勢和技術分為四層。以下是這四層：

4C 安全模型分別代表云、集群、容器和代碼。從開發(fā)階段開始到部署階段結(jié)束，我們上面提到的所有四個層都為所涉及的所有步驟提供了安全性。

使用這個 4C 安全模型，我們將分別討論這四個層的 Kubernetes 安全最佳實踐。讓我們從云層開始一一討論 Kubernetes 安全最佳實踐。

云

云層代表服務器基礎設施。當我們在任何云服務提供商（CSP）上設置服務器時，都會涉及到各種服務。云服務提供商處理管理操作系統(tǒng)、平臺和網(wǎng)絡等服務，但消費者仍然負責保護和監(jiān)控數(shù)據(jù)。

防火墻和加密

“Secrets”對象在 Kubernetes 中用于存儲或保存敏感數(shù)據(jù)或信息。這里，敏感數(shù)據(jù)可以是任何用戶名、密碼、令牌、密鑰和其他必要數(shù)據(jù)。秘密可以幫助我們減少潛在的攻擊面。Pod 可以訪問私有數(shù)據(jù)，因為秘密為 Pod 生命周期提供了靈活性。為了網(wǎng)絡安全，我們需要監(jiān)控網(wǎng)絡流量。防火墻還可以識別潛在的不安全流量。對秘密資源進行加密至關重要，因此 Kubernetes 支持加密。

需要注意的一件事是 etcd 配置文件的加密。這很重要，因為該文件在 Kubernetes 的 API 服務器級別以簡單的純文本格式存儲。加密文件的好處是，即使攻擊者獲得了對 etcd 文件的讀寫訪問權限，他也無法理解任何內(nèi)容。要解密 etcd 文件，需要加密密鑰來加密該文件。只有 API 服務器中存儲有加密密鑰。

建議啟用防火墻規(guī)則、監(jiān)控活動網(wǎng)絡流量并僅啟用本地端口。在控制平面，也稱為主節(jié)點，必須開放的端口有6443、2379、2380、10250、8472等一些端口。對于工作節(jié)點，也有一些端口。分別是 10250、10255 和 8472。

阻止訪問 Kube API 服務器

Kubernetes API 訪問控制過程涉及三個步驟。以下是這三個步驟：

• 請求訪問已驗證。
• 真實性有保證。
• 傳遞到準入控制進行訪問。

在身份驗證操作開始之前，將適當檢查 TLS 連接和網(wǎng)絡訪問控制設置。認證過程有時可能會很復雜或復雜。

為了控制平面和 Kubelet 之間的通信、與控制平面的內(nèi)部通信或與 API 服務器的連接，只能使用 TLS 連接。我們可以使用 Kube-API 服務器命令行將 TLS 證書和 TLS 私鑰文件發(fā)送到 API 服務器。

出于通信目的，Kubernetes API 使用兩個 HTTP 端口。第一個端口是本地端口，第二個端口是安全端口。本地端口不執(zhí)行任何請求的身份驗證和授權，因為它不需要任何傳輸層身份驗證提供程序或安全連接。因此，確保本地端口在 Kubernetes 集群外部無法訪問或開放就變得更加關鍵。

此外，由于存在安全漏洞的可能性，服務帳戶應盡快接受全面審核，特別是當它們鏈接到用于專門 Kubernetes 管理任務的特定命名空間和服務帳戶令牌時。每個應用程序都應該有其唯一的服務帳戶，而不是使用默認的服務帳戶。

本節(jié)將詳細討論保持 Kubernetes 集群安全的方法。讓我們分別簡要地研究一下所有的方法。

應用最小訪問權限

Kubernetes 為其元素提供了一些基本的安全性，例如授權。因此，要訪問集群組件，您需要登錄，以便您訪問集群組件或集群節(jié)點的請求獲得授權。在這里，我們可以使用基于角色的訪問控制（RBAC）。使用 RBAC，我們可以聲明哪個實體可以使用 Kubernetes API 在特定資源上執(zhí)行特定活動。它是 Kubernetes API 身份驗證限制訪問的最佳、最有效的方法之一。還建議啟用審核日志記錄以提高安全性。

Kubernetes API

為了做出任何授權決策，RBAC 授權使用rbac.authorization.k8s.io API 組。它可以根據(jù)需要進行策略更改。RBAC 激活涉及在將權限標志設置為包含 RBAC 的逗號分隔列表后重新啟動 API 服務器。

kube-apiserver --authorization-mode=Example,RBAC --other-options --more-options

請考慮以下示例。它只是提供 pod 供讀取，作為“默認”命名空間中的角色。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata: 

 namespace: default  
 name: read-user
rules:
 - apiGroups: [""]  
   resources: ["pods"]  
   verbs: ["get", "watch", "list"]

使用準入控制器和網(wǎng)絡策略

在 Kubernetes 容器編排系統(tǒng)中，準入控制器插件強制執(zhí)行集群的治理和使用。準入控制器可以捕獲經(jīng)過身份驗證的 API 請求并更改或拒絕它們。因此，他們也被稱為守門人。

準入控制器可以通過在整個集群中強制執(zhí)行適當?shù)?Pod 安全策略和狀態(tài)來提高安全性。內(nèi)置 Pod 安全策略準入控制器就是這種情況的一個合適示例。除此之外，它還可以用來阻止容器以 root 身份運行或保證根文件系統(tǒng)始終以只讀方式安裝。

容器

在集群環(huán)境中，容器使用容器運行時引擎運行。Kubernetes 最常見的容器運行時環(huán)境是 Docker。它還附帶了各種映像，程序員可以使用它們來設置從 Linux 到 Nginx 服務器的任何內(nèi)容。

使用經(jīng)過驗證的圖像來避免不需要的向量獲得訪問權限

為了避免易受攻擊的鏡像，必須掃描所有容器鏡像，并且只允許那些遵循或符合組織策略的容器鏡像。這是因為組織更容易受到此類安全風險的影響。眾所周知，大部分代碼通常取自開源項目，因此掃描圖像是否存在安全漏洞并遵循組織制定的網(wǎng)絡策略變得更加重要。對于所有容器鏡像，容器注冊表是中央存儲庫。您應該避免在容器映像本身中加載不需要的內(nèi)核模塊。

私有注冊表應用作容器注冊表，而不是公共注冊表，因為公共注冊表的安全性低于遠程注冊表。只有通過組織的網(wǎng)絡策略驗證的圖像才必須存儲在私有注冊表中。這樣，我們可以通過減少易受攻擊的映像的使用來減少組織操作系統(tǒng)的攻擊面。

掃描圖像的過程也可以安裝在CI管道中。這里，CI代表持續(xù)集成。讓我們看看什么是圖像掃描。在此過程中，系統(tǒng)會掃描映像中的 CVE、漏洞或不良做法。由于它安裝在 CI/CD 管道中，因此漏洞無法到達注冊表。它還可以防止由于使用第三方圖像而導致的管道漏洞。

限制應用程序權限

支持在運行容器時使用 root 權限的最有力論據(jù)之一是需要防止權限升級。root 用戶可以在系統(tǒng)上運行不同的命令，就像 root 用戶可以在容器系統(tǒng)中運行任何命令一樣。對于 root 用戶來說命令執(zhí)行變得非常容易。這給不良行為者帶來了困難，即使他們以某種方式獲得了訪問權限。

軟件包的安裝方法、用戶的創(chuàng)建、服務的啟動以及其他此類活動都需要進行充分的審查。這可能會給應用程序開發(fā)人員帶來不同的挑戰(zhàn)。我們還應該避免在虛擬機上以 root 用戶身份運行應用程序，以防止安全風險。容器也會發(fā)生同樣的情況。除 root 之外的任何其他用戶都不應具有寫入權限。

如果容器被破壞，根用戶將有權訪問并能夠在底層主機上運行任何操作系統(tǒng)命令，就像以根用戶身份登錄一樣。這會帶來危險，包括：-

• 可以訪問文件系統(tǒng)掛載
• 還可以訪問其他云資源
• 訪問用于連接其他資源的憑據(jù)。（我們應該使用密碼管理器來避免這種情況）
• 惡意軟件可以安裝在主機操作系統(tǒng)上。

代碼

盡管我們可能在容器中運行各種應用程序，但有時我們將代碼層稱為應用程序安全性。此外，企業(yè)最能控制的是傳輸層安全。由于您的應用程序及其關聯(lián)的數(shù)據(jù)庫通常對互聯(lián)網(wǎng)開放，因此如果所有其他組件都受到保護，攻擊者將集中嘗試攻擊系統(tǒng)的這一部分。

掃描漏洞

大多數(shù)應用程序軟件本質(zhì)上依賴于庫、其他第三方組件和開源包。因此，其中任何一個的漏洞肯定會影響整體性能。因此，您當前使用的程序很可能包含漏洞。

實施 Kubernetes 安全最佳實踐

在本節(jié)中，我們將討論 Kubernetes 安全最佳實踐在不同領域的實施。

資源管理

為了執(zhí)行容器，每個 Pod 都可以使用各種資源，包括內(nèi)存和 CPU。因此，聲明 Pod 時需要指定每個容器必須分配多少資源。

安全上下文

容器和 Pod 具有安全上下文，解釋它們的權限和訪問控制設置。自主訪問控制 (DAC) 需要根據(jù)用戶 ID（容器的基本術語）授權滲透某個項目。

環(huán)境安全更新

當容器承受各種開源軟件和其他軟件時，有可能稍后發(fā)現(xiàn)安全漏洞。最終，跟上軟件更新并掃描圖像以查看是否發(fā)現(xiàn)并修補了任何漏洞至關重要。此外，還可以使用 Kubernetes 的滾動更新功能升級到平臺上的最新版本，從而改進正在運行的應用程序的安全工具。

左移方法

Kubernetes 在設計時不會立即將網(wǎng)絡策略應用到 pod。包含 Pod 的容器幾乎是不可更改的，這意味著它們會被調(diào)度。或者，當它們不可用時，它們會被重新部署和銷毀。

因此，通過左移測試可以快速識別和解決容器生命周期中的缺陷，從而更有效地管理容器。

Kubernetes 中如何處理安全性？

Kubernetes 中的安全性是通過 RBAC（基于角色的訪問控制）、網(wǎng)絡策略、容器運行時安全性以及定期更新來解決漏洞等功能進行管理的。

Kubernetes 存在安全風險嗎？

Kubernetes 本身并不存在安全風險，但配置錯誤、網(wǎng)絡訪問和控制不足以及部署不當可能會引入安全漏洞。

如何保護 Kubernetes 集群的安全？

為了保護 Kubernetes 集群的安全，需要實施強大的訪問控制、啟用審核日志記錄、頻繁輪換基礎設施憑證、使用網(wǎng)絡策略、采用容器運行時安全性并定期進行安全審核。文章來源地址http://www.zghlxwxcb.cn/news/detail-768215.html

到了這里，關于Kubernetes 安全最佳實踐：保護您的秘密的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！