最佳实践系列丨Docker EE 供应链安全加固指南（一）

摘要： 建立安全的镜像供应链相当重要。每一个组织都须要权衡全部可用选项并了解安全风险。可供选择的镜像过多大大增长了挑选难度。归根结底，每一个组织都须要了解全部镜像的来源，即便它是来自于 store.docker.com 中的可信认的上游镜像时也是如此。

 

本文首发自“Docker公司”公众号（ID：docker-cn）
编译丨小东
每周1、3、五 与您不见不散！

建立安全的镜像供应链相当重要。每一个组织都须要权衡全部可用选项并了解安全风险。可供选择的镜像过多大大增长了挑选难度。归根结底，每一个组织都须要了解全部镜像的来源，即便它是来自于 store.docker.com 中的可信认的上游镜像时也是如此。将镜像导入基础架构后，颇有必要进行漏洞扫描。而带镜像扫描功能的 Docker Trusted Registry 提供了深刻了解漏洞的能力。最后，整个过程须要实现自动化以提供简单的审核线索。

学习内容

本参考架构介绍了安全供应链的组件。主题包括使用 Git、Jenkins 和 Docker 商店来为供应链提供素材。可使用同类工具替代本参考架构中列出的和用做示范的全部工具。安全供应链可分为三个阶段：

• 阶段 1 是代码镜像仓库。
• 阶段 2 是持续集成。
• 阶段 3 是能够扫描镜像的镜像库。

尽管存在许多替代工具，本文档主要关注一组工具组合：

• GitLab（阶段 1）
• Jenkins（阶段 2）
• Docker Trusted Registry（阶段 3）

对于此参考架构，须要牢记一条格言“任何人都不得将构建或部署直接投入生产的代码！”

先决条件

在继续以前,请先了解并熟悉：

• Docker 文档中的 Docker 概念：https://docs.docker.com/engine/docker-overview/
• 保护 Docker EE 安全和安全最佳实践：https://success.docker.com/article/security-best-practices

缩写词

在本文档中使用了如下缩写词：

UCP = Universal Control Plane
DTR = Docker Trusted Registry
DCT = Docker Content Trust
EE = Docker 企业版
RBAC = Role Based Access Controls（基于角色的访问控制）
CA = Certificate Authority（认证中心）
CI = Continuous Integration（持续集成）
CD = Continuous Deployment（持续部署）
HA = High Availability（高可用性）
BOM = Bill of Materials（物料清单）
CLI = Command Line Interface（命令行接口）

缘由

您须要安全供应链的缘由有多个。从理论上讲，必须为生产环境建立安全供应链。非生产环境管道也可因拥有自动化基础镜像而受益。提到供应链，就该想起一些重要的格言：

• “任何人都不得将构建或部署直接投入生产的代码！”
  它能够防止恶意代码偷偷进入经过审核的代码。它也有助于预防内部威胁。

• “一切都须要审核线索。”
  若是可以证实内容、时间、缘由、和方式，就能够简化每一个人的工做。

• “每一个供应链都须要已知安全源头。”
  您会在沼泽中建房吗？

理想状况下，您但愿用最快的速度获取镜像。您但愿确保镜像的成功能够贯穿整个供应链。限制所要采起的步骤的数量是减小移动组件的理想方式。整体来看，只须要两个组件，Git (GitLab) 和 Docker Trusted Registry (DTR)。

下面是当今途径的基本图表。

 

已知可靠源头

不管供应链有多出色，它都依赖于从“已知可靠源头”着手。阶段 1 能够分为两个可能的起点。

• 来自 Docker 商店的自动化、预制、（最好）经认证的镜像；
• 带有 Dockerfile 和其余 YAML 的私有安全 Git 镜像仓库；

二者都有充分的理由。Docker 商店途径意味着继承上游镜像时面临少量风险，取决于供应商构建它的方式。Git 途径意味着构建镜像时须要冒风险。两个入口点都各有优缺点。两个起点都有可验证的内容，以确保它们是“已知可靠源头”。

在后面的部分将对两个源头进行详细介绍。

Docker 商店

Docker 商店 store.docker.com 应当是查找镜像的首选位置。它为每一个组织提供了巨大的优点。商店中包含大量随时可用的镜像。镜像全部者负责更新镜像并确保镜像无漏洞。Docker 商店保证了全部“认证”和“官方”镜像都通过漏洞扫描。对于“认证”镜像，Docker 商店和供应商还会采起更进一步的措施。认证镜像须要经历全面的审查流程。从根本上说，供应商和 Docker 为认证镜像提供容器可正常工做的保证。商店中还包含“官方”镜像。“官方”镜像由 Docker 构建，而且也会由 Docker 按期进行更新。Docker 商店和 Docker Hub 中还包含社区镜像。非万不得已请勿使用社区镜像。

 

挑选合适的上游镜像

​从商店中挑选合适的镜像相当重要。决定使用哪一个镜像的决策过程很是简单。请优先考虑认证镜像，而后再考虑官方镜像。最后考虑社区镜像。请仅使用“自动构建”的社区镜像。这有助于确保它们会被及时更新。验证镜像的新鲜度也很重要。

如下内容节选自有关认证镜像的一篇博文：

Docker 认证计划旨在帮助技术合做伙伴和企业客户识别在质量、合做支持及合规性方面表现超群的容器和插件。Docker 认证以可用的 Docker EE 基础架构为标准，借助 Docker 和发布者的支持，为企业提供在容器中运行更多技术的可靠途径。借助显而易见的徽章，客户能够快速识别出经认证的容器和插件，而且能够确信它们采用最佳实践构建，经测试可在 Docker EE 上平稳运行。

 

在 Docker 商店中搜索镜像时，请务必选中 Docker 认证复选框。

 

Docker 商店的一个出色功能是镜像都须要通过安全漏洞扫描。此功能使您可在拉取镜像前先对镜像进行检查。

 

除了商店中的“认证”镜像以外，另外一种很棒的资源是 Hub 的“官方”镜像。全部这些“官方”镜像都是自动化的，通过扫描且更新频率很高。

当使用非官方或未经认证的上游镜像时，须要确保镜像为自动构建。一个重要的步骤是审查 Dockerfile，以确保镜像中仅包含正确的数位。万不得已时，可考虑建立社区的“自动”镜像。

请注意，任何从 Hub 或商店中拉取的镜像也都应经过 Docker Trusted Registry 接受相同级别的详细审查。

Git - (GitLab CE)

在现代企业中，版本控制系统对于全部代码都很重要。Git 等版本控制系统也是跟踪配置的出色方式。Git 真正成为了企业的“数据源”。多家公司都搭建了 Git 服务器。GitLab CE 是出色的开源 Git 服务器。在下面的示例中使用的是 GitLab 社区版。

理想的 Git 镜像仓库结构包含构建和部署所需的全部文件。具体来讲，就是 Dockerfile、代码和 stack.yml。 Dockerfile是用来构建 Docker 镜像的“食谱”。代码文件应该简单易懂。 stack.yml 用来描述应用栈。 stack.yml 也被称为 compose YAML 文件。下面的示例使用 Docker 设置了一个 GitLab 实例。该实例应位于您的 Docker 企业版集群外部。

设置

针对使用 Docker 镜像设置，GitLab 提供了一些很是好的说明。Git 默认使用 SSH 端口 (22)，所以无需更改主机或 Git 的端口。下面展现了如何将 GitLab 的端口移动到 2022。对于生产环境来讲，移动主机的 SSH 端口可能更为合理。另外，对于有状态安装，须要使用永久存储。使用应用栈文件来简化安装过程：

> > version: "3.3"
services:
  gitlab:
    image: gitlab/gitlab-ce:latest
    ports:
      - 80:80
      - 443:443
      - 2022:22
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /srv/gitlab/config:/etc/gitlab
      - /srv/gitlab/logs:/var/log/gitlab
      - /srv/gitlab/data:/var/opt/gitlab
    restart: always
    networks:
      gitlab:
 
  gitlab-runner:
    image: gitlab/gitlab-runner:alpine
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - /srv/gitlab-runner/config:/etc/gitlab-runner
      - /root/.docker:/root/.docker
      - /root/.notary:/root/.notary
    restart: always
    networks:
      gitlab:
 
networks:
  gitlab:
将```  
以上内容保存为 gitlab.yml。而后执行如下命令：

sudodockerswarminitsudodockerswarminit sudo docker stack deploy -c gitlab.yml gitlab

注意，GitLab 须要一分钟来启动。

----

#### 镜像仓库内容

利用“数据源”的一个好方法是将构成镜像的全部内容与应用栈存储在一块儿。该示例为三层应用，由“Web”、“middleware”和“db”组成。将全部三个 Dockerfile 和 stack.yml 存储在相同的位置很是便于全部团队进行构建和部署。理论上，目录结构中应包含：

1. 名称为 web.dockerfile、middleware.dockerfile 和 db.dockerfile 的 Dockerfile。
1. 每层的源数位和工件（位于另外一个目录中）。
1. stack.yml（用于 docker stack deploy）。
1. GitLab CI 描述 .gitlab-ci.yml（后面将介绍）。

别忘了在 Dockerfile 中使用多阶段构建。多阶段构建有助于大幅减少生成的镜像的大小。如今，您能够自动实现这一切。

<p style="text-align:center">![screenshot](https://yqfile.alicdn.com/9d5740f041bf21085c02cec216eeb1f432d472f8.png)</p>


下一部分将介绍持续集成自动化的相关内容。