Chart 的出處與完整性驗證

Helm擁有可幫助chart使用者驗證chart包完整性和出處的工具。使用基於PKI，GnuPG和備受尊敬的軟體包管理器的行業標準工具，Helm可以生成並驗證簽名檔案。

概述

完整性通過將chart與其出處記錄進行比較來確定。出處記錄儲存在出處檔案provenance中，並與打包的chart一起儲存。例如，如果chart包被命名myapp-1.2.3.tgz，其出處檔案將是myapp-1.2.3.tgz.prov。

出處檔案在打包時生成（helm package --sign ...），並且可以通過多個命令檢查，比如helm install --verify。

工作流程

本節描述了有效使用出處資料的可用的工作流程。

前提條件：

• 二進位制（非ASCII）格式的有效PGP金鑰對
• helm命令列工具
• GnuPG命令列工具（可選）
• Keybase命令列工具（可選） – 注意：如果PGP私鑰有密碼，支援--sign選項的任何命令系統將提示輸入密碼以檢視。

建立chart：

$ helm create mychart
Creating mychart

準備打包後，將--sign引數加到helm package。另外，指定已知簽名金鑰和包含相應私鑰的金鑰環keyring：

$ helm package --sign --key `helm signing key` --keyring path/to/keyring.secret mychart

提示：對於GnuPG使用者，金鑰環已存在~/.gnupg/secring.gpg。可以使用gpg –list-secret-keys列出擁有的金鑰。

警告： GnuPG v2在預設位置在〜/ .gnupg / pubring.kbx，使用新格式’kbx’儲存金鑰keyring。請使用以下命令將鑰匙keyring轉換為傳統的gpg格式：

$ gpg --export-secret-keys >~/.gnupg/secring.gpg

到這裡，應該可用看到mychart-0.1.0.tgz和mychart-0.1.0.tgz.prov。這兩個檔案最終應該上傳到想要的chart庫。

可以使用helm verify以下方式驗證chart：

$ helm verify mychart-0.1.0.tgz

驗證失敗如下所示樣例：

$ helm verify topchart-0.1.0.tgz Error: sha256 sum does not match for topchart-0.1.0.tgz: "sha256:1939fbf7c1023d2f6b865d137bbb600e0c42061c3235528b1e8c82f4450c12a7" != "sha256:5a391a90de56778dd3274e47d789a2c84e0e106e1a37ef8cfa51fd60ac9e623a"

要在安裝過程中進行驗證，請使用該--verify標誌。

$ helm install --verify mychart-0.1.0.tgz

如果金鑰keyring（包含與簽名chart關聯的公鑰）不在預設位置，則可能需要--keyring PATH像helm package示例中那樣指向金鑰keyring。

如果驗證失敗，在chart被推到Tiller之前中止安裝終止。

使用Keybase.io憑據

該Keybase.io服務可以很容易建立信任鏈的密碼身份。金鑰庫憑證可用於對chart進行簽名。

前提條件：

• 已配置的Keybase.io帳戶
• GnuPG在本地安裝
• keybaseCLI本地安裝

簽署軟體包

第一步是將keybase金鑰匯入到本地GnuPG金鑰keyring中：

$ keybase pgp export -s | gpg --import

這會將Keybase金鑰轉換為OpenPGP格式，然後將其本地匯入到~/.gnupg/secring.gpg檔案中。

可以通過執行gpg --list-secret-keys進行仔細檢查。

$ gpg --list-secret-keys /Users/mattbutcher/.gnupg/secring.gpg
-------------------------------------
sec 2048R/1FC18762 2016-07-25
uid technosophos (keybase.io/technosophos) <technosophos@keybase.io>
ssb 2048R/D125E546 2016-07-25

注意，金鑰有一個識別符號字串：

technosophos (keybase.io/technosophos) <technosophos@keybase.io> 

這是鑰匙的全名。

接下來，可以使用helm package打包和簽名chart。--key確保至少使用該名稱字串的一部分。

$ helm package --sign --key technosophos --keyring ~/.gnupg/secring.gpg mychart

結果，package命令應該生成一個.tgz檔案和一個.tgz.prov 檔案。

驗證軟體包

還可以使用類似的技術來驗證由其他人的Keybase金鑰簽名的chart。假設想驗證簽名的軟體包keybase.io/technosophos。請使用該keybase工具：

$ keybase follow technosophos
$ keybase pgp pull

上面的第一條命令跟蹤使用者technosophos。接下來keybase pgp pull，將關注的所有帳戶的OpenPGP金鑰下載到GnuPG金鑰環（~/.gnupg/pubring.gpg1）中

到此，可以使用helm verify或帶有--verify引數的任何命令：

$ helm verify somechart-1.2.3.tgz

可能無法驗證的原因

下面是失敗的常見原因。

• prov檔案丟失或損壞。這表明某些內容配置錯誤或原始維護人員未建立出處檔案。
• 用於簽署檔案的金鑰不在鑰匙keyring中。這表明簽名chart的組織不是已經信任的人員。
• prov檔案的驗證失敗。這表明chart或出處資料有問題。
• prov檔案中的檔案雜湊與壓縮包檔案的雜湊不匹配。這表明壓縮包已被篡改。
• 如果驗證失敗，則有理由懷疑該軟體包有問題。

Provenance檔案

Provenance檔案包含chart的YAML檔案以及幾條驗證資訊。Provenance檔案被設計自動生成。

新增了以下幾個出處資料：

• 包含chart檔案（Chart.yaml）可以讓人員和工具輕鬆檢視chart內容。
• 包括chart包（.tgz檔案）的簽名（SHA256，就像Docker）一樣，可用於驗證chart包的完整性。
• 整個檔案使用PGP使用的演算法進行簽名（參見[ http://keybase.io ]，這是一種使加密簽名和驗證變得容易的新方法）。

這樣的組合給了使用者以下保證：

• 包本身沒有被篡改（校驗和包tgz）。
• 已知釋出此包的組織（通過GnuPG / PGP簽名）。

該檔案的格式如下所示：

-----BEGIN PGP SIGNED MESSAGE-----
name: nginx
description: The nginx web server as a replication controller and service pair.
version: 0.5.1
keywords: - https
 - http
 - web server
 - proxy
source: - https://github.com/foo/bar
home: http://nginx.com ...
files:
 nginx-0.5.1.tgz: “sha256:9f5270f50fc842cfcb717f817e95178f” -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkjilUEACgQkB01zfu119ZnHuQCdGCcg2YxF3XFscJLS4lzHlvte
WkQAmQGHuuoLEJuKhRNo+Wy7mhE7u1YG =eifq
-----END PGP SIGNATURE-----

注意，YAML部分包含兩個文件（由分隔...
）。首先是Chart.yaml。第二個是校驗和，一個檔名到SHA-256摘要的對映（上顯示的值是假的/被截斷的）

簽名塊是一個標準的PGP簽名，它提供了防篡改功能。

Chart庫

Chart庫用作Helm chart的集中場所。

Chart儲存庫必須能夠通過特定的請求通過HTTP為provenance檔案提供服務，並且必須使它們在與chart相同的URI路徑下可用。

例如，如果軟體包的基本URL是https://example.com/charts/mychart-1.2.3.tgz, provenance檔案（如果存在）必須可以通過https://example.com/charts/mychart-1.2.3.tgz.prov訪問。

從終端使用者的角度來看，`helm install –verify myrepo/mychart-1.2.3 “應該無需額外的配置或操作即可下載chart和provenance檔案。

確認認證和真實性

在處理信任鏈系統時，能夠確認簽名者的認證很重要。或者，簡單地說，上述系統取決於相信簽名人員的事實。這反過來又意味著你需要信任簽名者的公鑰。

Kubernetes Helm的設計決策之一是Helm專案不會將自己插入信任鏈中作為必要的組分。我們不希望成為所有chart簽名者的“證書頒發機構”。相反，我們強烈支援分散模式，這是我們選擇OpenPGP作為基礎技術的原因之一。所以說到確認認證時，我們在Helm 2.0.0中對這個步驟或多或少未明確定義。

但是，對於那些有興趣使用rpovenance系統的人，我們有一些建議：

• Keybase 平臺提供了可靠資訊的公開集中存放。
• 可以使用Keybase儲存金鑰或獲取其他公鑰。
• Keybase也有很多可用的文件
• 雖然我們還沒有對它進行測試，但Keybase的“安全網站”功能可用於服務Helm chart。
• Kubernetes chart專案 正在設法解決這個管方chart庫official Kubernetes Charts project問題。
• 這裡有一個很長的issue，詳細介紹了當前的想法。
• 基本思想原則是官方的“chart reviewer”用她或他的鑰匙簽名chart，然後將得到的Provence檔案上傳到chart儲存庫。
• 關於有效簽名金鑰列表可包含在index.yaml儲存庫檔案中的想法已經有了一些工作進展。

最後，信任鏈是Helm的一個發展特徵，一些社群成員已經提出了將OSI模型的一部分用於簽名。這是Helm團隊的一個開放性調查。如果你有興趣，請參與其中。

本文轉自kubernetes中文社群-Helm chart指南-系列（6）- 出處與完整性驗證