点击下载《不一样的 双 11 技术: 阿里巴巴经济体云原生实践》 https://developer.aliyun.com/article/728327
本文节选自《不一样的 双 11 技术: 阿里巴巴经济体云原生实践》一书, 点击上方图片即可下载!
作者
汤志敏 阿里云容器服务高级技术专家
汪圣平 阿里云云平台安全高级安全专家
导读: 从 Docker image 到 Helm, 从企业内部部署到全球应用分发, 作为开发者的我们如何来保障应用的交付安全. 本文会从软件供应链的攻击场景开始, 介绍云原生时代的应用交付标准演进和阿里云上的最佳实践.
"没有集装箱, 就不会有全球化". 在软件行业里, Docker 和 Kubernetes 也扮演了类似的角色, 加速了软件行业的社会化分工和交付运维的效率. 2013 年, Docker 公司提出了容器应用打包规范 Docker Image, 帮助开发者将应用和依赖打包到一个可移植的镜像里. 2015 年, Google 将 Kubernetes 捐献给 CNCF, 进一步普及了大规模容器编排调度的标准.
Kubernetes 以一种声明式的容器编排与管理体系, 屏蔽了底层基础架构的差异, 让软件交付变得越来越标准化. 随着 K8s 为代表的云原生技术的大规模运用, 越来越多的容器化应用被分发到 IDC, 公共云, 边缘等全球各地.
在 2019 年, 阿里云容器镜像服务 ACR 的月镜像下载量超过了 3 亿次. 同年 10 月, 阿里云云市场的容器镜像类目发布, 越来越多的企业将其软件以容器的方式进行上架和销售. 11 月, 天猫 双 11 的所有核心系统 100% 上云, 容器镜像服务 ACR 除了支持 双 11 的内部镜像托管以外, 也将内部的能力在云上透出, 支持更多的 双 11 生态公司.
接下来我们看下如何保证容器和 Kubernetes 下的软件供应链安全, 并先熟悉下软件供应链的常见攻击场景.
软件供应链攻击面和典型攻击场景
软件供应链通常包括三个阶段:
软件研发阶段
软件交付阶段
软件使用阶段
在不同阶段的攻击面如下:
历史上著名的 APPLE Xcode IDE 工具攻击就是发生在软件研发阶段的攻击, 攻击者通过向 Xcode 中注入恶意后门, 在非官方网站提供下载, 所有使用此 Xcode 的开发者编译出来的 App 将被感染后门. 同样著名的还有美国的棱镜门事件, 亦是在大量的软件中植入后门程序, 进行数据获取等恶意操作.
Kubernetes 中的软件供应链攻击面也包括在以上范围之中, 以软件使用阶段为例, 今年 RunC 漏洞 CVE-2019-5736, 漏洞本身与 RunC 的运行设计原理相关, Container 之外的动态编译 Runc 被触发运行时会引用 Conainer 内部的动态库, 造成 RunC 自身被恶意注入从而运行恶意程序, 攻击者只需要在一个 Container 镜像中放入恶意的动态库和恶意程序, 诱发受攻击者恶意下载运行进行模糊攻击, 一旦受攻击者的 Container 环境符合攻击条件, 既可完成攻击.
同样的攻击面还存在于 Kubernetes 自身服务组件之中, 前段时间爆出的 HTTP2 CVE-2019-9512,CVE-2019-9514 漏洞就是一个非常好的软件研发阶段脆弱性的例子, 漏洞存在于 GO 语言的基础 LIB 库中, 任何依赖 GO 版本 (<1.2.9) 所编译的 KubernetesHTTP2 服务组件都受此漏洞影响, 因此当时此漏洞影响了 K8s 全系列版本, 攻击者可以远程 DOS Kubernetes API Server. 同时在 Kubernetes 组件的整个交付过程中也存在着攻击面, 相关组件存在被恶意替换以及植入的可能性.
不同于传统的软件供应链, 镜像作为统一交付的标准如在容器场景下被大规模应用, 因此关注镜像的使用周期可以帮助攻击者更好的设计攻击路径.
攻击者可以在镜像生命周期的任何一个阶段对镜像进行污染, 包括对构建文件的篡改, 对构建平台的后门植入, 对传输过程中的劫持替换和修改, 对镜像仓库的攻击以替换镜像文件, 对镜像运行下载和升级的劫持攻击等.
整个攻击过程可以借助云化场景中相关的各种依赖, 如 Kubernetes 组件漏洞, 仓库的漏洞, 甚至基础设施底层漏洞. 对于防御者来说, 对于镜像的整个生命周期的安全保障, 是容器场景中攻击防范的重中之重.
云原生时代的应用交付标准演进(从 Image 到 Artifacts)
在云原生时代之前, 应用交付的方式比较多样化, 比如脚本, RPM 等等. 而在云原生时代, 为了屏蔽异构环境的差异, 提供统一的部署抽象, 大家对应用交付标准的统一也迫切起来.
Helm
Helm 是 Kubernetes 的包管理工具, 它提出了 Chart 这个概念.
一个 Chart 描述了一个部署应用的多个 Kubernetes 资源的 YAML 文件, 包括文档, 配置项, 版本等信息;
提供 Chart 级别的版本管理, 升级和回滚能力.
CNAB
CNAB 是 Docker 和微软在 2018 年底联合推出平台无关的 Cloud Native Application Bundle 规范. 相比于 Helm, 有额外几个定义:
在 thick 模式时, CNAB 的 bundle 可以包含依赖的镜像二进制, 从而不需要额外去镜像仓库下载, 作为一个整体打包;
CNAB 定义了扩展的安全标准, 定义了 bundle 的签名 (基于 TUF ) 和来源证明 (基于 In-Toto) 描述;
CNAB 的部署是平台无关性, 可以部署在 K8s 之上, 也可以通过 terraform 等方式来部署.
CNAB 的这些特性, 可以在可信软件分发商与消费者之间进行跨平台 (包括云和本地 PC) 的应用打包和分发.
OCI Artifacts
2019 年 9 月, 开放容器标准组织 (OCI) 在 OCI 分发标准之上, 为了支持更多的分发格式, 推出了 OCI Artifacts 项目来定义云原生制品 (Cloud Native Artifacts) 的规范. 我们可以通过扩展 media-type 来定义一种新的 Artifacts 规范, 并通过标准的镜像仓库来统一管理.
来源: https://www.cnblogs.com/alisystemsoftware/p/12009531.html