一場突如其來的疫情讓全員遠程辦公提前五年到來，各大企業IT紛紛連夜加班打通遠程辦公的通道。一個個來自書桌上，沙發上，床上的無管控或輕管控的電腦通過VPN進入內網，自由的訪問內網資源，處理敏感數據，接觸核心代碼。傳統安全防護在內網和外網之間劃了一道紅線，劃定了內網的安全域，為了操作的方便，大多數內網資源都可自由訪問。突如其來的遠程辦公讓這個假設的“安全域”不再安全，內網設備之間的互相信任關係被打破。唯一值得欣慰的是很少有來自機場，酒店，咖啡廳等容易被攻擊的公共wifi連接的終端。
2010年，Forrester分析師John Kindervag提出了“零信任模型”（Zero Trust Model)。其核心思想是“Never Trust， Always Verify”。網絡安全的信任關係將不再區分內網外網，所有對資源的訪問都需要驗證其合法性。特別喜歡一個同事對零信任的一個總結。
“Zero Trust” is the philosophy of security. Its principles are ABCDE: “Assume nothing, Believe nobody, Check everything, Defeat threats/risks, Expect and prepare for the worst.” Where “check everything” includes not only network, data, devices, workloads, systems, applications, services, but also most importantly IAM and people whose actions/behaviors and business risks must be checked.
沒想到這場疫情竟成為了對零信任核心思想最好的現實例證，復工之後每個人不再認為可以通過辦公室大門就進入了一個安全區域，每個在辦公室裡的人都全副武裝，無論是對曾經信任的同事還是陌生人都做同等的防護。應對這種新的安全架構，Google從2014年12月起發表了多篇BeyondCorp相關的論文，重新定義了辦公網絡安全架構，其目標是讓所有員工從不受信任的網絡中不接入VPN就可順利辦公，平等對待位於內部和外部的設備，不再有默認的邊界及信任區。
辦公形式迎來鉅變的同時，軟件架構也迎來了一場變革。隨著容器，微服務架構，DevOps等技術的發展，越來越多的軟件架構開始使用雲原生架構設計。雲原生架構下的軟件設計有以下幾個特點：
-
- 使用解耦合的微服務架構，服務與服務之間通過網絡通信
- 運行實例短時存在，IP將不再作為唯一標識
- 服務可運行在任何地方，包括跨區域的公有云，混合雲
- 頻繁的更新
- 實例運行在共享的操作系統
一個個散落在雲臺上的服務實例不正可類比為一個個散落在不同網絡裡遠程接入的辦公終端麼？基於這種類比，Google在2019年12月發表了BeyondProd白皮書，描述了一種基於零信任的應用於雲原生的安全架構。以下是Google在描述BeyondCorp和BeyondProd時使用的同樣句式不同對象。
"Key assumptions of this model no longer hold: The perimeter is no longer just the physical location of the enterprise [data center], and what lies inside the perimeter is no longer a blessed and safe place to host personal computing devices and enterprise applications[microservices].”
BeyondProd對比了傳統的安全和雲原生安全，提出了以下幾項改變：
- 從基於邊界的安全轉變為零信任安全：傳統的安全模型中，企業應用的保護基於部署在數據中心外圍的邊界防火牆。雲原生環境下，傳統邊界安全仍然需要，但已經不能滿足要求。基於零信任的安全架構取消了內外網之分，對內部通信不再採取默認信任，而是要通過相同的訪問控制。
- 從固定的IP和硬件轉變為更大的共享資源池：傳統的安全工具基於固定IP地址作為唯一標識去識別不同的應用，基於IP地址指定針對不同應用的安全策略。雲原生環境中，應用實例是短時存在的，其IP地址無法作為唯一標識，應該使用服務來標識。
- 從應用特有的安全實現轉變為共享的安全需求：傳統軟件架構中，應用需要自己設計實現安全需求，這樣會導致不一致的安全基線或者遺漏掉的安全漏洞修復。雲原生環境下，服務數量大幅增加，多種服務頻繁複用，因此需要統一的安全管理及統一的安全策略執行。
- 從不頻繁的固定的變更轉變為更頻繁的變更：傳統軟件架構下，應用相互依賴嚴重，每次升級都傷筋動骨，因此運維團隊會為變更設置固定週期。雲原生環境下，應用耦合降低，自動化程度高，可以相對簡單的升級模塊或服務，需要將安全防護添加到軟件供應鏈的每個環節。
- 從使用物理機或虛擬機隔離轉變為共享操作系統：傳統軟件架構下，應用之間通過物理機或虛擬機進行隔離，從安全角度來看可以將安全事件的影響限制在有限可控的範圍內。在雲原生環境下，多個服務實例共享操作系統，一個存在漏洞服務被攻陷可能會導致運行在同主機上其他服務受到影響。因此需要通過網絡隔離和沙箱技術對應用進行隔離。
BeyondProd同時提出了對雲原生環境下安全的幾個原則：
- 邊緣防護：邊緣防護仍然十分必要並不可或缺。對於入向流量，雲原生環境可以利用K8S Network Policy加Istio Ingressgateway的方式控制暴露到公網的服務。K8S network policy可以從三層或四層對入向流量進行訪問控制，Istio Gateway把訪問控制的顆粒度提升到了七層，可更加精細化的限制暴露在公網的服務。開源軟件對入向流量控制時並不能完全滿足要求，公有云提供的DDoS攻擊防護和WAF（Web應用防火牆）也是必不可少的組件，這些商業產品可以從網絡流量特徵上阻斷從外網的攻擊。對於出向流量的控制也非常重要，大部分攻擊在進入內網之後都會通過各種方式與外網C&C服務器通信獲取更新或指令。與辦公網絡不同的是大部分雲原生服務不需要主動對外網發起連接，因此可以利用K8S Network Policy和Istio Egressgateway配合的方式將對外訪問的控制在指定範圍。通過K8S Network Policy控制整個服務網格中只有Istio Egressgateway可以訪問外面，將網格內對外的訪問全部轉到egressgateway作為代理，並將對外訪問控制在ServiceEntry中定義的外部站點。Istio Egressgateway也可以利用Istio的流量控制功能，強制出網格的流量全部走加密通道，或者對外部網站做併發限制。
- 服務之間零信任：服務之間的通信需要在一個加密的通道內完成，並且只有通過了認證，並且有訪問權限的調用者才可以訪問到服務。利用Istio開啟雙向TLS，可以保證服務間的通信在加密通道中完成。雙向TLS認證保證了客戶端對服務器證書的驗證以及服務器端對客戶端證書的驗證。客戶端證書中包含了調用者的服務標識（使用serviceaccount作為服務的標識，istio將serviceaccount與具體的服務進行映射），通過Istio安全功能中的鑑權功能，可以嚴格指定ACL，將服務之間的通信控制在有限的範圍內，只有服務權限的調用者才能調用指定的服務。Istio將ACL的顆粒度細化到了應用層，可以進行更細粒度的控制，例如可以對HTTP method進行控制，也可以細化到請求頭當中的某個屬性。同時Istio指定規則的源和目標都是以服務為唯一標識，可以快速應對服務IP的改變。
- 服務執行統一的安全策略：Istio可以統一管理多個集群，使多個集群使用同樣的安全策略。對於每個應用的安全管控也是由istio統一配置和管理的，應用無需單獨處理流量加密認證鑑權等安全功能。使用OPA(open policy agent)可以屏蔽不同服務不同產品對安全策略定義的差異，提供統一的工具集和框架。
下圖為Istio安全架構，此架構能很好地詮釋Istio如何實現以上三點原則：
Istio安全架構
- 在可信的主機上運行可以溯源的代碼：雲原生除了使軟件架構發生了重大變化之外，對服務上線的流程也有較大的改變。雲原生環境下，企業大多使用持續集成持續發佈的高度自動化流程，從程序員編寫代碼到自動化測試到安全掃描到發佈上線，整個流程稱作軟件供應鏈。既然是零信任，那就需要對軟件供應鏈的每一步加入安全屬性。比較典型的軟件供應鏈攻擊就是XCodeGhost了，編譯軟件將惡意代碼嵌入到發佈軟件當中，只要安裝了此軟件的用戶就可能觸發惡意代碼。Google提出了二進制授權（Binary Authorization）的方式保證只有滿足軟件供給鏈安全的實例才能部署。相應的開源軟件可以使用Grafeas配合Kritis來實現。Grafeas是一個開源的元數據API服務，在整個軟件供應鏈中提供統一的審計和管理。Grafeas定義了API管理軟件資源的元數據，典型的軟件資源包括容器鏡像，虛擬機鏡像，Jar包及腳本。Kritis是一款開源的基於K8S的軟件供應鏈安全解決方案。可以通過k8s apiserver創建基於容器鏡像的安全策略，其註冊的validatingwebhook可以在Pod創建時查詢grafeas獲取此鏡像的元數據並匹配安全策略，只有符合安全策略的容器才允許部署。安裝Kritis會創建四個CRD，kritisconfigs用於自身的配置（配置指向哪個grafeas），genericattestationpolicies用於定義鏡像需要包含哪些attestation（軟件供應量的每個階段完成會向grafeas寫入相應的attestation），imagesecuritypolicies用於定義鏡像白名單，可接受的CEV安全界別及CVE例外列表，attestationauthorities用於創建Kritis使用的attestation authority。當一個鏡像通過validatingwebhook之後，Kritis會為此鏡像創建一個attestation，當容器重新調度或者擴容的時候會直接得到這個attestaion確保運行成功不影響現有業務。同時會有一個cronjob定期檢查鏡像是否符合策略的要求（如有新的安全漏洞發現），當發現不符合策略時，會給運行的pod打上指定label，由管理員決定如何處理。
下圖是Grafeas應用於軟件供應鏈中的一個示例圖。
Grafeas應用於軟件供應鏈安全流程圖
- 簡單、自動、標準的升級過程：標準的升級過程可保證安全補丁及時安裝並減少對生產環境的影響。使用K8S deployment和statefulset部署無狀態和有狀態服務，可在升級工程中保證服務不間斷。Istio利用其更精細的流量管理功能可將軟件升級的影響降到最低，輕鬆實現A/B測試或灰度升級。
- 共享操作系統的實例隔離：運行在同一個宿主機上的多個容器共享操作系統，當一個容器因為漏洞被攻陷的時候很可能會影響其他運行在同宿主機上的容器的安全。可以通過對實例進行隔離的方式將一次攻擊事件對整個系統的影響降到最低。比較常見的隔離方式有三種：
-
- 基於規則的系統調用控制，例如seccomp，SELinux和AppArmor。如果能將系統調用控制在非常有限的範圍內，這將是一種很好的對應用實例進行隔離的方法，但實際中很難對一個應用做出這種規則，這種方式通常是作為一種輔助手段，為其他方式提供更進一步的保護。
- 基於沙箱技術，如gVisor。此技術把通常在宿主機內核中實現的系統調用轉移到了每個沙箱獨立的用戶空間內核，通過截獲系統調用並充當guest內核把攻擊的風險降到最低。gVisor目前並沒有實現全部系統調用，因此並不保證所有的應用都能正常運行。
- 基於虛擬化技術，如Kata Container。此技術通過對傳統的虛擬化技術進行裁剪和優化，實現一種輕量級的虛擬化系統。其既有虛擬化技術在隔離和安全方面的優勢，又有容器技術發佈打包的便捷。
K8S支持多種運行時（runtime）類型，用戶可根據應用不同的安全需求選擇其運行時類型，對於包含敏感數據或關鍵業務的實例使用提供隔離能力的運行時類型，對於非關鍵業務使用容器運行時。
綜上所述，零信任架構對於雲原生安全的需求既包含了對基礎架構的變化也包含了對研發流程的變化。Istio在其中扮演了重要的角色，其提供了統一的安全策略管理及管控，並對應用程序透明，是使用開源軟件實現此安全架構的首選。同時利用grafeas提供的標準元數據API及統一管理，結合Kritis的策略定義和管控，可以很好的控制研發流程中的安全風險。雲原生架構結合零信任安全架構可為軟件研發團隊和安全團隊提供巨大的便利，使應用能夠更安全的運行在生產環境。
