【51CTO.com快譯】誰都無法否認：在快速發展的DevOps和持續集成/交付領域，安全問題仍然需要大家持續關注，謹慎對待。盡管當前有許多工具和技術，可以讓我們將安全集成到現有工作流中，但是容器安全僅僅是其中的一個方面。我們仍然需要安全專家采用各種優秀實踐，來提供全方位的安全防護。

作為容器安全的防護平臺，StackRox(請參見-- https://www.stackrox.com/)最近發布的《容器和Kubernetes安全態勢報告》

(https://www.stackrox.com/kubernetes-adoption-and-security-trends-and-market-share-for-containers/)。他們向540位IT專業人員開展了，針對容器的使用和Kubernetes安全模型方面的全面調查，并發現了一些有趣的現象。

通過該報告，我們可以看出：許多公司都在使用容器技術來提高開發速度，但是為了確保不會忽略掉任何安全防范的關鍵點，他們逐漸放慢了應用的部署過程。下面，讓我們一起通過該報告，來深入解析本年度在容器安全領域的統計數據和趨勢。

引領大規模的數字化轉型

容器、Kubernetes和微服務，往往被視為快速轉化為云原生應用和創新的主要工具。許多公司正得益于將云原生應用作為數字化轉型的典型案例。

如下圖左側所示，絕大多數受訪者認為：容器與Kubernetes給其組織帶來的競爭優勢，主要體現在“更快的應用開發與發布”上。不過右側的圖告訴我們：仍有將近半數的企業持有“作壁上觀”的態度。

也就是說，有44%的受訪者(及組織)承認：曾經出于安全方面的考慮，而推遲了將應用向生產環境中部署。由于將安全集成到現有工作流中，其實并不總是那么容易的，因此這會直接延遲微服務和云原生應用的快速部署。

容器的安全威脅持續上升

根據該報告，針對云原生應用的威脅已越來越多。如下圖所示，在過去12個月中，有94%的人經歷過與容器和Kubernetes相關的安全事件。

這個數字非常驚人，尤其是當我們考慮到安全事件的影響，可能會給組織帶來的災難性的后果時。無論是簡單的數據泄露，還是諸如分布式拒絕服務(DDoS)攻擊，都可能會導致用戶對于企業應用、及其安全性的信任喪失，進而產生復合性的業務風險。

該報告還指出，大多數安全風險都是由人為錯誤而引發的，例如：錯誤地配置了云端環境或Kubernetes集群。我們可以毫不夸張地說，那些由代碼錯誤和群集配置錯誤所引起的事故數量，和已知并糾正了的漏洞數量，是不相上下的。

優先級的提高

隨著各個企業有關容器安全性風險意識的增強，受訪者門能夠持續關注容器的安全相關策略。在上一輪調查(2019年春季)中，有34%的受訪者表示他們現有的容器策略不夠詳細(請參見--

https://www.stackrox.com/post/2019/07/top-5-takeaways-from-state-of-container-and-kubernetes-security-report/)。而在本輪調查中，此項數字降到了22%。這些策略主要包括：如何保護容器化的環境，以及如何在不降低環境安全態勢的基礎上，加快部署工作的流程。

同時，從各個組織的采用程度來看，容器的安全策略正在變得越來越易于被采用。目前，有34%的受訪者將本組織的安全策略，即：那些足以緩解大多數安全威脅的高級策略，評定為中級;有14%的受訪者認為本組織的安全策略已經達到了成熟狀態。

容器應用

如前所述，容器和Kubernetes共同推動了組織的創新。目前已有越來越多的公司將其單體應用(monolithic app)及解決方案，轉化為可以充分利用云端環境的微服務中。

如下圖所示，有29%的受訪者在本企業50%以上的應用方案中采用了云原生的容器化，該占比幾乎是2018年秋季的兩倍。

如前所述，容器安全的問題會在部署和運行時集中爆發。過去，大多數開發運行環境，被設計為只在本地受限制的生態系統中運行，因此安全問題并不那么凸顯。而當各類應用在云端被部署并運行時，安全風險就變得非常突出了。

進一步的調查顯示，云服務專業人員和組織會將錯誤的配置，視為安全風險的主要原因。與之相比，各類攻擊倒并不被視為重大的安全威脅，只有12%的受訪者對此表示擔憂。同時，他們也并不認為漏洞是造成威脅的主要根源，其中只有27%的受訪者對此表示了擔憂。

該調查還顯示，原生云應用要比混合式部署更受歡迎。這意味著許多組織都有著足夠的信心，將其應用方案完全移至云端運行，而無需依賴本地與云端這種混合的部署模式。其背后的原因主要得益于：如今我們已經擁有了更加成熟的云端基礎架構。

盡管Google是Kubernetes背后的公司，但是我們發現Amazon Web Services(AWS)在容器化市場的云端基礎架構占有率方面能夠排名第一，第二名是Microsoft的Azure，而Google Cloud Platform(GCP)只能排到第三，雖然其增速已超過Azure。如下圖所示，有78%的受訪者會選擇AWS來支持他們的應用。如果您有興趣的話，請參考《Google Cloud Platform(GCP)與Amazon Web Services(AWS)在成本、易用性和優勢方面的比較》一文--

https://blog.cherre.com/2020/03/10/gcp-vs-aws/。

在AWS引領市場的同時，其編排工具也在市場上廣受歡迎。下面我們來看看目前最為流行的5種容器編排工具：

• Amazon EKS占比37%。
• 自我管理/自我托管的Kubernetes占比35%。
• Amazon ECS占比28%。
• Azure AKS占比21%。
• Google GKE占比21%。

可見，在受訪者眼中，Amazon的整體市場份額最大。Elastic Container Service(ECS)和Elastic Kubernetes Service(EKS)都以其易用性，能夠與其他Amazon服務和工具進行無縫集成。而且它們以具有競爭力的價格結構，在市場上占據了主導地位。

挑戰和措施

大家普遍認為：在順應向云原生應用和容器化微服務遷移的趨勢中，各個企業往往在將單體應用轉換為用到云計算能力的微服務時，會面臨嚴重的障礙。特別是對于Kubernetes來說，團隊內部的技能差距和陡峭的學習曲線，都會成為整個推進過程中巨大的障礙。

Kubernetes和容器的學習曲線，不同于標準的軟件工程范例。在Kubernetes項目的初期階段，企業需要尋找和雇用在云平臺上具有豐富開發經驗的人員。而在容器管理的過程中，那些涉及到的風險管理水平、以及專業的知識，同樣給企業帶來了新的挑戰。

不過可喜的是，DevOps工程師和越來越多可用的容器安全解決方案，正在幫助企業簡化保護容器和部署安全措施的整個過程。秉承著盡早實施和“安全左移”的理念，各項安全措施將會更加容易地被集成到CI/CD的管道中。

得益于云服務的發展與普及，如今各種關鍵性的安全必備功能，都能夠以托管服務的形式，提供給云原生、以及混合的應用產品。其中包括：

• 漏洞管理。
• 配置管理。
• 合規性檢查。
• 運行時威脅檢測。
• 風險分析與一般性評估。
• 可視性管理。
• 網絡細分。

如果說安全工程師和開發人員擅長與處理代碼級的安全性，那么DevOps工程師往往會負責保護目標應用，運行在云端環境和微服務中的安全。他們可以使用各種在線工具，對上述提到的各個安全功能點，持續進行日常管理和維護。

總結

StackRox發布的2020年版《容器和Kubernetes安全態勢報告》，通過各項統計數據表明，容器與Kubernetes安全性相關要點，主要體現在如下四個方面：

• Kubernetes已是大勢所趨。它不但能夠提供靈活性，還能夠圍繞著編排工具去構建的服務。各個企業通過尋找改進容器化和Kubernetes編排的方法，以提高云原生應用在開發與部署上的安全態勢。
• 容器(尤其是Kubernetes)是通用的，并且與云服務類型無關。這也是Kubernetes的最大優勢之一。只要滿足運行時的要求，您完全可以在不同的環境中部署同一組微服務。這就意味著：安全性可以是一個標準化的過程，而不是某一個案的工作流。也就是說，您可以使用相同的配置和方法，來保護任何一個Kubernetes集群。
• 安全性是一個持續的過程，而不再是駐留在CI/CD管道末端的待完成任務。也就是說，安全過程需要與CI/CD工作流的其余部分(包括：代碼檢查和部署)一起被推進。
• DevOps會起到橋梁的作用。在不久的將來，DevOps團隊會在開發伊始就引入安全方面的“布局”，并全面負責和確保整個云端環境的安全性。他們也會利用各種最佳實踐，來改善云端環境中的容器安全性。

總的說來，該報告向我們表明：DevOps團隊需要從一開始就將安全性作為至關重要的優先事項，主動引入容器安全的相關流程中，以大幅降小攻擊面，并提高云應用的整體安全性。

原標題：Container and Kubernetes Security: A 2020 Update ，作者: Stefan Thorpe 

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】