保護云原生應用的3款K8S原生控件分別是什么

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

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

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

工具介紹

Rancher Kubernetes Engine(RKE)

RKE是一個經過CNCF認證的Kubernetes發行版，可以在Docker容器內完整運行。它通過移除大多數的主機依賴項并提供一個部署、升級和回滾的穩定路徑，解決了Kubernetes安裝過于復雜的問題。RKE使用聲明式YAML文件來配置和創建Kubernetes環境。這可以實現可重現的本地或遠程環境。

KubeLinter

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

StackRox

StackRox Kubernetes安全平臺通過構建、部署和運行時保護重要的應用程序。StackRox部署在您的基礎設施中，并于您的DevOps工具和工作流程集成，以提供無摩擦的安全性和合規性。StackRox Policy Engine包含了數百個內置控制，以執行DevOps和安全最佳實踐、CIS基準和NIST等行業標準、容器和Kubernetes運行時安全的配置管理。StackRox對您的工作負載進行剖析，使您能夠對工作負載的安全性做出明智的決定。

組合使用

RKE、KubeLinter和StackRox使您能夠部署可重現的安全集群、可視化配置文件和訪問安全漏洞，并創建聲明式安全策略。接下來，我們來談談這些應用程序如何共同應對安全威脅。

評估安全風險

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

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

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

控制平面Hardening

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

• Kubernetes API Server

• kube-scheduler

• kube-controller-manager

• etcd (如果適用)

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

etcd將可能在控制平面節點上，但是它也可以為高可用用例提供一個遠程環境。cloud-controller-manager也安裝在提供程序實例中。

Kubernetes API Server

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

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

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

• 啟用審計日志

• 為所有K8S API客戶端設置身份驗證

借助諸如RKE等開發工具，可以很輕松地設置這種聲明式格式的集群。以下是一個默認的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客戶端設置身份驗證是當前面臨的挑戰。我們需要應用一個零信任的模型到運行在我們集群中的工作負載上。

kube-scheduler

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

• 設置與API Server通信的安全端口

• 確保scheduler以最低要求的權限運行（RBAC）

• 限制kube-scheduler pod規范和kubeconfig文件的文件權限

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

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

kube-controller-manager

Kubernetes系統調節器，即kube-controller-manager，是一個使用核心控制循環調節系統的守護進程。保護controller的安全，需要采取與scheduler類似的策略：

• 設置一個與API Server通信的安全端口

• 確保scheduler以最低所需權限運行（RBAC）

• 限制kube-controller-manager pod規范和kubeconfig文件的文件權限

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

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

etcd

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

• 限制對數據庫的讀/寫訪問

• 加密

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

Cloud-controller-manager

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

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

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

• 容器鏡像安全

• 運行時

• 持久化

• 網絡

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

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

容器鏡像安全

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

• 基本鏡像的選擇

• 更新頻率

• 非必要軟件

• 可訪問的構建/CI工具

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

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

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

Runtime

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

• Linux功能

• 容器的SELinux上下文

• 主機網絡和端口的使用情況

• 主機文件系統的使用

• 容器的用戶和groupID

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

持久化

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

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

• 沒有特權容器

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

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

網絡訪問

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

• 使用命名空間作為網絡策略的自然邊界

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

• 使用特定于每個 pod 所需流量的網絡策略

網絡策略的重大挑戰之一是可視化。StackRox通過監控pod之間的活動網絡流量，自動生成和配置網絡策略，將通信限制在應用程序組件運行所需的范圍內，從而幫助防止網絡映射。

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

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

• 對不同類型的工作負載使用不同的服務賬戶，并應用最小權限原則。

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

• 對不同類型的工作負載使用不同的服務賬戶，并應用最小權限原則。

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

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

以上就是保護云原生應用的3款K8S原生控件分別是什么，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。