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