共計 5483 個字符，預計需要花費 14 分鐘才能閱讀完成。
本篇文章給大家分享的是有關保護云原生應用的 3 款 K8S 原生控件分別是什么，丸趣 TV 小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著丸趣 TV 小編一起來看看吧。
隨著越來越多的企業開始采用容器技術，他們正在面臨一個重大挑戰——如何保護容器應用程序的安全？比起存儲、網絡和監控，安全常常是一個被積壓已久的問題。再加上需要對員工進行 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.yamlkube-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.yamletcd
控制平面的最后一個核心組件是它的鍵值存儲，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 原生控件分別是什么，丸趣 TV 小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注丸趣 TV 行業資訊頻道。
