最佳實踐系列丨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>


下一部分將介紹持續集成自動化的相關內容。