1、安全沙箱容器在邊緣計(jì)算場(chǎng)景的實(shí)踐目錄安全沙箱容器Edge Kubernetes安全沙箱容器edge方案新探索安全容器帶來(lái)的機(jī)遇與挑戰(zhàn)據(jù) Gartner 預(yù)測(cè) 2019 年一半以上的企業(yè)會(huì)在其開發(fā)和生產(chǎn) 環(huán)境中使用容器部署應(yīng)用，容器技術(shù)日趨成熟穩(wěn)定，然而42% 以上的受訪者表示安全成為其容器化的最大障礙之一， 主要包括容器運(yùn)行時(shí)安全、鏡像安全和數(shù)據(jù)安全加密。圖片來(lái)源: /wp-content/uploads/2017/03/Docker-Security.png?resize=696%2C345&ssl=1端到端云原生安全架構(gòu)基礎(chǔ)架構(gòu)安全安全軟件供應(yīng)鏈容器運(yùn)行時(shí)安全KMS集成內(nèi)置安全設(shè)計(jì)網(wǎng)絡(luò)策略

2、租戶管理運(yùn)行時(shí)安全安全沙箱容器專有云公共云RAM認(rèn)證，細(xì)粒度RAM授權(quán)，支持審計(jì)能力鏡像掃描DevSecOps靜態(tài)加密 BYOK鏡像簽名安全分發(fā)安全合規(guī)安全容器運(yùn)行時(shí)對(duì)比安全容器運(yùn)行時(shí)分類OS容器+安全機(jī)制用戶態(tài)內(nèi)核Library OSMicroVM內(nèi)核模式共享內(nèi)核獨(dú)立內(nèi)核典型代表Docker OS容器gVisorUniKernel Nabla ContainersKata-Containers Firecracker特點(diǎn)RunC 共享內(nèi)核。訪問控制增強(qiáng)：SELinux、AppArmor、Seccomp等。Rootless Mode (docker 19.03+)獨(dú)立用戶態(tài)內(nèi)核，代理應(yīng) 用所有

3、系統(tǒng)調(diào)用。進(jìn)程虛擬化增強(qiáng)?；?LibOS技術(shù)，內(nèi)核深度 裁剪，啟動(dòng)速度較快。內(nèi)核需與應(yīng)用編譯打包在一 起?；谳p量虛擬化技術(shù)，擴(kuò)展能力 優(yōu)。內(nèi)核OS可定制。應(yīng)用兼容性優(yōu)。安全性最優(yōu)。缺點(diǎn)無(wú)法有效防范內(nèi)核漏洞問題。安全訪問控制工具對(duì)管理員認(rèn)知 和技能要求高。安全性相對(duì)最差。應(yīng)用兼容性以及系統(tǒng)調(diào)用 性能較差。不支持 Virtio，擴(kuò)展性較 差。應(yīng)用兼容性差。應(yīng)用和LibOS的捆綁編譯和 部署為傳統(tǒng)的 DevOPS 帶 來(lái)挑戰(zhàn)。Overhead 較大，啟動(dòng)速度相對(duì)較 慢。徹底解決安全問題？不可能。The only real solution to security is to admit that

4、 bugs happen, and then mitigate them by having multiple layers.”-Linus Torvalds (LinuxCon NA 2015, Seattle)安全容器運(yùn)行時(shí)選擇沒有任何一種容器運(yùn)行時(shí)技術(shù)可以滿足所有場(chǎng)景的需求，需根據(jù)業(yè)務(wù)需求合理選擇。安全隔離性能隔離故障域影響小低Overhead啟動(dòng)速度應(yīng)用性能應(yīng)用兼容性O(shè)CI 兼容、K8sAPI 兼容等生態(tài)特點(diǎn)輕量虛擬機(jī)沙箱；獨(dú)立 kernel，強(qiáng)隔離; 安全 影響域最??；兼容OCI標(biāo)準(zhǔn)，兼容幾乎所 有 K8s API；約25MB內(nèi)存極低開銷， 500ms極速啟動(dòng)，原生 90% 性能；多

5、租負(fù)載隔離、不可信應(yīng)用 隔離、Serverless等場(chǎng)景;ACK安全沙箱容器多用戶負(fù)載隔離不可信負(fù)載隔離可信加密運(yùn)行環(huán)境ACK Kubernetes 集群普通Pod安全沙箱PodNodeEBM(神龍)/BMAlibaba Cloud Sandboxed PodCCKernelAlibaba Cloud Sandboxed PodCCKernelNodeECS/EBM(神龍)基于輕罣虛擬化技術(shù)實(shí)現(xiàn)強(qiáng)隔離Host KernelPodCCPodCCHost Kernel目錄安全沙箱容器Edge Kubernetes安全沙箱容器edge方案新探索特點(diǎn)云邊端相互協(xié)同，提供統(tǒng)一的 交付、運(yùn)維、管控標(biāo)準(zhǔn)；云

6、端統(tǒng)一管控，節(jié)點(diǎn)自治、網(wǎng) 絡(luò)自治；設(shè)備就近接入（邊）；支持安全沙箱容器。ACK邊緣容器Infrastructure EdgeE.g. CDN, ENS，ServerlessDevice EdgeE.g. 工廠、園區(qū)、樓宇、機(jī)場(chǎng)、設(shè)備網(wǎng)關(guān)Cloud（云）Edge（邊）Device（端）云端統(tǒng)一管控邊緣適度自制設(shè)備就近接入支持多種設(shè)備接入?yún)f(xié)議AI預(yù)測(cè)實(shí)時(shí)計(jì)算直播、轉(zhuǎn)碼+隨著萬(wàn)物互聯(lián)時(shí)代的到來(lái)，智慧城市、智能制造、智能交通、智能家居，5G時(shí)代、寬帶提速、IPv6的不斷普及，導(dǎo)致數(shù)百億的設(shè)備接入 網(wǎng)絡(luò)，在網(wǎng)絡(luò)邊緣產(chǎn)生ZB級(jí)數(shù)據(jù)，傳統(tǒng)云計(jì)算難以滿足物聯(lián)網(wǎng)時(shí)代大帶寬、低時(shí)延、大連接的訴求，邊緣云計(jì)算便應(yīng)運(yùn)

7、而生。邊緣計(jì)算設(shè)施服務(wù)越來(lái)越難以滿足邊端日益膨脹的訴求，因而云上服務(wù)下沉，邊緣 Serverless、邊緣側(cè)隔離不可信負(fù)載等日趨強(qiáng)烈.目錄安全沙箱容器Edge Kubernetes安全沙箱容器edge方案新探索邊緣安全沙箱容器整體架構(gòu)挑戰(zhàn)u 邊緣弱網(wǎng)節(jié)點(diǎn)自治如何避免驅(qū)逐。斷網(wǎng)節(jié)點(diǎn)數(shù)據(jù)/應(yīng)用治 理。u 安全沙箱容器運(yùn)行時(shí)兼容性K8s API 兼容監(jiān)控異常日志采集異常存儲(chǔ)性能極差(Rootfs & Volume).主要問題：節(jié)點(diǎn)失聯(lián)超過pod容忍時(shí)間（默認(rèn)300s）被驅(qū)逐問題。封（斷）網(wǎng)期間，節(jié)點(diǎn)應(yīng)用（如kubelet）重啟無(wú)法從 apiserver 獲取應(yīng)用數(shù)據(jù)信息問題。邊緣節(jié)點(diǎn)自治-社區(qū)云端K

8、8s Master公網(wǎng)https邊緣EdgeUnit 1Node1kubeletcheckpoint本地文件Node2kubeletcheckpoint本地文件EdgeUnit 2.K8s Federation云端邊緣EdgeUnit 1K8s Masterkubelet (data 內(nèi)存)Node1kubelet (data 內(nèi)存)Node2公網(wǎng)httpsEdgeUnit 2K8s Masterkubelet (data 內(nèi)存)Node 3kubelet (data 內(nèi)存)Node4僅緩存 POD，對(duì) ConfigMap/Secret/PV/PVC等暫不支持?？啥ㄖ菩薷膋ubelet，但面臨

9、升級(jí)難題。Overhead 成本高：所有邊緣區(qū)域均有 Master。難運(yùn)維：架構(gòu)較復(fù)雜，集群規(guī)模數(shù)倍增加，監(jiān)控、日志等復(fù)雜度。圖1 社區(qū)方案(一)圖2 社區(qū)方案(二)邊緣節(jié)點(diǎn)自治方案K8s Master公網(wǎng)httpsEdgeUnit 1EdgeHubkubelet(data 內(nèi)存)Node2EdgeHubkubelet(data 內(nèi)存)Node1EdgeUnit 2EdgeHubkubelet(data 內(nèi)存)Node4EdgeHubkubelet(data 內(nèi)存)Node3edge-controller-manager云端邊緣ECM(edge-controller-manager)：節(jié)點(diǎn)自治

10、管理，忽略自治模式節(jié)點(diǎn)上的 Pod 驅(qū)逐等。 EdgeHub：邊緣代理組件作為 kubelet 和 apiserver 之間的緩存和代理。在網(wǎng)絡(luò)正常情況下，EdgeHub直接代理轉(zhuǎn)發(fā) Kubelet 請(qǐng)求到 apiserver，并緩存結(jié)果到本地。在節(jié)點(diǎn)斷網(wǎng)的情況下，EdgeHub 利用本地緩存充當(dāng) apiserver，并忽略所有寫操作。安全沙箱容器方案圖監(jiān)控方案-拓?fù)鋱D主要問題:runC、runV 容器缺失 network、blk io等。如何架構(gòu)改動(dòng)/影響最 小？監(jiān)控方案擴(kuò)展CRI接口？安全沙箱容器存儲(chǔ)方案- RootFS采 devicemapper 案構(gòu)建速、穩(wěn)定的容器graph driv

11、er，實(shí)現(xiàn)功能、性能指標(biāo)全對(duì) runC 場(chǎng)景。GraphDriver:采用 devicemappersnapshot 機(jī)制，實(shí)現(xiàn)鏡 像分層存儲(chǔ)；IOPS、Bandwidth 與 RunC overlayfs + ext4 基本持平基于snapshot增強(qiáng)開發(fā)， 實(shí)現(xiàn)容器鏡像計(jì)算、存儲(chǔ) 分離安全沙箱容器存儲(chǔ)方案- VolumeVolume:9pfs （default，性能差）兼容 CSI 和 FlexVolume 插件云盤NASOSS* .性能優(yōu)化：Virtiofs vs 9pfs （通用）Blk device 直通Mount NAS on GuestOS主要問題：Logtail 只支持dock

12、er，不支持 containerd。所有 runC 和 runV 容器標(biāo)準(zhǔn)輸出無(wú)法采集。Logtail DaemonSet 模式無(wú)法直采 runC 和 runV 內(nèi)。日志方案解法：通用性：通過 CRI，而非 containerd SDK 連接 containerd。通過 Container Spec 獲取容器標(biāo)準(zhǔn)輸出日志路徑。優(yōu)先嘗試查找 Upper Dir，否則查找 devicemapper 最佳匹配路徑，由于runV 有獨(dú)立 kernel 無(wú)法在 Host 側(cè)直采容器內(nèi)日志文件。網(wǎng)絡(luò)方案三種網(wǎng)絡(luò)方案：Bridge橋接模式云上節(jié)點(diǎn)。通用性好。性能相對(duì)較差。網(wǎng)卡直通模式云上場(chǎng)景：彈性網(wǎng)卡ENI

13、。邊緣場(chǎng)景：SR-IOV。性能最好，Host網(wǎng)卡數(shù)量限制。IPVlan模式下一代網(wǎng)絡(luò)方案。網(wǎng)絡(luò)性能對(duì)比Ping 時(shí)延帶寬(128B)帶寬(1024B)TCP_RRUDP_RRHost100%100%100%100%100%網(wǎng)卡直通100%100%100%98%92%Bridge140%82%80%77%75%IPVlan121%81%85%80%78%注：以上為內(nèi)部數(shù)據(jù)測(cè)試結(jié)果，僅供參考。結(jié)論：直通網(wǎng)卡的性能可以做到接近host的性能，ipvlan和bridge與直通網(wǎng)卡方式有一定差距，但前兩者通用性更 好；總體來(lái)說(shuō) ipvlan 比 bridge 性能普遍更好。多運(yùn)行時(shí)調(diào)度（1.14.0 =

14、 kubernetes = 1.16.0）apiVersion: node.k8s.io/v1beta1 handler: runvkind: RuntimeClass metadata:name: runv overhead:podFixed:cpu: 100m memory: 50MinodeSelector: runtime: runvtolerations:# .Kubernetes 1.16.0+ 支持 RuntimeClass 調(diào)度，同時(shí)支持 pod overhead 設(shè)置，參考：runtimeclass issue：/kubernetes/enhancements/pull/90

15、9runtimeclass kep：/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class-scheduling.md （已加入1.16.0）pod-overhead: /kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.mdapiVersion: v1 kind: Pod metadata:name: my-runv-ypod spec:runtimeClassName: runv nodeSelector: runtime:runv# .目錄安全沙箱容器Edge Kubernetes安全沙箱容器edge方案新探索探索 We Can Do More !Cloud密碼身份信息秘鑰健康數(shù)據(jù)機(jī)密數(shù)據(jù)探索：機(jī)密計(jì)算 隱私/機(jī)密數(shù)據(jù)保護(hù)多用戶負(fù)載隔離不可信負(fù)載隔離可信加密運(yùn)行環(huán)境ACK Kubernetes 集群普通Pod安全沙