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

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

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

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

工具介紹

Rancher Kubernetes Engine(RKE)

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

KubeLinter

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

StackRox

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

組合使用

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

評(píng)估安全風(fēng)險(xiǎn)

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

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

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

控制平面Hardening

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

• Kubernetes API Server

• kube-scheduler

• kube-controller-manager

• etcd (如果適用)

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

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

Kubernetes API Server

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

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

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

• 啟用審計(jì)日志

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

借助諸如RKE等開發(fā)工具，可以很輕松地設(shè)置這種聲明式格式的集群。以下是一個(gè)默認(rèn)的RKE config.yml.file代碼段。從中可以看到，我們能夠默認(rèn)啟用審計(jì)日志、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è)置身份驗(yàn)證是當(dāng)前面臨的挑戰(zhàn)。我們需要應(yīng)用一個(gè)零信任的模型到運(yùn)行在我們集群中的工作負(fù)載上。

kube-scheduler

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

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

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

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

通過RKE，我們可以通過驗(yàn)證默認(rèn)的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，是一個(gè)使用核心控制循環(huán)調(diào)節(jié)系統(tǒng)的守護(hù)進(jìn)程。保護(hù)controller的安全，需要采取與scheduler類似的策略：

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

• 確保scheduler以最低所需權(quán)限運(yù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

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

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

• 加密

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

Cloud-controller-manager

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

使用Kubernetes原生控件保護(hù)工作負(fù)載安全

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

• 容器鏡像安全

• 運(yùn)行時(shí)

• 持久化

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

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

在以下部分，我們將深入探討每個(gè)部分的各種注意事項(xiàng)。

容器鏡像安全

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

• 基本鏡像的選擇

• 更新頻率

• 非必要軟件

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

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

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

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

Runtime

運(yùn)行時(shí)安全跨越不同的Kubernetes功能，核心目標(biāo)是確保我們的工作負(fù)載是安全的。Pod安全策略具備以下能力保護(hù)容器安全：

• Linux功能

• 容器的SELinux上下文

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

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

• 容器的用戶和groupID

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

持久化

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

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

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

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

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

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

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

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

• 在每個(gè)命名空間中啟用默認(rèn)的拒絕策略

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

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

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

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

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

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

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

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

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

以上就是保護(hù)云原生應(yīng)用的3款K8S原生控件分別是什么，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見到或用到的。希望你能通過這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。