建站
咨詢
售后
建站咨詢
新聞中心
自 Kubernetes 項目啟動以來，安全性已得到了長足提高，但仍存在幾個問題。文章從控制平面入手，然后介紹工作負載和網(wǎng)絡安全，最后預測安全未來。本文列出的幾個要點有助于加固集群并提高集群應對威脅的能力。
成都創(chuàng)新互聯(lián)專注于企業(yè)成都全網(wǎng)營銷、網(wǎng)站重做改版、岳陽網(wǎng)站定制設計、自適應品牌網(wǎng)站建設、H5頁面制作、商城網(wǎng)站制作、集團公司官網(wǎng)建設、外貿(mào)網(wǎng)站建設、高端網(wǎng)站制作、響應式網(wǎng)頁設計等建站業(yè)務，價格優(yōu)惠性價比高，為岳陽等各大城市提供網(wǎng)站開發(fā)制作服務。
第一部分：控制平面
控制平面是 Kubernetes 的大腦。它全面洞察集群上運行的每一個容器和 pod，可以調(diào)度新的 pod （pod 包含對父節(jié)點擁有 root 訪問權(quán)限的容器），讀取存儲在集群中的所有私密信息。這種寶貴資產(chǎn)需要防范意外泄漏和惡意威脅：被訪問時、處于靜態(tài)時以及在網(wǎng)絡上傳輸時都要受到保護。
TLS Everywhere
凡是支持 TLS 以防止流量嗅探、驗證服務器身份以及（對于相互 TLS 而言）驗證客戶端身份的每個組件，都應該啟用 TLS。
請注意：某些組件和安裝方法可能會啟用基于 HTTP 的本地端口，管理員應該熟悉每個組件的設置，以識別可能不安全的流量。
LucasK?ldstr?m 繪制的這個網(wǎng)絡圖演示了理想情況下運用 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
啟用最小權(quán)限的 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 策略是一種安全威脅。保持最小權(quán)限，不斷審查和改進 RBAC 規(guī)則，應被視為是“技術(shù)債務衛(wèi)生”的一部分，團隊應納入到開發(fā)生命周期中。
Audit Logging（1.10 版中的 beta）在有效載荷（比如請求和響應）和元數(shù)據(jù)級別提供了可定制的 API 日志。日志級別可根據(jù)貴企業(yè)的安全策略加以調(diào)整——GKE 提供了合理的默認設置幫助你上手。
對于 get、list 和 watch 等讀取請求，只有請求對象保存在審計日志中，響應對象不保存。對于涉及 Secret 和 ConfigMap 等敏感數(shù)據(jù)的請求，只導出元數(shù)據(jù)。對于其他所有請求，請求對象和響應對象都保存在審計日志中。
不要忘記：萬一受到危及，將這些日志保存在集群中是一種安全威脅。與其他所有安全敏感日志一樣，應將這些日志傳輸?shù)郊和饷?，以防萬一泄密時被人篡改。
對 API 服務器使用第三方驗證
在整個企業(yè)集中驗證和授權(quán)機制（即單次登錄）有助于為用戶配置和取消資源，并授予一致的權(quán)限。
將 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)和私密數(shù)據(jù)的信息，它是 Kubernetes 的一個關鍵組件，保護它的方式應該有別于集群的其他部分。
對 API 服務器的 etcd 的寫訪問相當于獲得整個集群上的 root 權(quán)限，連讀取訪問都可以用來很輕松地提升權(quán)限。
Kubernetes 調(diào)度程序?qū)⒃?etcd 中搜索沒有節(jié)點的 pod 定義。然后，它將找到的 pod 發(fā)送到可用的 kubelet 進行調(diào)度。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)網(wǎng)，總是存在后來被利用的風險。以最小權(quán)限運行工作負載并加強運行時配置有助于降低這一風險。
使用Linux安全功能
和PodSecurityPolicies
Linux 內(nèi)核有許多重疊的安全擴展（功能、SELinux、AppArmor 和 seccomp-bpf），它們經(jīng)配置后可為應用程序提供最小權(quán)限。
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 服務器，包括安全配置文件、特權(quán)標志以及主機網(wǎng)絡、進程或 IPC 命名空間的共享。
這些指令很重要，因為它們有助于防止容器化進程脫離隔離邊界，Tim Allclair 的示例 PodSecurityPolicy（https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0）是個綜合資源，你可以根據(jù)自己的用例來定制。
靜態(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 用戶的身份運行容器
經(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)核功能控制），但可以使用服務來掩蓋這個事實。在該示例中，虛構(gòu)的 MyApp 應用程序綁定到容器中的端口 8443，但是該服務通過代理請求到 targetPort，在端口 443 上提供它：
- kind:Service
- apiVersion:v1
- metadata:
- name:my-service
- spec:
- selector:
- app:MyApp
- ports:
- -protocol:TCP
- port:443
- targetPort:8443
必須以非 root 用戶的身份運行工作負載這一點在用戶命名空間可用之前不會改變。
使用網(wǎng)絡策略
默認情況下，Kubernetes 網(wǎng)絡允許所有 pod 到 pod 的流量，可以使用網(wǎng)絡策略（https://kubernetes.io/docs/concepts/services-networking/network-policies/）對此進行限制。
圖4
傳統(tǒng)服務用防火墻加以限制，防火墻為每個服務使用靜態(tài) IP 和端口范圍。由于這些 IP 很少變化，因此歷來用作一種身份。容器很少有靜態(tài) IP，它們是為了快速失效（fail fast）、快速重新調(diào)度，并使用服務發(fā)現(xiàn)而不是靜態(tài) IP 地址。這些屬性意味著，防火墻配置和檢查起來難多了。
由于 Kubernetes 將其所有系統(tǒng)狀態(tài)存儲在 etcd 中，它可以配置動態(tài)防火墻，前提是它得到 CNI 網(wǎng)絡插件的支持。Calico、Cilium、kube-router、Romana 和 Weave Net 都支持網(wǎng)絡策略。
值得一提的是，這些策略一失效就關閉，所以這里缺少 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 網(wǎng)絡策略無法應用于 DNS 名稱。這是由于 DNS 可解析針對多個 IP 的輪詢，或者基于呼叫 IP 動態(tài)解析，所以網(wǎng)絡策略只能應用于固定 IP 或 podSelector（針對動態(tài) Kubernetes IP）。
最佳實踐是先拒絕命名空間的所有流量，然后逐漸添加路由，允許應用程序通過其許可測試套件。這可能變得很復雜，于是 ControlPlane 結(jié)合了 netassert（https://github.com/controlplaneio/netassert），這是面向 DevSecOps 工作流程的網(wǎng)絡安全測試框架，擁有高度并行化的 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)絡上被阻止的特定測試有助于防止意外的錯誤配置。
掃描鏡像，運行 IDS
Web 服務器給它們連接的網(wǎng)絡帶來了攻擊面：掃描鏡像的已安裝文件可確保沒有已知的漏洞，因而攻擊者無法鉆漏洞的空子、遠程訪問容器。IDS（入侵檢測系統(tǒng)）可檢測攻擊者是否在鉆空子。
Kubernetes通過一系列準入控制器（https://kubernetes.io/docs/admin/admission-controllers/）門卡允許pod進入集群，這些門卡應用于 pod 及其他資源（比如部署）。這些門卡可以驗證每個 pod，決定是否準入或更改內(nèi)容，現(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/）等工具可以存儲鏡像元數(shù)據(jù)，針對容器的獨特簽名（內(nèi)容可尋址哈希）不斷進行合規(guī)和漏洞檢查。這意味著掃描擁有該哈希的容器鏡像與掃描生產(chǎn)環(huán)境中部署的鏡像一樣，可以持續(xù)地執(zhí)行，不需要訪問生產(chǎn)環(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)的入口點。
展望未來
安全界“云原生演化”的下一個階段看起來是服務網(wǎng)格（service mesh），不過可能一段時間后才會采用。遷移需要將復雜性從應用程序轉(zhuǎn)移到網(wǎng)格基礎設施，企業(yè)組織熱衷于了解最佳實踐。
圖6
運行服務網(wǎng)絡
服務網(wǎng)格是加密持久的連接組成的網(wǎng)絡，是在 Envoy 和 Linkerd 等高性能“跨斗”（sidecar）代理服務器之間建立起來的。它增加了流量管理、監(jiān)控和策略，這一切無需更改微服務。
有了 Linkerd（https://linkerd.io/），已經(jīng)可以將微服務的安全和網(wǎng)絡代碼卸載到一組共享的、久經(jīng)測試的庫，谷歌、IBM 和 Lyft 推出的 Istio（https://istio.io/）在這個領域增加了另一種方案。
由于添加了面向每個pod加密身份的 SPIFFE（https://spiffe.io/）以及其他眾多功能（https://istio.io/docs/concepts/what-is-istio/overview.html），Istio 有望簡化部署下一代網(wǎng)絡安全的工作。
在“零信任”網(wǎng)絡中，不需要傳統(tǒng)的防火墻或 Kubernetes 網(wǎng)絡策略，因為每一次交互都基于 mTLS（相互TLS）進行，確保雙方不僅安全通信，而且兩種服務的身份都已知道。
對于奉行傳統(tǒng)安全理念的人來說，從傳統(tǒng)網(wǎng)絡到云原生安全原則的這種轉(zhuǎn)變并不容易，而SPIFFE 的 Evan Gilman 撰寫的《零信任網(wǎng)絡》（https://amzn.to/2Gg6Pav）一書清楚地介紹了這個嶄新的領域，強烈推薦讀一讀。
Istio 0.8 LTS 已過時，該項目正迅速接近 1.0 版本。其穩(wěn)定版本控制與 Kubernetes 模型一樣：一個穩(wěn)定的核心，各個 API 在各自的 alpha/beta 穩(wěn)定命名空間下自報身份。預計 Istio 的采用率在今后幾個月會有所上升。
結(jié)束語
云原生應用程序有一組更精細的輕量級安全基元，為工作負載和基礎設施確保安全。這些工具的強大功能和靈活性有利也有弊；由于自動化程度不足，更容易暴露允許突破容器或其隔離模型的不安全的工作負載。
現(xiàn)在可供使用的防御工具比以往更多，但須謹慎行事，減小攻擊面和錯誤配置的可能性。
然而，如果安全減慢了企業(yè)組織交付功能的步伐，安全永遠不會成為“一等公民”。將持續(xù)交付原則運用于軟件供應鏈讓企業(yè)組織得以實現(xiàn)合規(guī)、持續(xù)審計和強制治理，又不影響公司的賬本底線。
如果得到全面測試套件的支持，安全方面快速迭代最容易。這可以通過持續(xù)安全（Continuous Security）來實現(xiàn)——這是時間點滲透測試之外的替代方案，持續(xù)的流水線驗證確保企業(yè)組織的攻擊面已知，風險不斷被理解和管理。
【原創(chuàng)稿件，合作站點轉(zhuǎn)載請注明原文作者和出處為.com】
當前文章：Kubernetes用戶的安全寶典：被黑和不被黑的11個途徑
新聞來源：http://fisionsoft.com.cn/article/dhjgiod.html
