如何应对云原生之旅中的安全挑战？
作者 |Pavan Belagatti
譯者 | 彎月
頭圖 | CSDN 下載自東方 IC
來源?| CSDN（ID：CSDNnews）
以下為譯文：
如果你已經接受了云原生計算的概念和原理，那么代表你已經處于領先地位。在當今先進且競爭激烈的IT環境中，你已經走上了正確的道路。但是，我們需要了解一件事，將開發環境和流程遷移到云原生環境是一項令人望而生畏又充滿挑戰的工作。任何人都只能建議你從單例應用程序遷移到微服務體系結構，但從哪兒遷移以及如何遷移才是需要分析的關鍵問題。
對遺留的應用程序進行現代化改造的問題比較棘手。你應該逐步解決問題，首先要對現有的應用程序進行部分或整體的容器化，此時無需采用微服務架構。但接下來，你需要逐步集成現代開發運維和云方法，例如CI/CD、自動化和可觀察性等。經過一段時間后，你需要在現有遺留應用程序/服務的基礎上添加新的微服務，或者淘汰掉代碼庫中的單例服務。但這只是邁向云原生的過程中相對比較簡單的方面，那么安全性呢？
在本文中，我們將詳細地討論云原生之旅所涉及的安全問題，以及如何解決這些問題。
云原生的起源
大約十年前，Netflix公司首次提出了“云原生”，這是一項關于云和計算的技術。這項技術推動了Netflix的發展，幫助他們從一家郵購公司發展成為了全球最受信任以及最大的消費者按需內容提供商之一。Netflix率先開發了云原生技術，并為所有軟件開發的重塑、轉型和擴展方面提供了寶貴的經驗。
Netflix借助云原生技術，更快地向客戶提供更多功能，從那時起，每家與軟件打交道的公司都希望借鑒Netflix的云原生技術。云原生能夠有效地提高業務速度，并可利用容器、Docker、Kubernetes等云原生技術提供自動化和可擴展性。
云原生之旅
云原生之旅可以歸結為三個關鍵性的決策，而這些決策都可以通過云原生得到解決。
什么是基礎設施？
基礎設施的基本要求之一是計算機必須具有彈性。此外，基礎設施還需要支持其他功能，例如可觀察性、可見性、若干托管的服務等。基礎設施是一個廣泛討論的話題，我不打算在本文中詳細討論。
選擇哪個平臺？
云原生平臺的選擇比較容易，因為基本上Kubernetes已成為運行容器化微服務的默認平臺。
如何有效，安全地運行容器化微服務？
這是一個復雜的決定，一般我會推薦Helm。Helm能夠幫助你以更簡單且可重用的方式安裝Kubernetes的服務。以上我推薦的選擇都是為了幫助開發人員專注于業務問題，而不必擔心平臺要求的負擔等。
以上就是三個你需要做出的關鍵決策，而這就是你云原生之旅的起點。
云原生是一段旅程，而不是目的地。
各個公司可以采取多個步驟來推進這段旅程。
云原生的基本原則包括可擴展的應用、彈性架構以及頻繁變更的能力。
在這段旅程中，有三個階段需要注意：
●?第一個階段：主要面向開發人員、采用容器。
●?第二個階段：主要面向開發運維、部署應用程序。
●?第三個階段：主要面向業務（端到端）、智能運營。
Vodafone 在“云原生世界”大會上展示了他們的云原生之旅。
在云原生之旅的中間，Vodafone將“為云做好準備”作為一個中間步驟。
“為云做好準備”的步驟包括向以API為中心轉變，自動化應用構建和運行，消除對操作系統的依賴，并通過API實現基礎設施即代碼（Infrastructure as a Code，即IaaC）。
Vodafone的IT方面似乎比網絡方面更成熟。大多數IT功能已經處于“為云做好準備”階段，但是重新架構VNF以實現容器化，并讓它們成為云原生是一項具有挑戰性的任務。
云原生之旅面臨的共同挑戰
保護入口點
保護網絡安全是重中之重。擁有一個VPC，使用NAT（NAT用于控制出口，確保沒有P地址、節點或對象被泄漏I）。使用RBAC，專用網絡等，為了確保每個人都無法訪問在Kubernetes集群中運行的API服務器，這些都是必需的。在Kubernetes上運行容器化微服務時，需要使用命名空間。因此，一切都可以歸結為監視和控制入口點。
指定機密數據
敏感信息非常重要，因此需要加密，因此我們需要使用機密數據。一個很好模式是在計劃或設計Helm Chart時，將機密數據放到外部。然后使用約束，約束是限制集群濫用資源的關鍵，然后還有安全上下文，它應該是一組指定的策略。最后還有網絡策略也是遏制濫用的另一種方式。
掌握微服務
如果你在選定的平臺和選定的基礎設施上運行微服務，那么可以通過Helm Chart來部署應用程序，從而掌握所有的微服務。有些Pod是單獨的，你可以在Pod中建立一個主容器和一個初始化容器，還可以運行一個sidercar。你可以為這些Pod建立多個副本，而且也可以具有依賴項。也許你需要運行一個數據庫，也許你需要在同一個集群中運行另一個微服務，而且該依賴項可能也有一個主容器和一個sidercar容器。
可觀察性
微服務是云原生架構的基礎，但是當你拆分單例應用程序時，可能會創建數十個、甚至數百個微應用程序。這些微應用程序中的每一個都需要進行觀察和監視，這是一個很大的挑戰。
由于許多微服務都涉及構建現代云原生應用程序，因此快速配置、部署、連續交付、嚴格的開發運維實踐以及整體的監視和可觀察性都是必要的。
你可以通過可觀察性監視微服務的狀況，確保它們的性能和行為。通過工具來掌握系統整體的運行狀況和功能非常重要。
自從編程問世以來，日志記錄一直被當作可觀察性和監視指標的常規方法，但這對于云原生應用程序還不夠。
重要的是你能夠觀察到系統的當前狀況。你必須擁有現代化的監視工具SLA，并了解服務水平的穩健程度，以及解決問題和警告的平均時間。
GoCenter、ChartCenter等社區中心都建立了許多微服務。所有這些服務都默認在代碼中加入了健康檢查，并以此作為提高可觀察性的良好實踐。
如何以可重復的方式在K8S上部署應用程序？
假設我們在Kubernetes集群上安裝了Redis，那么問題就是，我是否可以重用我的安裝程序，運行100次，仍然可以獲得相同的輸出？如果答案是否定的，則表明你的系統存在安全隱患。除了安全問題之外，這也是維護的噩夢。對于微服務，可重用性是關鍵，而且不知道依賴關系來自何處，那么問題就很嚴重了。
那么，如何解決這個問題呢？答案很簡單：使用包管理器，使用Helm。Helm可以提高可重用性以及可重復性。因此，Helm Chart和Helm Chart的各個版本都可以實現可重復性。
但是，這是真的嗎？Helm生態系統是否保證可重復性？
上面提到的是一些嚴重的問題，并且與安全問題有很多的聯系。因此，Helm生態系統雖然有其一定優勢，同時也存在嚴重的弊端。
隨著Kubernetes成為企業在云原生世界默認的容器編排平臺，Helm可以幫助我們更輕松地重復安裝和升級應用程序。盡管“ Kubernetes + Helm”組合是云原生的入門方法之一，但是仍然缺乏安全性，而ChartCenter滿足了持續保護云原生生態系統的需求。
ChartCenter可以作為一種解決方案，幫助大家以可重復的方式提供公共的Helm Chart，從而確保云原生生態系統的安全，同時可以遏制日益增長的安全隱患。
ChartCenter可以為公開的K8s應用程序的Helm Chart提供安全可靠的來源。目前還沒有標準規定生產者如何與云原生生態系統中的消費者共同承擔安全隱患，也沒有任何咨詢說明。為了解決這個問題，我們提出了一個標準，該標準可幫助生產者使用Helm Chart提供安全緩解信息。
下面是一些ChartCenter的獨特之處：
1. 中心存儲庫可以幫助用戶輕松地設置客戶端，并保持可追溯性。
2. 高可用性和可擴展性服務保障了可靠的生產服務。不可變性可以更進一步確保你放心地使用Chart，即便作者刪除了Chart，你依然可以訪問。
3. 出色的搜索功能，能夠根據命名空間、名稱、描述和標簽快速找到合適的Chart。
4. 上游依賴：安裝Helm Chart會拉取容器鏡像以及其他子Chart，其中可能包含關系到安全和許可證的問題，因此我們不建議你使用被棄用或過時的依賴庫。生產部署隨時可以接收到這些重要的信息，這一點非常關鍵。
5. 隨著Chart快速地發展，了解誰可能會受到更改的影響有助于增進穩定性和信任度。Chart的作者認為在支持向后兼容性和管理重大更改時，該功能非常有幫助性。
6. 安全掃描：ChartCenter會針對存儲庫中的1.2萬個Docker鏡像中包含的1.8M個組件進行連續掃描，這些鏡像被3萬多個Helm Chart版本引用。
現如今，每家公司都希望以高質量和高可靠性來鞏固自家的軟件產品。云原生之路讓各個公司充滿信心，相信他們可以快速地發布高質量的產品。Kubernetes和Helm等平臺已經發展了很長一段時間，能夠幫助軟件公司利用云原生原則的力量，例如現代CI/CD、微服務等。希望本文提到的技術能夠幫助你克服重重困難，順利地完成云原生之旅。
原文鏈接：
https://dzone.com/articles/securing-your-cloud-native-journey
8000字 | 32 張圖 | 一文搞懂事務+隔離級別+阻塞+死鎖
放棄 Windows 后 ，開源操作系統能成為主流桌面系統嗎？
賠償 525 萬？聯想前副總裁跳槽小米仲裁案后續，常程不服提起訴訟
刪庫跑路升級版，著名大廠員工離職為報復公司，直接刪虛擬機！
今年至少有75家交易所關閉，近半數沒有說明原因
總結
以上是生活随笔為你收集整理的如何应对云原生之旅中的安全挑战？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Mendix：低代码与无代码的异同点与用
- 下一篇： 阿里工程师用 8 张图告诉你如何存储、管