近年來，雲原生的發展可謂迅猛，據Gartner分析，到2025年，超過85%的企業將接受雲優先原則，超過95%的新數字工作負載將被部署在雲原生平台上。但其實，雲原生不僅是一項技術，也是一種服務、一種思維方式。就國內企業而言，雲原生目前的接受程度如何？全新的架構體系帶來了哪些新的安全風險？本期話題就圍繞雲原生下的安全威脅與挑戰，就相關問題展開討論。
1.無論是容器、微服務架構、持續性交付等方面，現有技術條件下的雲原生帶來了哪些新的攻擊面？構建雲原生應當遵頊哪些安全原則？
其實題幹上也說了一部分，容器運行時、容器編排平台、微服務架構Web應用、服務網格、Serverless，這些都是比較主要的攻擊面。
雲原生因面向微服務架構、基於API的特點，決定了傳統以終端或主機層安全防護策略需要向以容器為主要載體的微服務轉移，成為安全防護的重點；應用風險威脅或者數據泄漏需要關注API安全。
雲原生注重敏捷持續交付，在DevOps過程中每一個環節都要考慮安全因素，對安全的需求和要求也提高了，安全左移的成熟度直接決定了雲原生下能否具有安全屬性的業務。
引入的應用或者系統越多，出現漏洞的可能性越大的，不管是配置錯誤還是應用漏洞。上雲呢運維便捷了很多，但是配置不當的話造成的影響也會更大，因為相當於一個核心系統。
安全部門的工作一方面是維持正常運轉，另一方面就是發現潛在風險點。像前面說到的配置錯誤更像是潛在風險點，發不發現完全看攻擊者能力。
Q：雲原生內以Docker為例進行容器運行時存在哪些安全問題？
容器安全的風險點主要從幾個方面去考慮吧：鏡像安全風險、鏡像倉庫安全風險、編排工具安全風險、容器運行安全風險、容器主機安全風險。
之前在FreeBuf看到過一篇講Docker容器安全性分析的文章，把可能存在的技術性安全風險分為鏡像安全風險、容器虛擬化安全風險、網絡安全風險等類型，可以參考一下。
說到鏡像，使用Docker的新手很可能會創建不安全的鏡像，攻擊者很容易藉此接管容器，一個是用了過時或者不安全的基礎鏡像，裡面往往一堆漏洞；一個是啟動的應用程序以 root 用戶身份運行，這樣攻擊者一旦利用漏洞取得Shell 權限，就可以接管 Docker 守護程序所運行的主機；一個是如果鏡像包含CURL、APT等工具，一旦攻擊者獲得了某種訪問權，就可以通過這些工具加載惡意軟件。
Q: 雲原生編排組件為何存在非管理員賬戶提權風險?
首先要明確，是編排工具自身漏洞導致非管理員賬戶提權，舉個例子：CVE-2018-1002105，這是一個Kubernetes的權限提升漏洞，攻擊者可在擁有集群內低權限的情況下提升至Kubernetes API Server權限；通過構造一個對Kubernetes API Server的特殊請求，攻擊者能夠藉助其作為代理，建立一個到後端服務器的連接，攻擊者就能以Kubernetes API Server的身份向後端服務器發送任意請求，實現權限提升。
2. 現在不少企業在雲原生上落地還存在一定難度，這個難點在哪？雲原生對技術能力提出了哪些新要求？
根據CNCF的雲原生定義：雲原生技術有利於各組織在公有雲、私有雲和混合雲等新型動態環境中構建和運行可彈性擴展的應用，代表性的技術：容器、服務網格、微服務、不可變基礎設施和聲明式API。
現階段，大多數組織的人力架構，配不上Devops，配不上微服務，也配不上雲原生。別的不說，單元測試和自動化測試的覆蓋率有多少？從需求到研發到上線能在pineline里全完成可追溯嗎？
現在雲原生總的說來還是一個很新的概念，內含技術龐雜，對於傳統企業學習成本過高，要招到熟練這一塊的人才又很難，不太容易因地制宜、規模地應用。
說到人才，其實思路轉變才是難點，因為很多開發人員掌握的架構模型知識都是以前傳統的那一套，雲原生的技術理念還是太新了，過去傳統的開發流程慣性對運用雲原生阻力較大。現在雲原生的相關概念倒是提的不少，但是一套相對系統完善的培訓體系還是太少。
還有一個就是長期的遷移過程，比如很多企業仍然採用傳統 IDC 做基礎設施，為了實現雲原生的微服務化，整合雲端後台這些優勢服務，需要對系統進行重構。但大規模的系統遷移過程會比較漫長，期間系統是處在一種混合狀態，既有運行在容器中的微服務，也有在容器外運行的，甚至是運行在傳統非雲基礎設施上的服務。這種混合狀態會對開發和維護提出更高的挑戰，新遷移系統和遺留系統的互通，分布的遷移過程都要通過精心的設計。
雲原生是一種構建和運行應用程序的方法，是一套技術體系和方法論。雲原生（CloudNative）是一個組合詞，Cloud+Native。Cloud表示應用程序位於雲中，而不是傳統的數據中心；Native表示應用程序從設計之初即考慮到雲的環境，原生為雲而設計，在雲上以最佳姿勢運行，充分利用和發揮雲平台的彈性+分布式優勢。
總而言之，符合雲原生架構的應用程序應該是：採用開源堆棧（K8S+Docker）進行容器化，基於微服務架構提高靈活性和可維護性，藉助敏捷方法、DevOps支持持續迭代和運維自動化，利用雲平台設施實現彈性伸縮、動態調度、優化資源利用率。
3.如何判斷企業是否真的需要雲原生？現階段雲原生、微服務是概念營銷，還是能真正實現業務價值？
雲原生註定了必須是面向雲環境，以持續敏捷交付的業務才具有適用性，適合自己的方案才是最好的，傳統架構和業務並不適配雲原生。
國內現在這個階段，用處還比較有限。如果你用的是非常好的一個公有雲服務，那麼雲原生可能還是不錯的。自建的話不要自找苦吃，雲原生會成為公司後續往公有雲迅速遷移的一個梯子。
我有個做雲原生安全的朋友，他的苦惱在於，願意為安全買單的客戶都沒有雲原生。當然可能海外會有一些客戶，但是這個比例跟用雲原生但是不想買單，和願意為安全買單但是不用雲原生的海外群體比，比例肯定還是很小的。
原生雲的出現，其實是為了解決運維難的痛點，雲技術發展之後，才出現了原生雲安全的概念，其實主要就是雲的宿主這部分的安全。對企業來說，上不上雲，一是看自己需求，二是看有沒有監管要求。
雲內，根據我司的使用情況，好多手段不好用，比如全流量無法實現，比如網絡拓撲無法改變，全靠廠商。某些雲上的拓撲環境並不合理，但無法改變。既然企業要選擇上雲 那就應該把雲上安全的預算列出來，因為雲上的運維確實比自建 IDC 要方便。
本期精彩觀點到此結束啦~此外，FreeBuf會定期開展不同的精彩話題討論，想了解更多話題和觀點，快來掃碼免費申請加入FreeBuf甲方群吧！
加入即可獲得FreeBuf月刊專輯，還有更多精彩內容盡在FreeBuf甲方會員專屬社群，小助手周周送福利，社群周周有驚喜，還不趕快行動？
申請流程：掃碼申請-後台審核（2-5個工作日）-郵件通知-加入會員俱樂部
