time 
设为首页】【收藏本站
当前位置: 主页 > 程序设计 > .net > .net综合 > Kubernetes 时代的安全软件供应链

Kubernetes 时代的安全软件供应链

时间:2019-12-28 16:50 点击:157次 字体:[ ]




  “没有集装箱,就不会有全球化”。在软件行业里,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 组件漏洞、仓库的漏洞,甚至基础设施底层漏洞。对于防御者来说,对于镜像的整个生命周期的安全保障,是容器场景中攻击防范的重中之重。

  在云原生时代之前,应用交付的方式比较多样化,比如脚本、RPM 等等。而在云原生时代,为了屏蔽异构环境的差异,提供统一的部署抽象,大家对应用交付标准的统一也迫切起来。

  在 thick 模式时,CNAB 的 bundle 可以包含依赖的镜像二进制,从而不需要额外去镜像仓库下载,作为一个整体打包;

  CNAB 定义了扩展的安全标准,定义了 bundle 的签名(基于 TUF )和来源证明(基于 In-Toto)描述;

  CNAB 的部署是平台无关性,可以部署在 K8s 之上,也可以通过 terraform 等方式来部署。

  CNAB 的这些特性,可以在可信软件分发商与消费者之间进行跨平台(包括云和本地 PC)的应用打包和分发。

  2019 年 9 月,开放容器标准组织(OCI)在 OCI 分发标准之上,为了支持更多的分发格式,推出了 OCI Artifacts 项目来定义云原生制品(Cloud Native Artifacts)的规范。我们可以通过扩展 media-type 来定义一种新的 Artifacts 规范,并通过标准的镜像仓库来统一管理。

  在之前章节也提到过,相对于传统软件的安全软件供应链管理,容器和 Kubernetes 的引入使得:

  在传统的软件安全和安全准则之上,我们可以结合一些最佳实践,沉淀一个新的端到端安全软件供应链:

  2017 年 10 月,Google 联合 JFrog、IBM 等公司推出了 Grafeas。Grafeas(希腊语中的scribe)旨在定义统一的方式来审核和管理现代软件供应链,提供云原生制品的元数据管理能力。可以使用 Grafeas API 来存储,查询和检索有关各种软件组件的综合元数据,包括合规和风险状态。

  通过验证链中的每个任务是否按计划执行(仅由授权人员执行)以及产品在运输过程中未被篡改来做到这一点。In-toto 要求项目所有者创建布局 (Layout)。布局列出了软件供应链的步骤 (Step) 顺序,以及授权执行这些步骤的工作人员。当工作人员执行跨步操作时,将收集有关所使用的命令和相关文件的信息,并将其存储在链接 (Link) 元数据文件中。通过在完整的供应链中定义每个 Step,并对 Step 进行验证,可以充分完整的完整整个供应链的安全。

  同时对于在安全软件供应链中占比很大的第三方软件,需要有完善的基线机制和模糊安全测试机制来保障分发过程中的安全风险,避免带已知漏洞上线,阿里云正在与社区积极贡献帮助演进一些开源的工具链。

  关于基础镜像优化、安全扫描、数字签名等领域也有非常多的工具和开源产品,在此不一一介绍。

  在阿里云上,我们可以便捷地基于容器服务 ACK、容器镜像服务 ACR、云安全中心打造一个完整的安全软件供应链。

  安全软件供应链全链路以云原生应用托管为始,以云原生应用分发为终,全链路可观测、可追踪、可自主设置。可以帮助安全需求高、业务多地域大规模部署的企业级客户,实现一次应用变更,全球化多场景自动交付,极大提升云原生应用交付的效率及安全性。

  在云原生应用的安全托管阶段,容器镜像服务 ACR 支持容器镜像、Helm Chart 等云原生资产的直接上传托管;也支持从源代码(Github、Bitbucket、阿里云 Code、GitLab 来源)智能构建成容器镜像。在安全软件供应用链中,支持自动静态安全扫描并自定义配置安全阻断策略。一旦识别到静态应用中存在高危漏洞后,可自动阻断后续部署链路,通知客户失败的事件及相关漏洞报告。客户可基于漏洞报告中的修复建议,一键更新优化构建成新的镜像版本,再次触发自动安全扫描。

  由于使用了基于分层的调度、公网链路优化以及免公网入口开启的优化,云原生应用的全球同步效率,相比本地下载后再上传提升了 7 倍。云原生应用同步到全球多地域后,可以自动触发多场景的应用重新部署,支持在 ACK、ASK、ACK@Edge 集群中应用自动更新。针对集群内大规模节点分发场景,可以实现基于镜像快照的秒级分发,支持 3 秒 500 Pod 的镜像获取,实现业务在弹性场景下的极速更新。

  云安全中心基于云原生的部署能力,实现威胁的数据自动化采集、识别、分析、响应、处置和统一的安全管控。利用多日志关联和上下文分析方案,实时检测命令执行、代码执行、SQL 注入、数据泄露等风险,覆盖业务漏洞入侵场景。结合 K8s 日志和云平台操作日志实时进行行为审计和风险识别,实现容器服务和编排平台存在的容器逃逸、AK 泄露、未授权访问风险。

  随着云原生的不断发展,云原生应用也会在安全、交付、全球分发等领域持续演进。我们可以预见一个新的时代:越来越多的大型软件以积木的方式由全球开发者独立开发而最终合并组装。



本文地址 : http://www.fengfly.com/plus/view-215988-1.html
标签: .net综合
------分隔线----------------------------
最新评论 查看所有评论
发表评论 查看所有评论
请自觉遵守互联网相关的政策法规,严禁发布色情、暴力、反动的言论。
评价:
表情:
验证码: