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

第一部分：控制平面

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

TLS Everywhere

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

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

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

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 引導(dǎo)（https://medium.com/@toddrosner/kubernetes-tls-bootstrapping-cf203776abc7）讓新的 kubelet 能夠創(chuàng)建證書簽名請求，以便引導(dǎo)時生成證書。

圖2

啟用最小權(quán)限的 RBAC，禁用 ABAC

并監(jiān)控日志

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

圖3

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

--authorization-mode=RBAC

或者使用該標(biāo)志在 GKE 中禁用它：

--no-enable-legacy-authorization

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

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

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

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

不要忘記：萬一受到危及，將這些日志保存在集群中是一種安全威脅。與其他所有安全敏感日志一樣，應(yīng)將這些日志傳輸?shù)郊和饷妫苑廊f一泄密時被人篡改。

對 API 服務(wù)器使用第三方驗證

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

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

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

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

分離你的 etcd 集群

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

對 API 服務(wù)器的 etcd 的寫訪問相當(dāng)于獲得整個集群上的 root 權(quán)限，連讀取訪問都可以用來很輕松地提升權(quán)限。

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

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

輪換加密密鑰

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

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

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

第二部分：工作負載

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

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

使用Linux安全功能

和PodSecurityPolicies

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

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

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

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

靜態(tài)分析 YAML

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

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

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

{ 
"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 用戶的身份運行容器

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

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

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

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

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

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

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

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

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

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

使用網(wǎng)絡(luò)策略

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

圖4

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

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

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

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

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

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 網(wǎng)絡(luò)策略無法應(yīng)用于 DNS 名稱。這是由于 DNS 可解析針對多個 IP 的輪詢，或者基于呼叫 IP 動態(tài)解析，所以網(wǎng)絡(luò)策略只能應(yīng)用于固定 IP 或 podSelector（針對動態(tài) Kubernetes IP）。

最佳實踐是先拒絕命名空間的所有流量，然后逐漸添加路由，允許應(yīng)用程序通過其許可測試套件。這可能變得很復(fù)雜，于是 ControlPlane 結(jié)合了 netassert（https://github.com/controlplaneio/netassert），這是面向 DevSecOps 工作流程的網(wǎng)絡(luò)安全測試框架，擁有高度并行化的 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 

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

掃描鏡像，運行 IDS

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

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

圖5

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

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

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

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

展望未來

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

圖6

運行服務(wù)網(wǎng)絡(luò)

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

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

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

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

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

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

結(jié)束語

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

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

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

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

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