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

原文链接：点击打开链接

摘要：创建安全的镜像供应链至关重要。每个组织都需要权衡所有可用选项并了解安全风险。可供选择的镜像过多大大增加了挑选难度。归根结底，每个组织都需要了解所有镜像的来源，即使它是来自于 store.docker.com 中的可信认的上游镜像时也是如此。

screenshot

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

创建安全的镜像供应链至关重要。每个组织都需要权衡所有可用选项并了解安全风险。可供选择的镜像过多大大增加了挑选难度。归根结底，每个组织都需要了解所有镜像的来源，即使它是来自于 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)。

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

screenshot

已知可靠源头

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

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

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

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

Docker 商店

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

screenshot

挑选合适的上游镜像

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

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

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

screenshot

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

screenshot

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

screenshot

除了商店中的“认证”镜像之外，另一种很棒的资源是 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。然后执行以下命令：

sudodockerswarminit 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>


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