保護云原生應(yīng)用的3款K8S原生控件分別是什么

本篇文章給大家分享的是有關(guān)保護云原生應(yīng)用的3款K8S原生控件分別是什么，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。

創(chuàng)新互聯(lián)公司是一家專業(yè)提供盤州企業(yè)網(wǎng)站建設(shè),專注與網(wǎng)站設(shè)計制作、成都網(wǎng)站制作、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為盤州眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)的建站公司優(yōu)惠進行中。

隨著越來越多的企業(yè)開始采用容器技術(shù)，他們正在面臨一個重大挑戰(zhàn)——如何保護容器應(yīng)用程序的安全？比起存儲、網(wǎng)絡(luò)和監(jiān)控，安全常常是一個被積壓已久的問題。再加上需要對員工進行Kubernetes相關(guān)的培訓，對安全問題的關(guān)注已經(jīng)遠遠滯后了。事實上，The New Stack發(fā)布的一項調(diào)查顯示，近50%的Kubernetes用戶表示，安全是他們尚未解決的首要問題。

我們將深入了解Kubernetes所面臨的安全威脅并展示保護集群的最佳實踐，然后提供一些有用的工具以幫助開發(fā)人員維護集群安全。

工具介紹

Rancher Kubernetes Engine(RKE)

RKE是一個經(jīng)過CNCF認證的Kubernetes發(fā)行版，可以在Docker容器內(nèi)完整運行。它通過移除大多數(shù)的主機依賴項并提供一個部署、升級和回滾的穩(wěn)定路徑，解決了Kubernetes安裝過于復雜的問題。RKE使用聲明式Y(jié)AML文件來配置和創(chuàng)建Kubernetes環(huán)境。這可以實現(xiàn)可重現(xiàn)的本地或遠程環(huán)境。

KubeLinter

KubeLinter是一個靜態(tài)的分析工具，它可以查看Kubernetes YAML文件以確保聲明的應(yīng)用程序配置堅持最佳實踐。KubeLinter是StackRox首個開源工具，用于從命令行實現(xiàn)安全檢查以及作為CI流程的一部分。KubeLinter是一個二進制文件，它接收YAML文件的路徑，并對它們進行一系列的檢查。管理員和開發(fā)人員可以創(chuàng)建自己的策略來執(zhí)行，從而實現(xiàn)更快、更自動化的部署。

StackRox

StackRox Kubernetes安全平臺通過構(gòu)建、部署和運行時保護重要的應(yīng)用程序。StackRox部署在您的基礎(chǔ)設(shè)施中，并于您的DevOps工具和工作流程集成，以提供無摩擦的安全性和合規(guī)性。StackRox Policy Engine包含了數(shù)百個內(nèi)置控制，以執(zhí)行DevOps和安全最佳實踐、CIS基準和NIST等行業(yè)標準、容器和Kubernetes運行時安全的配置管理。StackRox對您的工作負載進行剖析，使您能夠?qū)ぷ髫撦d的安全性做出明智的決定。

組合使用

RKE、KubeLinter和StackRox使您能夠部署可重現(xiàn)的安全集群、可視化配置文件和訪問安全漏洞，并創(chuàng)建聲明式安全策略。接下來，我們來談?wù)勥@些應(yīng)用程序如何共同應(yīng)對安全威脅。

評估安全風險

我們先來關(guān)注一下Kubernetes的攻擊載體。微軟最近發(fā)布了一個基于MITRE ATT&CK框架的Kubernetes攻擊矩陣：

https://www.microsoft.com/security/blog/2020/04/02/attack-matrix-kubernetes/

該框架針對Kubernetes進行了調(diào)整，并基于真實世界的觀察和案例。幸運的是，存在一些策略可以緩解所有不同的問題。首先，我們可以從hardening我們的Kubernetes控制平面開始。之后，我們將把重點轉(zhuǎn)移到保護我們運行的容器工作負載的安全上。

控制平面Hardening

Kubernetes控制平面包括以下組件：

• Kubernetes API Server

• kube-scheduler

• kube-controller-manager

• etcd (如果適用)

• cloud-controller-manager (如果適用)

etcd將可能在控制平面節(jié)點上，但是它也可以為高可用用例提供一個遠程環(huán)境。cloud-controller-manager也安裝在提供程序?qū)嵗小?/p>

Kubernetes API Server

Kubernetes REST API server是control-plane的核心組件。該server處理REST API的調(diào)用，這些調(diào)用包含不同組件和用戶之間的所有通信。該依賴項使得保障API Server的安全成為人們最關(guān)心的問題。在此前的K8S版本中，只要升級到較新的版本就可以修復一些特定的漏洞。然而，你也可以控制以下hardening任務(wù)：

• 啟用基于角色控制訪問（RBAC）

• 確保所有API流量是TLS加密的

• 啟用審計日志

• 為所有K8S API客戶端設(shè)置身份驗證

借助諸如RKE等開發(fā)工具，可以很輕松地設(shè)置這種聲明式格式的集群。以下是一個默認的RKE config.yml.file代碼段。從中可以看到，我們能夠默認啟用審計日志、TLS（在Kubernetes組件之間）以及RBAC。

 1. kube-api:
   
 2.  image: ""
  
 3. extra_args: {}
    
 4. extra_binds: []
   
 5. extra_env: []
    
 6. win_extra_args: {}
   
 7. win_extra_binds: []
   
 8. win_extra_env: []
    
 9. service_cluster_ip_range: 10.43.0.0/16
   
 10. service_node_port_range: ""
   
 11. pod_security_policy: false
   
 12. always_pull_images: false
   
 13. secrets_encryption_config: null
   
 14. audit_log: null
   
 15. admission_configuration: null
   
 16. event_rate_limit: null
 17. …
 18. authentication:
  
 19. strategy: x509
  
 20. sans: []
 
 21. webhook: null
 22. …
 23. authorization:
  
 24. mode: rbac
 
 25. options: {}

為所有的K8S API客戶端設(shè)置身份驗證是當前面臨的挑戰(zhàn)。我們需要應(yīng)用一個零信任的模型到運行在我們集群中的工作負載上。

kube-scheduler

Kubernetes的默認scheduler是可插拔的。因此你可以構(gòu)建你的scheduler或者為不同的工作負載設(shè)置多個scheduler。不管哪種實現(xiàn)方式，都需要保證安全。以下這些任務(wù)可以確保它是安全的：

• 設(shè)置與API Server通信的安全端口

• 確保scheduler以最低要求的權(quán)限運行（RBAC）

• 限制kube-scheduler pod規(guī)范和kubeconfig文件的文件權(quán)限

通過RKE，我們可以通過驗證默認的scheduler地址(設(shè)置為127.0.0.1)來保證其與API server的連接。另外，通過確保根用戶擁有scheduler YAML文件來限制文件權(quán)限。

stat -c %U:%G /etc/kubernetes/manifests/kube-scheduler.yaml

kube-controller-manager

Kubernetes系統(tǒng)調(diào)節(jié)器，即kube-controller-manager，是一個使用核心控制循環(huán)調(diào)節(jié)系統(tǒng)的守護進程。保護controller的安全，需要采取與scheduler類似的策略：

• 設(shè)置一個與API Server通信的安全端口

• 確保scheduler以最低所需權(quán)限運行（RBAC）

• 限制kube-controller-manager pod規(guī)范和kubeconfig文件的文件權(quán)限

和scheduler一樣，我們可以確保通信使用本地地址（而不是不安全的loopback接口），并確保根用戶擁有controller YAML文件。

stat -c %U:%G /etc/kubernetes/manifests/kube-controller-manager.yaml

etcd

控制平面的最后一個核心組件是它的鍵值存儲，etcd。所有的Kubernetes對象都位于etcd中，這意味著你所有的配置文件和密鑰都存儲在這里。最好的做法是使用單獨的密鑰管理解決方案（如Hashicorp Vault或云提供商的密鑰管理服務(wù)）來加密密鑰或管理密鑰信息。當你管理數(shù)據(jù)庫時，需要記住以下關(guān)鍵因素：

• 限制對數(shù)據(jù)庫的讀/寫訪問

• 加密

我們希望將manifest的任何更新或更改限制在允許訪問的服務(wù)上。使用RBAC控制與零信任模型相結(jié)合將可以幫助你入門。最后，使用etcd加密可能很麻煩?；诖耍琑ancher有一個獨特的方法，即在初始集群配置中生產(chǎn)密鑰。Kubernetes有類似的策略，盡管帶有密鑰的文件也需要安全。企業(yè)的安全要求將決定你在何處以及如何保護敏感信息。

Cloud-controller-manager

對于云提供商而言，云的cloud-controller-manager是獨一無二的，同時它對于需要集群與提供程序API通信的發(fā)行版來說也是獨有的。與云提供商一起使用時，管理員將無法訪問其集群的主節(jié)點，因此將無法運行此前提到的hardening步驟。

使用Kubernetes原生控件保護工作負載安全

既然我們的控制平面的安全已經(jīng)得到保障，那么是時候研究一下我們在Kubernetes中運行的應(yīng)用程序了。與此前的部分類似，讓我們把安全拆分為以下幾個部分：

• 容器鏡像安全

• 運行時

• 持久化

• 網(wǎng)絡(luò)

• 基于角色的訪問控制（RBAC）

在以下部分，我們將深入探討每個部分的各種注意事項。

容器鏡像安全

在使用容器之前對其進行管理是采用容器的第一個障礙。首先，我們需要考慮：

• 基本鏡像的選擇

• 更新頻率

• 非必要軟件

• 可訪問的構(gòu)建/CI工具

最重要的是選擇安全的基礎(chǔ)鏡像，限制不必要的包并保障鏡像倉庫安全?，F(xiàn)在，大部分鏡像倉庫都有內(nèi)置的鏡像掃描工具，可以輕松地確保安全。StackRox Kubernetes安全平臺可以在與底層基礎(chǔ)操作系統(tǒng)（OS）鏡像分離的鏡像層中自動執(zhí)行可用于啟動容器并識別安全問題（包括漏洞和有問題的程序包）的鏡像。

如果你想了解更多，可以訪問以下鏈接查看相關(guān)文章：

https://www.stackrox.com/post/2020/04/container-image-security-beyond-vulnerability-scanning/

Runtime

運行時安全跨越不同的Kubernetes功能，核心目標是確保我們的工作負載是安全的。Pod安全策略具備以下能力保護容器安全：

• Linux功能

• 容器的SELinux上下文

• 主機網(wǎng)絡(luò)和端口的使用情況

• 主機文件系統(tǒng)的使用

• 容器的用戶和groupID

請記住應(yīng)用于系統(tǒng)的零信任方法，應(yīng)該在其中設(shè)置功能，以便容器具有運行時起作用所需的最低功能。為了更好地實現(xiàn)可視化，StackRox的風險剖析會自動識別哪些容器中包含對攻擊者有用的工具，包括bash。它還會對可疑工具的使用發(fā)出告警，并監(jiān)控、檢測和警告有關(guān)運行時活動，如在容器內(nèi)執(zhí)行異常或意外的進程。

持久化

在Kubernetes中運行有狀態(tài)的工作負載會創(chuàng)建一個后門進入你的容器。通過附加存儲并可能將可執(zhí)行文件或信息提供給不應(yīng)訪問的容器，遭受攻擊的可能性會大大增加。Kubernetes的最佳實踐可以確保有狀態(tài)工作負載以所需的最小特權(quán)運行。其他注意事項包括：

• 使用命名空間作為存儲的自然邊界

• 沒有特權(quán)容器

• 使用Pod安全策略限制Pod volume訪問

StackRox通過提供動態(tài)策略驅(qū)動的準入控制作為StackRox平臺的一部分，幫助緩解這些威脅。這使企業(yè)能夠自動執(zhí)行安全策略，包括在將容器部署到Kubernetes集群之前對主機掛載的限制及其可寫性。

網(wǎng)絡(luò)訪問

由于缺乏對容器的可見性，網(wǎng)絡(luò)訪問在Kubernetes中是一個艱難的挑戰(zhàn)。默認情況下，網(wǎng)絡(luò)策略是禁用的，每個pod都可以到達Kubernetes網(wǎng)絡(luò)上的其他pod。如果沒有這個默認值，新人會很難上手。隨著企業(yè)的成熟，除了我們認為必要的流量之外，我們應(yīng)該努力鎖定所有流量。這可以使用由命名空間配置的網(wǎng)絡(luò)策略來完成，同時關(guān)注以下幾點也很重要：

• 使用命名空間作為網(wǎng)絡(luò)策略的自然邊界

• 在每個命名空間中啟用默認的拒絕策略

• 使用特定于每個 pod 所需流量的網(wǎng)絡(luò)策略

網(wǎng)絡(luò)策略的重大挑戰(zhàn)之一是可視化。StackRox通過監(jiān)控pod之間的活動網(wǎng)絡(luò)流量，自動生成和配置網(wǎng)絡(luò)策略，將通信限制在應(yīng)用程序組件運行所需的范圍內(nèi)，從而幫助防止網(wǎng)絡(luò)映射。

基于角色的訪問控制（RBAC）

RBAC是保護集群安全的核心。Kubernetes的RBAC權(quán)限是相加的，因此，RBAC唯一的漏洞是管理員或用戶授予可利用的權(quán)限。我們遇到的最常見的問題是用戶在不該有的時候擁有集群管理員權(quán)限。幸運的是，有很多RBAC最佳實踐可以幫助減少此類問題：

• 對不同類型的工作負載使用不同的服務(wù)賬戶，并應(yīng)用最小權(quán)限原則。

• 定期審核您的集群的RBAC配置。

• 對不同類型的工作負載使用不同的服務(wù)賬戶，并應(yīng)用最小權(quán)限原則。

• 避免集群管理員的過度使用

RKE集群在集群設(shè)置時使用RBAC作為默認的身份驗證選項。StackRox通過幫助企業(yè)根據(jù)最小權(quán)限原則（the least privilege principle）限制Kubernetes RBAC權(quán)限來擴展這個默認選項。我們監(jiān)控集群RBAC設(shè)置的用戶和服務(wù)賬戶，并識別集群上權(quán)限過大的賬戶。

以上就是保護云原生應(yīng)用的3款K8S原生控件分別是什么，小編相信有部分知識點可能是我們?nèi)粘９ぷ鲿姷交蛴玫降?。希望你能通過這篇文章學到更多知識。更多詳情敬請關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

文章名稱：保護云原生應(yīng)用的3款K8S原生控件分別是什么
當前URL：http://www.muchs.cn/article40/ghoeeo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供微信小程序、網(wǎng)站策劃、微信公眾號、靜態(tài)網(wǎng)站、外貿(mào)建站、品牌網(wǎng)站設(shè)計

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)