\h終極指\h\h\h如何保護\h流水終極指Kubernetes安全防如何保護Kubernetes流水保護容器部署安全的重要意 Kubernetes的運行機 Kubernetes漏洞和攻擊載 保護整個流水 CI/CD生產線安全防 Kubernetes節(jié)點生產準 Kubernetes運行時容器安全防 Kubernetes系統和資源安全防 Kubernetes環(huán)境的審核與合規(guī)——安全態(tài) Kubernetes安全防護自動化——這可能嗎 開源Kubernetes安全防護工 運行時Kubernetes安全防護檢查清 2借助容器和Kubernetes等工具，企業(yè)能夠在應用程序部署的諸多方面實現自動化，繼而獲更麻煩的是，公有云中的Kubernetes等新型工具和技術以及托管容器服務本身就將為攻擊企業(yè)的重要資產提供可乘之機。繼近期Kubernetes的\h中間人漏洞和\hTesla\h漏洞事件之后，CI/CD流水線引入的漏洞。開源組件的大量運用和不斷涌現\h攻擊面擴大。Kubernetes和Docker自動化安全防護才能滿足發(fā)展需要。以往的安全防護模型和工具無法應對不斷變化KubernetesPod從出現到消失可能只有幾分鐘甚至幾秒的時間?？赡馨戮W絡連接的應用程序行為必須即時納入強制安全策略中。我們需要通過新一代自動化安全工具來保護容器安全，在流水線前期聲明安全策略，并通過代碼形式進行管理。KUBERNETES團隊對正在部署的KubernetesPod是否具有可見性？例如，是否了解應用程序團隊能否確定每個Pod當內部服務Pod或容器開始在內部掃描端口或嘗試隨機連接外部網絡時，團隊如何團隊如何確定攻擊者是否已經在容器、Pod團隊能否像對于非容器化部署一樣全面查看和檢查網絡連接？例如7如果面臨潛在攻擊，團隊能否監(jiān)控Pod團隊是否曾通過檢查Kubernetes團隊是否擁有鎖定Kubernetes服務、訪問控制(RBAC)如果具備合規(guī)策略，如何在運行時執(zhí)行以確保合規(guī)性？例如，確保內部Pod通信加密，當Pod未使用加密通道時團隊將如何得知？在對應用程序通信進行故障排除或記錄取證數據時，如何定位相關Pod并抓取日志？這篇指南將重點圍繞自動化運行時安全防護，介紹如何實現Kubernetes首先必須要了解Kubernetes的運行機制和Kubernetes如果還不熟悉\hKubernetesKubernetes是一種能夠自動化部署、更新和監(jiān)控容器的編排工具。RedHatOpenShifrEMSESe等所有主流容器管理和云平臺全部支持KubernetesKubernetes相關概念：主節(jié)點：管理Kubernetes工作節(jié)點集群和在節(jié)點上部署Pod的服務器。節(jié)點可以其他Kubernetes組件。POD：Kubernetes中的部署和可尋址性單元。每個Pod都擁有獨立的IP地址，其服務：為其底層Pod和請求充當代理的服務功能，可在各復制Pod之間進行負載均衡。服務還可通過定義外部IP或節(jié)點端口來為一個或多個Pod提供外部訪問端點。Kubernetes也提供DNS服務、路由程序和負載均衡器。用于管理Kubernetes集群的主要組件包括API服務器、Kubelet和etcd。Kubernetes支持基于瀏覽器的管理控制臺——Kubernetes（可選）。以上所有組件都是潛在的攻擊目標。例如，\hTesla\h漏洞事件就是一個未被保護的Kubernetes控制臺被攻擊，進而被安裝了挖礦軟件。KUBERNETESKubernetes基于角色的訪問權限控制(RBAC)可實現資源的精細化管理。它能夠提供對應用程序工作負載和Kubernetes系統資源的訪問權限。OpenShift等管理工具可以添加其他功能，但需要依賴或使用原生Kubernetes基本安全控制。通過妥善配置訪問權限控制來防止未經授權訪問API服務器或應用程序工作負載等Kubernetes組件的行為至關重要。KUBERNETESKubernetes的主要網絡連接概念是：為每個Pod分配獨立的可路由IP地址。（實際上是其網絡插件）Po。Pod的外部訪問權限可通過服務、負載均衡器或入口控制器來提供，Kubernetes會將其路由至相應的Pod。Kubernetes使用iptables來控制Pod（和節(jié)點）之間的網絡連接，以及處理大量的網絡連接和端口轉接規(guī)則。這樣一來，客戶就不需要追蹤連接至Kubernetes服務的IP地址。而且，由于各個Pod都有獨立的IP地址，并且其容器能夠偵聽原生端口，因此端口映射得到了OverlayKubernetes動態(tài)處理，所以監(jiān)控網絡流量的難度極大，安全防護更是難上加難。以下是Kubernetes網絡連接運行方式的示例。PODPODPODsrc:dst:

RoutingRouting/24via1dev1dev

src:dst:RoutingRouting/24via0dev3devtunI0:

eth0:IPIPtunnel:IPIPtunnel:src:dst:上圖所示為數據包在不同節(jié)點的Pod之間遍歷的方式。示例中使用的是CalicoCNI網絡插件。每個網絡插件對于PodIP地址(IPAM)的分配、iptables規(guī)則和跨節(jié)點網絡連接的配置當CNI網絡插件收到來自Kubernetes的容器部署通知時，它負責指派IP地址，并在節(jié)點上配置相應的iptables和路由規(guī)則。Pod1會使用Pod2的IP或Pod2的服務IP作為目標位置向Pod2發(fā)送一個數據包（圖中使用的是Pod2的IP。如果使用服務IP，則kube-proxy會執(zhí)行負載均衡和DNAT，并將目標IP轉換為遠程Pod的IP。如果目標位置是相同節(jié)點上的本地Pod，則數據包將直接被轉發(fā)至PodOverlay網絡還是三層網絡路由機在上圖中，數據包被發(fā)送至IPIP隧道接口，并通過IPIP遠程節(jié)點上的路由表會將數據包路由至目標位置Pod2在路由、NAT（可能進行）違規(guī)連接都極其困難。Kubernetes針對Pod上運行的Kubernetes容器發(fā)起的攻擊可能來自外部網絡，也可能來自內部人員，134east- 6Pod134east- 6POD數據外泄：攻擊者往往通過多種手段實現數據竊取，其中可能包括在連接至命令與控制服務器的Pod上設置反shell，以及通過網絡隧道來隱藏保

WORKER入侵容器文件系統：攻擊者可能通過安裝存在漏洞的庫/數據包來攻擊容器，也可能修改敏感文件。攻擊完成之后，可能會嘗試權限升級或其他突破方式。入侵工作節(jié)點：DirtyCowLinux內核漏洞升級至root權限

準備攻擊手 攻 命令與控偵 實

安 外的攻擊。但主機安全防護工具必須具有Kubernetes和容器意識，以確保全面覆蓋。例如，新的主機可以動態(tài)進入Kubernetes集群，并且必須包含由Kubernetes管理除了上述威脅載體，攻擊者還可能嘗試入侵KubernetesAPI服務器或控制臺等部署工具，從而獲取機密，或接管正在運行的Pod的控制權限。針對KUBERNETES器的訪問權限，黑客也可能嘗試攻擊API服務器或Kubelets等Kubernetes資源。例如，在對Tesla的攻擊中，黑客攻陷了一個不受保護的控制通過盜取/盜用API服務器令牌或冒充授權用戶身權。Kubernetes發(fā)布了可通過Kubelet、etcd訪問權限或服務令牌實現的多種權限升級機以Kubernetes中間人漏洞為例，這是一種相對較新的惡意安全防護問題，已經引起安全專家的廣泛關注，但更多問題還將繼續(xù)涌現。針對這類漏洞，攻擊者可以利用內置服務定義，通過一種不常用的渠道——外部IP發(fā)起中間人攻擊。\hCI/CD流水線 持續(xù)性容器安全防 持續(xù)性容器安全防 構 交 運 準 生 Docker階段眾多，沒有一款工具可以面面俱到?？偟貋碚f，RedHatOpenShift、DockerEE、SUSERancher、SUSECaaS和AWSEKS平臺可提供針對構建、交付和預部署階段的安全防護工具和功能，而一些獨立的安全服務供應商可提供包含運行時安全防護的端到端工具。運行時安全防護工具必須善于檢測和抵御基于網絡和容器發(fā)起的復雜攻擊。本指南稍后將總結一些開源容器安全防護項目。CI/CD應在CI/CD生產線中盡早集成安全防護措施，多數企業(yè)選擇在開發(fā)者構建容器鏡像的階段著手。在鏡像進入生產線的下一階段之前，開發(fā)者通過即時掃描可以確定是否存在必須修復的重大漏洞或違規(guī)。技術和流程方面都有一些值得思考的問題，比如：如何在生產線中執(zhí)行和觸發(fā)掃描？Jenkins等多數工具都具有能夠觸發(fā)掃描的插件或在要求修復時應當采用什么標準？這種標準是否基于嚴重（CVSS分數閾值較高）對違規(guī)是否應設置寬限期和/或例外情況（豁免）？除了在CI/CDKubernetes部署應用程序容器之前，應鎖定Kubernetes工作節(jié)點的主機系統。下面介紹的是鎖定主機限制Linux啟用采用配置使用R/O裝運行CIS在暫存和生產環(huán)境中應持續(xù)對Kubernetes主機進行審核和掃描，確保在更新和擴展活動期Kubernetes運行時容器當容器在生產中運行時，三個重要的安全防護載體是：網絡篩選、容器檢查和主機安全容器防火墻是一種新型網絡安全防護產品，可針對新的云原生Kubernetes環(huán)境采取傳統網基于P網絡策略，可在部署更改和擴展時提供保護。簡單的網絡分段規(guī)則并非是為關鍵性業(yè)務容器部署提供可靠的監(jiān)控、記錄和威脅檢測，而是能夠防止一些未經授權的網絡連接。Web應用防火墻(WAF)攻擊檢測能夠采用檢測常見攻擊的方法來保護面向Web的容器（通常為基于HTTP或HTTPS的應用程序），與Web應用防火墻的功能類似。七層容器防火墻具備七層篩選和對Pod間流量的深度數據包檢測的功能，可通過使用網絡應用程序協議來保護容器安全。容器防火墻還與Kubernetes等編排工具集成，DDoS、DNS和SQL注入等通過網絡發(fā)起的常見應用程序攻擊進行內置檢測，從而實施保護。容器深度包檢測(DPI)技術對于容器防火墻的深度網絡安全防護必不可少。入侵通常使用可預測的攻擊載體：標頭格式錯誤的惡意HTTP請求，或包含在可擴展標記語言(XML)對象中的可執(zhí)行shell命令。基于DPI的七層檢測能夠尋找并發(fā)現這些攻擊方式。針對每一次Pod連鑒于容器和Kubernetes網絡連接模型的動態(tài)性質，傳統的網絡可見性、取證和分析工具均無法使用。為調試應用程序或調查安全防護事件進行的抓包等任務也不再簡單。需要Kubernetes和具有容器意識的工具來執(zhí)行網絡安全防護、檢查和取證任務。網絡攻擊者經常使用特權升級和惡意進程來發(fā)起攻擊或擴散。針對Linux內核漏洞（DirtyCow）檢查容器進程和文件系統活動以及檢測可疑行為是容器安全防護的重要組成部分。端口掃描和反向shell或特權升級等可疑進程都應被檢測出來。應當將內置檢測與基準行為學習流程相結合，從而基于以往的活動發(fā)現反常進程。如果容器化應用程序采用的是微服務設計原則，即容器中的每個應用程序都具備少量功能，并且僅使用必須的數據包和庫來構建容器，則將大大簡化對可疑進程和文件系統活動的檢測，并提高準確度。如果運行容器的主機（Kubernetes工作節(jié)點）被入侵，可能導致一系列不良后果，包括：root特權升主機資源被破壞或劫持（例如挖礦軟件API服務器或Docker對于容器來說，需要對主機系統中的這些可疑活動進行監(jiān)控。因為容器能像主機一樣運行操作系統和應用程序，所以監(jiān)控容器進程和文件系統活動需要與監(jiān)控主機相同的安全防護功能。將網絡檢查、容器檢查和主機安全防護相結合是通過多種威脅載體檢測殺傷鏈的最佳方法。Kubernetes系統和資源如果得不到保護，Kubernetes等編排工具和基于其構建的管理平臺都將面臨攻擊威脅。這會導致容器部署暴露此前不存在的新潛在攻擊面，從而難以抵御黑客的入侵。\hTesla\h以及\hKubelet\h被攻擊事件為新技術在未來陷入攻擊和更新補丁反復拉鋸的循環(huán)拉開了序幕。為了幫助Kubernetes和管理平臺抵御攻擊，針對系統資源妥善配置RBAC非常重要。為確保護API服務器。為API服務器配置RBAC或手動創(chuàng)建防火墻規(guī)則，杜絕未經授權的限制KUBELET權限。為Kubelets配置RBAC并管理證書輪換，保護Kubelet安對所有外部端口要求身份驗證。 總地來說，應仔細審核所有基于角色的訪問權限控制。例如，應審核具有集群管理員角色的服務帳戶，并限制其僅可訪問必要位置。Kubernetes部署基礎設施抵御攻擊。不過也建議使用監(jiān)控工具來追蹤對基礎設施服務的訪問，以檢測未經授權的連接嘗試和潛在攻擊。以TeslaKubernetes控制臺遭到的攻擊為例，一旦工作節(jié)點的訪問權限被攻陷，黑客即可創(chuàng)建與中國的外部連接，用于控制挖礦軟件。對容器、主機、網絡和系統資源實施基于策略的實時監(jiān)控能夠檢測到可疑進程和未經授權的外部連接。Kubernetes隨著Kubernetes等容器技術和工具的快速發(fā)展，企業(yè)將不斷對容器環(huán)境進行更新、升級和遷移。運行一系列專為Kubernetes環(huán)境設計的安全測試將確保安全防護不會在每次更改后業(yè)向容器遷移，基礎設施、工具和拓撲的變化也可能需要對PCI好在針對Kubernetes和Docker環(huán)境，可通過Kubernetes和DockerBench測試的CIS基準執(zhí)行一系列全面的安全態(tài)勢檢查。應將定期運行這些測試和確認預計結果的流程自Kubernetes安全DockerRBAC此外，鏡像掃描應包含與鏡像安全防護相關的CIS基準測試。其他鏡像合規(guī)測試也能檢查鏡像是否存在嵌入式機密和文件訪問(setuid/setgid)違規(guī)。注冊表和生產中的鏡像和容器漏洞掃描也是防御已知攻擊和滿足合規(guī)性的核心組成部分。掃描可以整合到構建流程和CI/CD在生產中，應當對運行的容器和主機定期進行漏洞掃描。但漏洞掃描不足以提供容器運行時部署所需的多個安全防護載體。編排和容器管理工具雖然具備基本的RBAC和基礎設施安全防護功能，但它們并非專門的安全防護工具。關鍵性的業(yè)務部署仍然需要專業(yè)的Kubernetes安全防護工具。具體來說，需要一種安全防護解決方案，能夠解決涵蓋三種主要安全載體（網絡、容器和主機）的安全問題。NEUVECTOR是一款高度集成的自動化KUBERNETES安全防護解決方案，具節(jié)點服務節(jié)點節(jié)點服務通過CIS安全基準滿足合規(guī)性和審計NeuVector解決方案本身就是一個容器，KubernetesOpenShift、SUSERancher、DockerEE、IBMCloud、SUSECaaS、EKS等任何其他編排系統進行部署和更新。NeuVector可將安全防護的起點左移至CI/CD生產線構建階段。容器鏡像構建能夠觸發(fā)漏洞掃描，并將在發(fā)現重大漏洞時放棄構建?？梢砸箝_發(fā)者在修復這些漏洞之后才能準許鏡像通過構建階段，并存儲在經過審核的注冊表中。NeuVectorJenkins、CircleCI、AzureDevOpsGitlab等所有常見的生產線工具，并且還為任何其他使用中的構建工具提供了RESTAP。NeuVector會持續(xù)掃描已審核的注冊表中的鏡像是否存在新的漏洞。在構建階段或注冊表鏡像掃描過程中，除了提供分層掃描結果，還會針對CIS基準、檢測到的機密和文件訪問權限違規(guī)運行額外的合規(guī)性檢查。（包括PCI、HIPAA、GDPR、NIST等），以及報告漏洞修復進展在將NeuVector部署到各個工作節(jié)點之后，容器網絡連接和服務依存關系將一目了然。隔離和保護Kubernetes部署的安全防護策略將自動創(chuàng)建。NeuVector如何為KubernetesNeuVector能夠自動發(fā)現和可視化運行中的Pod及無論針對容器的攻擊來自內部還是外部，NeuVector都能夠檢測和攔截。r火墻可在監(jiān)控（網絡tap）模式下運行，也可運行保護（內聯）KubernetesPodNeuVector借助內置的端口掃描和反向shell等可疑進程檢測功能，能夠檢測出任何容器中的反?；顒?。此外，各容器中正在運行的進程都將被用來制定基準，為檢測未經授權的或惡意的進程提供協助。NeuVector還將監(jiān)控容器文件系統中的可疑活動。例如，在安裝或更新數據包或庫時，NeuVector將自動觸發(fā)漏洞掃描，并生成告警。NeuVector會監(jiān)控主機系統中的特權升級等攻擊。在容器中檢測出的可疑進程在主機上運行時也將被檢測。例如，NeuVector能夠檢測到端口掃描或反向shell進程開始運行，并發(fā)出告警。而且，NeuVector還能夠學習已允許在主機上運行的進程并建立白名單，并攔截任何嘗試啟動的未經授權的主機進程。NeuVector也會監(jiān)控系統容器以及各容器的網絡活動。Kubernetes和OpenShift網絡連接如下圖所示。NeuVector會自動掃描運行中的Pod、容器和工作節(jié)點的漏洞，并在各個節(jié)點上運行KubernetesCIS基準測試，還將對系統容器和編排平臺（例如Kubernetes1.19）進行漏洞掃描。NeuVector還可在構建和交付階段（檢查鏡像注冊表）以及在CI/CD自動化生產線中執(zhí)行漏洞掃描，并提供Jenkins集成，從而能夠在鏡像構建過程中進行掃描。Kubernetes安全防護自動化——隨著DevOps團隊向容器和Kubernetes的應用程序自動化部署全速前進，安全防護自動化勢在必行?，F在的安全防護團隊已經今非昔比，再也不可能隨時叫停或放緩應用程序、基礎設施或者在新云上的部署。安全防護自動化首先要為運行中的容器創(chuàng)建安全的基礎設施和平臺，之后是自動化運行時安全防護。利用Terraform等基礎設施即代碼概念和工具可確保獲得具有可重復安全配置的安全基礎設施。通過將行為學習和Kubernetes與自定義資源定義(CRD)相結合實現的\h安全即代碼，多數運行時安全防護都能實現自動化。最初可能始終需要一些手動設置或自定義，但當開啟生產開KubernetesPod時，安全防護即可自動化進行，并能隨著部署的情況進行調整和擴展。安全即代碼運行截安全即代碼運行截 Kubernetesyaml√√√√√√進出、DLP√RBAC√Kubernetes執(zhí)行CRD√支持開放策略代理(OPA)NeuVectorKubernetes全防護。將Kubernetes容器防火墻與容器檢查和主機安全防護相結合，能夠檢測和阻止殺傷鏈中的破壞性攻擊活動。憑借先進的公有云架構，NeuVector能夠以容器形式在鄰近應用程序容器的位置輕松完成自身部署，提供始終開啟和持續(xù)運行的安全防護。由于容器化應用程序的聲明式特點，以及Kubernetes等工具的豐富集成選擇，即使在高度動態(tài)化的容器環(huán)境中也可以執(zhí)行高級安全控制。通過與Kubernetes集成，并整合多項行為學習和多載體安全防護功能，可以實現\h整個\h生產線的安全防護自動化，從而滿足關鍵性Kubernetes業(yè)務部署的迫切需求。對于容器基礎設施來說，滿足行業(yè)標準的合規(guī)性要求并非易事。這些新的虛擬化層還未經過審計人員和合規(guī)顧問審查，在合規(guī)性要求方面尚未達成共識。NeuVector能夠助力達成\hPCI、\hGDPR、\hSOC2、HIPAA和\hNIST等標準的合規(guī)性要求，遵循網絡分段和建立防火墻。憑借專門設計用于容器和Kubernetes網絡篩選及保護的七層容器防火墻，NeuVector堪稱滿足這項要求的絕佳選擇。漏洞掃描和修復。通過端到端漏洞管理，NeuVector可在從構建階段到生產的整個審核配置測試。通過KubernetesCIS基準等合規(guī)性檢查來審查和執(zhí)行系統（主機限制訪問權限控制。評估和授予所需的最低級別用戶訪問特權能夠降低發(fā)生RBAC攻加密和敏感數據保護。NeuVector可確保流動數據的連接加密，甚至能使用DLP技NeuVector可針對容器部署的PCI、GDPR、HIPAA和NIST合規(guī)性提供可自定義的預配NeuVector通過將可自定義的合規(guī)性報告、端到端漏洞管理、防火墻構建和網絡分段以及合規(guī)性測試相結合，成功幫助眾多企業(yè)的全新云原生基礎設施和工作負載達成了合規(guī)性要求，涵蓋從PCI和GDP，到服務組織控制(SOC)2類審計等多項標準。SOC2是一項審計規(guī)程，旨在確保服務提供商（應用程序）以安全的方式管理數據，從而保護組織的利益及其用戶的隱私。對于注重安全性的企業(yè)而言，在考慮SaaS提供商時，滿足SOC2合規(guī)性是最起碼的要求。所有在云端存儲客戶信息的互動式技術服務組織都必須滿足SOC2合規(guī)性。這類企業(yè)會在提供SaaS和其他云服務期間使用云來存儲相應的互動客戶NeuVector