Kubernetes安全加固的一些實用建議

Posted on by

前言

隨著更多的組織開始擁抱雲原生技術，Kubernetes已成為容器編排領域的行業標準。向 Kubernetes轉變的這股潮流，很大程度上簡化瞭容器化應用程序的部署、擴展和管理，並實現瞭自動化，為傳統的單體式系統提供瞭勝於傳統管理協議的眾多優勢。

然而，管理大規模的Kubernetes帶來瞭一系列獨特挑戰，包括加固集群、保護供應鏈以及運行時檢測威脅。本文結合雲原生計算基金會（CNCF）、美國國傢安全局（NSA）以及網絡安全和基礎設施安全局（CISA）的諸多最佳實踐，整理出Kubernetes安全加固的6個建議，幫助組織降低風險。

集群設置和加固

保護Kubernetes環境從加固集群開始。對於使用托管Kubernetes服務（比如GKE、EKS或AKS）的用戶而言，由相應的雲提供商管理主節點安全，並為集群實施各種默認安全設置。GKE Autopilot采取瞭額外措施，實施GKE加固準則和GCP安全最佳實踐。但即使對於GKE Standard或EKS/AKS用戶而言，雲提供商也有一套準則，以保護用戶對Kubernetes API服務器的訪問、對雲資源的容器訪問以及Kubernetes升級。

準則如下：

  • GKE加固指南

  • EKS安全最佳實踐指南

  • AKS集群安全

至於自我管理的Kubernetes集群（比如kube-adm或kops），kube-bench可用於測試集群是否符合CIS Kubernetes Benchmark中規定的安全準則。主要的建議包括：加密存儲在靜態etcd中的機密信息、使用TLS證書保護控制平面通信以及開啟審計日志功能。

網絡和資源策略

默認情況下，Kubernetes允許從任何pod到同一集群中另一個pod的通信。雖然這對於發現服務而言很理想，但沒有提供網絡分離，不法分子或中招的系統可以無限制地訪問所有資源。如果團隊使用命名空間作為Kubernetes內部多租戶的主要手段，這就成為非常嚴重的問題。

為瞭控制pod、命名空間和外部端點之間的流量，應使用支持NetworkPolicy API的CNI插件（比如Calico、Flannel或針對特定雲的CNI），用於網絡隔離。遵照零信任模型，最佳實踐是實施默認一概拒絕的策略，阻止所有出入流量，除非另一項策略特別允許。

除瞭網絡策略外，Kubernetes還提供兩個資源級別的策略：LimitRange和ResourceQuotas。LimitRanges可用於限制單個資源的使用（如每個pod最多有2個CPU），而ResourceQuota控制聚合資源的使用（如在dev命名空間中總共有20個CPU）。

RBAC和服務賬戶

強大的網絡和資源策略到位後，下一步是強制執行RBAC授權以限制訪問。Kubernetes管理員可以對用戶和用戶組強制執行RBAC以訪問集群，以及限制服務訪問集群內外的資源（如雲托管的數據庫）。另外，企業使用創建時掛載到每個pod的默認服務賬戶時須謹慎。pod可能被授予過大的權限，這取決於授予默認服務賬戶的權限。如果不需要與Kubernetes服務進行任何特定的通信，將automountServiceAccountToken設置為false，以防止掛載。

系統加固

鑒於集群已安全，下一步是盡量縮小系統的攻擊面。這適用於節點上運行的操作系統以及容器上的內核。選擇為運行容器而優化的專用操作系統，如AWS Bottlerocket或GKE COS，而不是選擇通用的Linux節點。接下來，充分利用Linux內核安全功能，如SELinux、AppArmor（自1.4起是測試版）及/或seccomp（自1.19起是穩定版）。AppArmor為Linux用戶或用戶組定義瞭將程序限制於一組有限資源的權限。一旦定義瞭AppArmor配置文件，帶有AppArmor標註的pod將強制執行這些規則。

apiVersion:   v1
kind:   Pod
metadata:
        name: apparmor
        annotations:
                 container.apparmor.security.beta.kubernetes.io/hello:   localhost/k8s-apparmor-example-deny-write
spec:
        containers:
        - name: hello
            image: busybox
            command: [ "sh", "-c", "echo 'Hello   AppArmor!' && sleep 1h" ]

另一方面，Seccomp限制容器的系統調用。隻要底層Kubernetes節點上有seccomp配置文件可用，就可以在securityContext這部分定義seccomp配置文件。

apiVersion: v1
kind: Pod
metadata:
  name: audit-pod
  labels:
        app: audit-pod
spec:
  securityContext:
        seccompProfile:
                 type: Localhost
                 localhostProfile: profiles/audit.json
  containers:
  - name: test-container
       image: hashicorp/http-echo:0.2.3
       args:
        - "-text=just made some syscalls!"

即使沒有seccomp配置文件，用戶仍然可以限制容器免受各種權限提升攻擊。在安全上下文中，Kubernetes允許配置容器是否可以以特權或root身份來運行，或者將權限升級到root。用戶還可以限制hostPID、hostIPC、hostNetwork和hostPaths。所有這些設置都可以通過Pod Security Policy（v1.21中已被棄用）或使用其他開源工具（比如K-Rail、Kyverno和OPA/Gatekeeper）來執行。

最後，如果需要額外的安全保證，可以配置自定義的RuntimeClass，以便充分利用硬件虛擬化（如gVisor或Kata）。在節點層面定義RuntimeClass，並在pod定義部分指定它。

apiVersion:   node.k8s.io/v1 # RuntimeClass is defined in the node.k8s.io API group
kind:   RuntimeClass
metadata:
  name: myclass # The name the RuntimeClass   will be referenced by
  # RuntimeClass is a non-namespaced resource
handler:   myconfiguration # The name of the corresponding CRI configuration
---
apiVersion:   v1
kind:   Pod
metadata:
  name: mypod
spec:
  runtimeClassName: myclass

供應鏈安全

即使集群和系統安全，為保證整個應用程序的端到端安全，也必須考慮到供應鏈。若是內部開發的應用程序，請遵循創建容器的最佳實踐，即使用最小基礎鏡像以減小攻擊面、固定軟件包版本，並使用多階段構建以創建小鏡像。此外，定義容器運行所需的非root用戶，或使用podman構建無root容器，以限制root訪問。

下一步，使用開源工具（如Trivy、Clair或Anchore）或者商用工具掃描所有鏡像，以查找漏洞。一些工具還允許對鏡像進行簽名和驗證簽名，以確保容器在構建和上傳過程中未被篡改。最後，定義Kubernetes可以使用ImagePolicyWebhook或上面提到的任何策略執行工具從中提取鏡像的白名單註冊表。

監控、日志和運行時安全

至此，我們有瞭一個供應鏈嚴加保護的安全集群，可以生成幹凈的、經過驗證的鏡像，有限的訪問權限。然而環境是動態的，安全團隊需能夠響應運行環境中的事件。首先，將readOnlyRootFilesystem設置為true，並將tmp日志文件存儲到emptyDir，以此確保容器在運行時不變。除瞭典型的應用程序監控（如Prometheus/Grafana）或日志（如EFK）存儲外，還可以使用Falco或Sysdig來分析系統調用進程和Kubernetes API日志。

這兩種工具都可以在運行時解析來自內核的Linux系統調用，並在違反規則時觸發警報。示例規則包括：權限提升時發出警報，已知目錄上檢測到讀/寫事件時發出警報，或調用shell時發出警報。最後，將Kubernetes API審計日志與現有日志聚合和警報工具整合起來，以監控集群中的所有活動。這包括API請求歷史記錄、性能指標、部署、資源消耗、操作系統調用和網絡流量。

總結

由於雲原生系統很復雜，需要采用多層方法來保護Kubernetes環境。建議Kubernetes做好雲原生安全的4C：雲、集群、容器和代碼。首先，加固集群，並遵循雲安全最佳實踐；其次，嚴加保護容器，減小攻擊面，限制訪問，並確保運行時不變；再次，保護供應鏈，分析代碼和容器以查找漏洞。最後，監控運行時的所有活動，將防禦機制融入Kubernetes內運行的每一層軟件中。

推薦閱讀：