安全沙箱容器在边缘计算场景的实践 高步双
2020-03-01 438浏览
- 1.安全沙箱容器在边缘计算场景的实践 高步双(花名:江博) 阿里云容器服务技术专家
- 2.自我介绍
- 3.自我介绍 高步双(花名:江博),阿里云容器服务安全容器负责人,2017 年加入阿里,主要从 事 Kubernetes 相关产品的设计研发工作,负责或参与容器服务安全容器、边缘容器、 SAE、资源调度系统稳定性分析引擎、Kubernetes&YARN 混部等相关产品、项目的设 计和研发工作。
- 4.目录 1. 安全沙箱容器 2. Edge Kubernetes 3. 安全沙箱容器@edge方案 4. 新探索
- 5.安全容器带来的机遇与挑战 据 Gartner 预测 2019 年一半以上的企业会在其开发和生产 环境中使用容器部署应用,容器技术日趋成熟稳定,然而 42% 以上的受访者表示安全成为其容器化的最大障碍之一, 主要包括容器运行时安全、镜像安全和数据安全加密。 图片来源:https://i2.wp.com/foxutech.com/wp-content/uploads/2017/03/Docker-Security.png?resize=696%2C345&ssl=1
- 6.端到端云原生安全架构 基础架构安全 镜像签名 RAM认证,细粒度RAM授权,支持审计能力 专有云 安全软件供应链 公共云 静态加密 BYOK 镜像扫描 DevSecOps 容器运行时安全 安全合规 安全分发 KMS集成 内置安全设计 网络策略 安全沙箱容器 运行时安全 租户管理
- 7.安全容器运行时对比 安全容器运行时分类 OS容器+安全机制 内核模式 共享内核 典型代表 Docker OS容器 用户态内核 Library OS MicroVM 独立内核 gVisor UniKernel Nabla Containers Kata-Containers Firecracker 特点 • 基于轻量虚拟化技术,扩展能力 • RunC 共享内核。 • 基于 LibOS技术,内核深度 • 独立用户态内核,代理应 优。 • 访问控制增强:SELinux、 裁剪,启动速度较快。 用所有系统调用。 • 内核OS可定制。 AppArmor、Seccomp等。 • 内核需与应用编译打包在一 • 进程虚拟化增强。 • 应用兼容性优。 • Rootless Mode (docker 19.03+) 起。 • 安全性最优。 缺点 • 无法有效防范内核漏洞问题。 • 安全访问控制工具对管理员认知 和技能要求高。 • 安全性相对最差。 • 应用兼容性以及系统调用 • 应用兼容性差。 性能较差。 • 应用和LibOS的捆绑编译和 • 不支持 Virtio,扩展性较 部署为传统的 DevOPS 带 差。 来挑战。 • Overhead 较大,启动速度相对较 慢。
- 8.彻底解决安全问题?不可能。 "The only real solution to security is to admit that bugs happen, and then mitigate them by having multiple layers.” ---Linus Torvalds (LinuxCon NA 2015, Seattle)
- 9.安全容器运行时选择 • 低Overhead • 启动速度 • 应用性能 • 安全隔离 • 性能隔离 • 故障域影响小 • 应用兼容性 • OCI 兼容、K8sAPI 兼容等 • 生态 没有任何一种容器运行时技术可以满足所有场景的需求,需根据业务需求合理选择。
- 10.ACK安全沙箱容器 特点 • 轻量虚拟机沙箱; ACK Kubernetes • 独立 kernel,强隔离; 安全 Pod Pod 影响域最小; • 兼容OCI标准,兼容几乎所 有 K8s API; • 约25MB内存极低开销, Pod C 500ms极速启动,原生 90% Node Node Alibaba Cloud Sandboxed Pod Pod C C C C C Alibaba Cloud Sandboxed Pod C Kernel Host Kernel Host Kernel ECS/EBM( Kernel ) EBM( )/BM C 性能; • 多租负载隔离、不可信应用 隔离、Serverless等场景;
- 11.目录 1. 安全沙箱容器 2. Edge Kubernetes 3. 安全沙箱容器@edge方案 4. 新探索
- 12.ACK边缘容器 随着万物互联时代的到来,智慧城市、智能制造、智能交通、智能家居,5G时代、宽带提速、IPv6的不断普及,导致数百亿的设备接入 网络,在网络边缘产生ZB级数据,传统云计算难以满足物联网时代大带宽、低时延、大连接的诉求,边缘云计算便应运而生。 边缘计算设施服务越来越难以满足边端日益膨胀的诉求,因而云上服务下沉,边缘 Serverless、边缘侧隔离不可信负载等日趋强烈... Cloud(云) 特点 • 云边端相互协同,提供统一的 + 云端统⼀一管控 边缘适度⾃自制 Edge(边) 设备就近接⼊入 ⽀支持多种设备接⼊入协议 Device(端) • 云端统一管控,节点自治、网 络自治; • 设备就近接入(边); • AI预测 Infrastructure Edge E.g. CDN, ENS,Serverless 交付、运维、管控标准; • 实时计算 • 直播、转码 Device Edge E.g. ⼯工⼚厂、园区、楼宇、机场、设备⽹网关 • 支持安全沙箱容器。
- 13.目录 1. 安全沙箱容器 2. Edge Kubernetes 3. 安全沙箱容器@edge方案 4. 新探索
- 14.边缘安全沙箱容器整体架构 挑战 u 边缘弱网节点自治 Ø 如何避免驱逐。 Ø 断网节点数据/应用治 理。 u 安全沙箱容器运行时兼容性 Ø K8s API 兼容 Ø 监控异常 Ø 日志采集异常 Ø 存储性能极差(Rootfs & Volume) Ø ...
- 15.边缘节点自治-社区 主要问题: 1. 2. 节点失联超过pod容忍时间(默认300s)被驱逐问题。 封(断)网期间,节点应用(如kubelet)重启无法从 apiserver 获取应用数据信息问题。 图1 社区方案(一) 云端 图2 社区方案(二) 云端 K8s Master K8s Federation 公网https 边缘 公网https 边缘 EdgeUnit 1 EdgeUnit 2 Node1 EdgeUnit 1 Node2 kubelet checkpoint 本地文件 EdgeUnit 2 K8s Master kubelet ... checkpoint 本地文件 Node1 kubelet (data à 内存) K8s Master Node2 kubelet (data à 内存) Node 3 kubelet (data à 内存) Node4 kubelet (data à 内存) • 仅缓存 POD,对 ConfigMap/Secret/PV/PVC等暂不支持。 • Overhead 成本高:所有边缘区域均有 Master。 • 可定制修改kubelet,但面临升级难题。 • 难运维:架构较复杂,集群规模数倍增加,监控、日志等复杂度。
- 16.边缘节点自治方案 云端 K8s Master edge-controller-manager 公网https 边缘 EdgeUnit 1 Node1 EdgeUnit 2 Node3 Node2 Node4 EdgeHub EdgeHub EdgeHub EdgeHub kubelet kubelet kubelet kubelet (data à 内存) (data à 内存) (data à 内存) ECM(edge-controller-manager):节点自治管理,忽略自治模式节点上的 Pod 驱逐等。 EdgeHub:边缘代理组件 • 作为 kubelet 和 apiserver 之间的缓存和代理。 • 在网络正常情况下,EdgeHub直接代理转发 Kubelet 请求到 apiserver,并缓存结果到本地。 • 在节点断网的情况下,EdgeHub 利用本地缓存充当 apiserver,并忽略所有写操作。 (data à 内存)
- 17.安全沙箱容器方案图
- 18.监控方案-拓扑图 主要问题: • runC、runV 容器缺失 network、blk io等。 • 如何架构改动/影响最 小?
- 19.监控方案 扩展CRI接口?
- 20.安全沙箱容器存储方案 - RootFS 采⽤ devicemapper ⽅案构建⾼速、稳定的容器graph driver,实现功能、性能指标全⾯对⻬ runC 场景。GraphDriver:• 采用 devicemapper snapshot 机制,实现镜 像分层存储; • IOPS、Bandwidth 与 RunC overlayfs + ext4 基本持平 • 基于snapshot增强开发, 实现容器镜像计算、存储 分离
- 21.安全沙箱容器存储方案 - VolumeVolume:- 9pfs (default,性能差) - 兼容 CSI 和 FlexVolume 插件 * 云盘 * NAS * OSS * ... 性能优化: - Virtiofs vs 9pfs (通用) - Blk device 直通 - Mount NAS on GuestOS
- 22.日志方案 主要问题: 1. Logtail 只支持docker,不支持 containerd。 2. 所有 runC 和 runV 容器标准输出无法采集。 3. Logtail DaemonSet 模式无法直采 runC 和 runV 内。 解法: 1. 通用性:通过 CRI,而非 containerd SDK 连接 containerd。 2. 通过 Container Spec 获取容器标准输出日志路径。 3. 优先尝试查找 Upper Dir,否则查找 devicemapper 最佳匹配路径,由于 runV 有独立 kernel 无法在 Host 侧直采容器内日志文件。
- 23.网络方案 三种网络方案: • Bridge桥接模式 - 云上节点。 - 通用性好。 - 性能相对较差。 • 网卡直通模式 - 云上场景:弹性网卡ENI。 - 边缘场景:SR-IOV。 - 性能最好,Host网卡数量限制。 • IPVlan模式 - 下一代网络方案。
- 24.网络性能对比 Ping 时延 带宽(128B) 带宽(1024B) TCP_RR UDP_RR Host 100% 100% 100% 100% 100% 网卡直通 100% 100% 100% 98% 92% Bridge 140% 82% 80% 77% 75% IPVlan 121% 81% 85% 80% 78% 结论: 直通网卡的性能可以做到接近host的性能,ipvlan和bridge与直通网卡方式有一定差距,但前两者通用性更 好;总体来说 ipvlan 比 bridge 性能普遍更好。 注:以上为内部数据测试结果,仅供参考。
- 25.多运行时调度(1.14.0 <= kubernetes < 1.16.0)apiVersion:'>apiVersion: