出品丨Docker公司(ID:docker-cn)
编译丨小东
每周一、三、五晚6点10分 与您不见不散
说在前面
上周,KubeCon 欧洲大会在哥本哈根的成功举办,让我们来回顾那些在 Docker 和 Kubernetes 读者中最受欢迎的帖子吧。对于那些还没有尝试过 Docker EE 2.0 版本的用户来说,这篇文章将重点介绍 Docker EE 2.0 版本如何为 Kubernetes 提供安全的供应链。
&
上个月,Docker 揭晓了 Docker 企业版(EE)2.0 版本 —— 唯一的企业级容器平台(更多有关 Docker EE 2.0 版本的信息请参考下列文章),它集成了 Kubernetes 编排,可以让其与 Swarm 并行运行,并为运行在本地或云端的遗留和新的应用程序提供统一的容器平台支持。对于正在探索 Kubernetes 或正在将其部署到生产环境的组织来说,Docker EE 为容器化应用程序的整个生命周期提供了完整的安全保障,在Kubernetes部署工作负载之前提供额外的安全层,并在应用程序运行过程中提供持续的保护。
Mike Coleman 之前发表过有关 Kubernetes访问控制的文章,详情请参考:揭秘Docker EE 新版本特性 , RBAC为Kubernetes 护航(文尾处附测试版下载地址)。今天,我将为大家讲解 Docker EE 如何保护 Kubernetes 供应链。
什么是软件供应链?
当您从零售商店购买产品时,其实是由一条完整的供应链支撑,即从原材料到制造商,再由制造商加工成产品后到零售商店,最后再到您的手中。同样的,软件也有一条完整的供应链,它将应用程序的代码从开发者笔记本上面迁移到生产环境中。
每家公司的软件供应链可能都略有不同:一些选择外包软件开发、一些采用持续集成和持续交付流程、一些采用跨多个云端部署生产应用程序,还有一些在本地部署。无论软件供应链包含了什么内容,Docker EE 都提供了一整套解决方案,确保应用程序在使用 Kubernetes 和 Swarm 的所有步骤时仍然可信和安全。
在本文中,我们将更深入地了解这个解决方案中的一个重要部分 —— 即镜像扫描和基于策略的镜像提升。
安全、自动化的
Kubernetes 工作流程
在应用程序部署到生产环境之前,组织通常希望知道这个应用程序已经没有任何已知的漏洞,这些漏洞通常来自于该软件之前的版本或未打补丁的版本。就算对于大型组织来说,为他们运行中的每个应用程序(并且可能受到新漏洞的影响)保留一份完整的漏洞记录也是一件很困难的事。
而 Docker EE 提供了镜像安全扫描功能,该功能可以帮助组织在应用程序部署到生产环境之前识别已知漏洞,并在新漏洞影响到现有应用程序时向您提示。该功能是针对 NIST 发布的已知漏洞列表来为您的镜像执行一个二进制级别的镜像扫描。如下图所示,该功能可以彻底扫描镜像的每个层,并提供工作负载的详细信息。
Docker EE 还可以定义策略来实现镜像在镜像仓库之间的自动化迁移。这些镜像提升策略还可以与镜像扫描的结果结合在一起,从而创建一个安全的、自动化的工作流程来保障镜像迁移到生产环境中。
举个例子,开发人员正在开发一个新的 Kubernetes 项目,该项目可以访问“dev”镜像仓库,并且可以在该镜像仓库上传和下载镜像。“dev”镜像仓库设置了镜像扫描功能,以便自动扫描所有上传到该镜像仓库的镜像。当开发人员准备将新项目的镜像投入到生产环境时,他们就会在镜像中添加如“最新”之类的特定标签。同时他们会为镜像仓库设置镜像提升策略,该策略是如果镜像具有“最新”标签且没有严重漏洞时,该镜像就可以自动复制或提升到“QA”镜像仓库中。
在此示例中,只有QA团队才能访问QA文件夹,从而限制了访问,确保只对那些有需求的人开放权限。该策略还可确保开发人员在将漏洞传递给QA团队之前修复漏洞。
结合这些 Docker EE 的功能,组织可以:
在镜像仓库之间实现镜像大规模的自动化迁移;
在开发的特定阶段进行安全扫描;
防止将有已知漏洞的应用程序部署到生产环境中;
限制对敏感镜像仓库(如“生产”镜像仓库)的访问,只对有需要人开放权限,同时通过定义适当的策略来消除流程中的瓶颈问题;
这些都是把应用程序部署到 Kubernetes 生产环境之前所产生的关键工作流程。现在通过Docker EE,您就可以得到一条完整、安全的软件供应链。更多 Kubernetes 安全供应链的相关信息,请观看以下视频:
点击下列标题,阅读更多干货
如果本文对你有帮助,欢迎分享到朋友圈!获取更多Docker实用技巧,扫描下图二维码!