【51CTO.com原創(chuàng)稿件】自 Kubernetes 項目啟動以來，安全性已得到了長足提高，但仍存在幾個問題。文章從控制平面入手，然后介紹工作負載和網絡安全，最后預測安全未來。本文列出的幾個要點有助于加固集群并提高集群應對威脅的能力。

第一部分：控制平面

控制平面是 Kubernetes 的大腦。它全面洞察集群上運行的每一個容器和 pod，可以調度新的 pod （pod 包含對父節(jié)點擁有 root 訪問權限的容器），讀取存儲在集群中的所有私密信息。這種寶貴資產需要防范意外泄漏和惡意威脅：被訪問時、處于靜態(tài)時以及在網絡上傳輸時都要受到保護。

TLS Everywhere

凡是支持 TLS 以防止流量嗅探、驗證服務器身份以及（對于相互 TLS 而言）驗證客戶端身份的每個組件，都應該啟用 TLS。

請注意：某些組件和安裝方法可能會啟用基于 HTTP 的本地端口，管理員應該熟悉每個組件的設置，以識別可能不安全的流量。

LucasK?ldstr?m 繪制的這個網絡圖演示了理想情況下運用 TLS 的一些地方：在主節(jié)點上的每個組件之間以及 Kubelet 和 API 服務器之間。

Kelsey Hightower堪稱典范的《Kubernetes The Hard Way》（https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/1.9.0/docs/04-certificate-authority.md）提供了詳細的手冊說明，etcd的安全模型（https://coreos.com/etcd/docs/latest/op-guide/security.html）文檔也是如此。

圖1

自動擴展 Kubernetes 節(jié)點向來很難，因為每個節(jié)點都需要 TLS 密鑰才能連接到主節(jié)點，而將私密信息嵌入到基本鏡像不是好的做法。Kubelet TLS 引導（https://medium.com/@toddrosner/kubernetes-tls-bootstrapping-cf203776abc7）讓新的 kubelet 能夠創(chuàng)建證書簽名請求，以便引導時生成證書。

圖2

啟用最小權限的 RBAC，禁用 ABAC

并監(jiān)控日志

基于角色的訪問控制（RBAC）為用戶訪問資源提供了細粒度的策略管理，比如訪問命名空間。

圖3

自版本 1.6 以來，Kubernetes 的 ABAC（基于屬性的訪問控制）已被 RBAC 取代，不應在 API 服務器上啟用。請改用 RBAC：

--authorization-mode=RBAC

或者使用該標志在 GKE 中禁用它：

--no-enable-legacy-authorization

有好多關于為集群服務設置 RBAC 策略的典型案例以及好多文檔。此外，還可以使用 audit2rbac，從審計日志提取細粒度的 RBAC 策略。

萬一 pod 受到危及，不正確或過于寬松的 RBAC 策略是一種安全威脅。保持最小權限，不斷審查和改進 RBAC 規(guī)則，應被視為是“技術債務衛(wèi)生”的一部分，團隊應納入到開發(fā)生命周期中。

Audit Logging（1.10 版中的 beta）在有效載荷（比如請求和響應）和元數據級別提供了可定制的 API 日志。日志級別可根據貴企業(yè)的安全策略加以調整——GKE 提供了合理的默認設置幫助你上手。

對于 get、list 和 watch 等讀取請求，只有請求對象保存在審計日志中，響應對象不保存。對于涉及 Secret 和 ConfigMap 等敏感數據的請求，只導出元數據。對于其他所有請求，請求對象和響應對象都保存在審計日志中。

不要忘記：萬一受到危及，將這些日志保存在集群中是一種安全威脅。與其他所有安全敏感日志一樣，應將這些日志傳輸到集群外面，以防萬一泄密時被人篡改。

對 API 服務器使用第三方驗證

在整個企業(yè)集中驗證和授權機制（即單次登錄）有助于為用戶配置和取消資源，并授予一致的權限。

將 Kubernetes 與第三方驗證提供商（比如谷歌或 Github）整合起來使用遠程平臺的身份保證（輔以雙因子驗證即 2FA 等機制），因而管理員無需重新配置 Kubernetes API 服務器以添加或刪除用戶。

Dex（https://github.com/coreos/dex）是 OpenID Connect Identity（OIDC）和 OAuth 2.0 提供商，帶可插入式連接件。

Pusher 借助一些自定義工具使這更進了一步，另外有一些幫助程序（https://github.com/micahhausler/k8s-oidc-helper）可使用，但用例稍有不同。

分離你的 etcd 集群

etcd 存儲關于狀態(tài)和私密數據的信息，它是 Kubernetes 的一個關鍵組件，保護它的方式應該有別于集群的其他部分。

對 API 服務器的 etcd 的寫訪問相當于獲得整個集群上的 root 權限，連讀取訪問都可以用來很輕松地提升權限。

Kubernetes 調度程序將在 etcd 中搜索沒有節(jié)點的 pod 定義。然后，它將找到的 pod 發(fā)送到可用的 kubelet 進行調度。API 服務器將已提交的 pod 寫到 etcd 之前，負責對這些 pod 進行驗證，所以直接寫到 etcd 的惡意用戶可以繞過許多安全機制，比如 PodSecurityPolicies。

應為 etcd 配置對等體（peer）和客戶端 TLS 證書，部署在專用節(jié)點上。為了防范 worker 節(jié)點上的私鑰被竊取和使用，集群也可以通過防火墻與 API 服務器隔開。

輪換加密密鑰

一個安全最佳實踐是定期輪換加密密鑰和證書，以便限制密鑰泄密的“影響范圍”。

Kubernetes 將通過現(xiàn)有登錄信息到期失效時創(chuàng)建新的 CSR 來自動輪換一些證書（尤其是 kubelet 客戶端和服務器的證書）。

然而，API 服務器用于加密 etcd 值的對稱加密密鑰并不自動輪換，它們得手動輪換。為此需要訪問主節(jié)點，所以托管服務（比如 GKE 或 AKS）讓操作員無需操心該問題。

第二部分：工作負載

由于控制平面上的最小可行安全，集群得以安全地運行。但是就像輪船載有可能危險的貨物一樣，輪船集裝箱必須受到保護，以便發(fā)生不測時里面的貨物完好無損。

對于 Kubernetes 工作負載（pod、部署、作業(yè)和集合等）來說，也是如此，它們可能在部署時受到信任，但如果它們面向互聯(lián)網，總是存在后來被利用的風險。以最小權限運行工作負載并加強運行時配置有助于降低這一風險。

使用Linux安全功能

和PodSecurityPolicies

Linux 內核有許多重疊的安全擴展（功能、SELinux、AppArmor 和 seccomp-bpf），它們經配置后可為應用程序提供最小權限。

bane（https://github.com/genuinetools/bane）之類的工具有助于生成 AppArmor 配置文件，docker-slim（https://github.com/docker-slim/docker-slim#quick-seccomp-example）有助于生成 seccomp 配置文件，但要注意：驗證運用這些策略的副作用時，需要一套全面的測試來測試應用程序中的所有代碼路徑。

PodSecurityPolicies（https://kubernetes.io/docs/concepts/policy/pod-security-policy/）可用于強制使用安全擴展及其他 Kubernetes 安全指令。它們提供了 pod 必須履行的最基本合約才能提交到 API 服務器，包括安全配置文件、特權標志以及主機網絡、進程或 IPC 命名空間的共享。

這些指令很重要，因為它們有助于防止容器化進程脫離隔離邊界，Tim Allclair 的示例 PodSecurityPolicy（https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0）是個綜合資源，你可以根據自己的用例來定制。

靜態(tài)分析 YAML

在 PodSecurityPolicies 拒絕訪問 API 服務器的情況下，靜態(tài)分析也可用于開發(fā)工作流程，以模擬企業(yè)組織的合規(guī)需求或風險偏好。

敏感信息不應存儲在 pod 類型的 YAML 資源（部署、pod 和集合）中，敏感的配置映射和私密信息應使用 vault、git-crypt、sealed secrets 或云提供商 KMS 來進行加密。

YAML 配置的靜態(tài)分析可用于為運行時安全性建立一條基線。kubesec（https://kubesec.io/）為資源生成風險評分：

{ 
"score": -30, 
"scoring": { 
"critical": [{ 
"selector": "containers[]  .securityContext .privileged == true", 
"reason": "Privileged  containers can allow almost completely unrestricted host access" 
    }], 
"advise": [{ 
"selector": "containers[]  .securityContext .runAsNonRoot == true", 
"reason": "Force  the running image to run as a non-root user to ensure least privilege" 
    }, { 
"selector": "containers[]  .securityContext .capabilities .drop", 
"reason": "Reducing  kernel capabilities available to a container limits its attack surface", 
"href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" 
    }] 
  } 
} 

而 kubetest（https://github.com/garethr/kubetest）是 Kubernetes 配置的單元測試框架：

#// vim: set ft=python: 
deftest_for_team_label(): 
if spec["kind"] =="Deployment": 
        labels = spec["spec"]["template"]["metadata"]["labels"] 
assert_contains(labels, "team", "should indicate which team owns the deployment") 
test_for_team_label() 

這些工具“向左移”（在開發(fā)周期的早期移動檢查和驗證）。開發(fā)階段的安全測試為用戶提供了可能被后來的手動或自動檢查拒絕的代碼和配置方面的快速反饋，可以減小引入更安全的實踐帶來的阻力。

以非 root 用戶的身份運行容器

經常以 root 的身份運行的容器通常擁有比工作負載實際要求多得多的權限，萬一受到危及，會幫助攻擊者進一步發(fā)動攻擊。

容器仍依賴傳統(tǒng)的 Unix 安全模型（名為自主訪問控制或 DAC），一切都是文件，權限授給用戶和用戶組。

用戶命名空間在 Kubernetes 中并未啟用。這意味著容器的用戶 ID 表映射到主機的用戶表，以 root 用戶的身份在容器內運行進程就是在主機上以 root 身份運行它。雖然我們有分層安全機制來防止容器突破（container breakout），但仍不推薦以 root 的身份在容器內運行。

許多容器鏡像使用 root 用戶來運行 PID 1，如果該進程受到危及，攻擊者擁有容器的 root 權限，任何錯誤配置會變得極容易被利用。

Bitnami 已做了大量的工作將容器鏡像移動到非 root 用戶（尤其是由于 OpenShift 默認需要這樣），這可以簡化遷移到非 root 容器鏡像。

這個 PodSecurityPolicy 代碼片段可防止以 root 的身份在容器內運行進程，并防止權限提升到 root：

# Required to prevent escalations to root. 
allowPrivilegeEscalation:false 
runAsUser: 
# Require the container to run without root privileges. 
rule:'MustRunAsNonRoot' 

非 root 容器無法綁定到 1024 以下的特權端口（這由 CAP_NET_BIND_SERVICE 內核功能控制），但可以使用服務來掩蓋這個事實。在該示例中，虛構的 MyApp 應用程序綁定到容器中的端口 8443，但是該服務通過代理請求到 targetPort，在端口 443 上提供它：

kind:Service 
apiVersion:v1 
metadata: 
name:my-service 
spec: 
selector: 
app:MyApp 
ports: 
-protocol:TCP 
port:443 
targetPort:8443 

必須以非 root 用戶的身份運行工作負載這一點在用戶命名空間可用之前不會改變。

使用網絡策略

默認情況下，Kubernetes 網絡允許所有 pod 到 pod 的流量，可以使用網絡策略（https://kubernetes.io/docs/concepts/services-networking/network-policies/）對此進行限制。

圖4

傳統(tǒng)服務用防火墻加以限制，防火墻為每個服務使用靜態(tài) IP 和端口范圍。由于這些 IP 很少變化，因此歷來用作一種身份。容器很少有靜態(tài) IP，它們是為了快速失效（fail fast）、快速重新調度，并使用服務發(fā)現(xiàn)而不是靜態(tài) IP 地址。這些屬性意味著，防火墻配置和檢查起來難多了。

由于 Kubernetes 將其所有系統(tǒng)狀態(tài)存儲在 etcd 中，它可以配置動態(tài)防火墻，前提是它得到 CNI 網絡插件的支持。Calico、Cilium、kube-router、Romana 和 Weave Net 都支持網絡策略。

值得一提的是，這些策略一失效就關閉，所以這里缺少 podSelector 默認情況下用通配符：

apiVersion:networking.k8s.io/v1 
kind:NetworkPolicy 
metadata: 
name:default-deny 
spec: 
podSelector: 

下面這個示例 NetworkPolicy 拒絕除 UDP 53（DNS）之外的所有出站流量，這還阻止入站連接到你的應用程序。NetworkPolicies 是有狀態(tài)的（https://www.weave.works/blog/securing-microservices-kubernetes/），所以出站請求的回復仍抵達應用程序。

apiVersion:networking.k8s.io/v1 
kind:NetworkPolicy 
metadata: 
name:myapp-deny-external-egress 
spec: 
podSelector: 
matchLabels: 
app:myapp 
policyTypes: 
-Egress 
egress: 
-ports: 
-port:53 
protocol:UDP 
-to: 
-namespaceSelector:{} 

Kubernetes 網絡策略無法應用于 DNS 名稱。這是由于 DNS 可解析針對多個 IP 的輪詢，或者基于呼叫 IP 動態(tài)解析，所以網絡策略只能應用于固定 IP 或 podSelector（針對動態(tài) Kubernetes IP）。

最佳實踐是先拒絕命名空間的所有流量，然后逐漸添加路由，允許應用程序通過其許可測試套件。這可能變得很復雜，于是 ControlPlane 結合了 netassert（https://github.com/controlplaneio/netassert），這是面向 DevSecOps 工作流程的網絡安全測試框架，擁有高度并行化的 nmap：

k8s:# used for Kubernetes pods 
deployment:# only deployments currently supported 
test-frontend:# pod name, defaults to `default` namespace 
test-microservice:80# `test-microservice` is the DNS name of the target service 
test-database:-80# `test-frontend` should not be able to access test-database’s port 80 
169.254.169.254:-80,-443# AWS metadata API 
metadata.google.internal:-80,-443# GCP metadata API 
new-namespace:test-microservice:# `new-namespace` is the namespace name 
test-database.new-namespace:80# longer DNS names can be used for other namespaces 
test-frontend.default:80 
169.254.169.254:-80,-443# AWS metadata API 
metadata.google.internal:-80,-443# GCP metadata API 

云提供商元數據 API 歷來是提升權限的來源（最近的 Shopify 漏洞懸賞表明了這點），因此證實 API 在容器網絡上被阻止的特定測試有助于防止意外的錯誤配置。

掃描鏡像，運行 IDS

Web 服務器給它們連接的網絡帶來了攻擊面：掃描鏡像的已安裝文件可確保沒有已知的漏洞，因而攻擊者無法鉆漏洞的空子、遠程訪問容器。IDS（入侵檢測系統(tǒng)）可檢測攻擊者是否在鉆空子。

Kubernetes通過一系列準入控制器（https://kubernetes.io/docs/admin/admission-controllers/）門卡允許pod進入集群，這些門卡應用于 pod 及其他資源（比如部署）。這些門卡可以驗證每個 pod，決定是否準入或更改內容，現(xiàn)在它們支持后端 web 鉤子（webhook）。

圖5

容器鏡像掃描工具可以使用這些 Web 鉤子在鏡像部署到集群之前驗證鏡像，可以拒絕未通過檢查的鏡像準入。

掃描容器鏡像查找已知漏洞可以縮短攻擊者鉆已披露的 CVE 空子的時間窗口。應該在部署流水線中使用免費工具，比如 CoreOS 的 Clair（https://github.com/coreos/clair）和 Aqua 的 Micro Scanner（https://github.com/aquasecurity/microscanner），防止部署存在嚴重漏洞的鏡像。

Grafeas（https://grafeas.io/）等工具可以存儲鏡像元數據，針對容器的獨特簽名（內容可尋址哈希）不斷進行合規(guī)和漏洞檢查。這意味著掃描擁有該哈希的容器鏡像與掃描生產環(huán)境中部署的鏡像一樣，可以持續(xù)地執(zhí)行，不需要訪問生產環(huán)境。

未知的零日漏洞將始終存在，所以應在 Kubernetes 中部署入侵檢測工具，比如 Twistlock（https://www.twistlock.com/）、Aqua（https://www.aquasec.com/）和 Sysdig Secure（https://sysdig.com/product/secure/）。IDS 可檢測容器中的異常行為，暫?；蚪K止容器。Sysdig 的 Falco 是一種開源規(guī)則引擎（https://github.com/draios/falco），是這個生態(tài)系統(tǒng)的入口點。

展望未來

安全界“云原生演化”的下一個階段看起來是服務網格（service mesh），不過可能一段時間后才會采用。遷移需要將復雜性從應用程序轉移到網格基礎設施，企業(yè)組織熱衷于了解最佳實踐。

圖6

運行服務網絡

服務網格是加密持久的連接組成的網絡，是在 Envoy 和 Linkerd 等高性能“跨斗”（sidecar）代理服務器之間建立起來的。它增加了流量管理、監(jiān)控和策略，這一切無需更改微服務。

有了 Linkerd（https://linkerd.io/），已經可以將微服務的安全和網絡代碼卸載到一組共享的、久經測試的庫，谷歌、IBM 和 Lyft 推出的 Istio（https://istio.io/）在這個領域增加了另一種方案。

由于添加了面向每個pod加密身份的 SPIFFE（https://spiffe.io/）以及其他眾多功能（https://istio.io/docs/concepts/what-is-istio/overview.html），Istio 有望簡化部署下一代網絡安全的工作。

在“零信任”網絡中，不需要傳統(tǒng)的防火墻或 Kubernetes 網絡策略，因為每一次交互都基于 mTLS（相互TLS）進行，確保雙方不僅安全通信，而且兩種服務的身份都已知道。

對于奉行傳統(tǒng)安全理念的人來說，從傳統(tǒng)網絡到云原生安全原則的這種轉變并不容易，而SPIFFE 的 Evan Gilman 撰寫的《零信任網絡》（https://amzn.to/2Gg6Pav）一書清楚地介紹了這個嶄新的領域，強烈推薦讀一讀。

Istio 0.8 LTS 已過時，該項目正迅速接近 1.0 版本。其穩(wěn)定版本控制與 Kubernetes 模型一樣：一個穩(wěn)定的核心，各個 API 在各自的 alpha/beta 穩(wěn)定命名空間下自報身份。預計 Istio 的采用率在今后幾個月會有所上升。

結束語

云原生應用程序有一組更精細的輕量級安全基元，為工作負載和基礎設施確保安全。這些工具的強大功能和靈活性有利也有弊；由于自動化程度不足，更容易暴露允許突破容器或其隔離模型的不安全的工作負載。

現(xiàn)在可供使用的防御工具比以往更多，但須謹慎行事，減小攻擊面和錯誤配置的可能性。

然而，如果安全減慢了企業(yè)組織交付功能的步伐，安全永遠不會成為“一等公民”。將持續(xù)交付原則運用于軟件供應鏈讓企業(yè)組織得以實現(xiàn)合規(guī)、持續(xù)審計和強制治理，又不影響公司的賬本底線。

如果得到全面測試套件的支持，安全方面快速迭代最容易。這可以通過持續(xù)安全（Continuous Security）來實現(xiàn)——這是時間點滲透測試之外的替代方案，持續(xù)的流水線驗證確保企業(yè)組織的攻擊面已知，風險不斷被理解和管理。

【51CTO原創(chuàng)稿件，合作站點轉載請注明原文作者和出處為51CTO.com】