本文的的核心內(nèi)容是提供有關(guān)如何設(shè)置 Gitlab 和 Vault 以在 CI/CD 管道構(gòu)建期間使用密鑰。另外，本文將分解 JWT 授權(quán)過(guò)程，并解釋 Gitlab + Vault 的流程。通過(guò)本文，讀者最終可以實(shí)現(xiàn)自己的帶有 Vault 密鑰的 CI/CD 流程。

目的

在 Vault 上啟用 JWT 身份驗(yàn)證方法

利用 JWT 授權(quán)從 Vault 中讀取密鑰以進(jìn)行 Gitlab CI/CD 作業(yè)

背景

什么是 Gitlab?

GitLab 是一個(gè)基于 Web 的 DevOps 生命周期工具 ，它提供了一個(gè) Git 代碼存儲(chǔ)庫(kù)管理，同時(shí)它使用 GitLab Inc 開(kāi)發(fā)的開(kāi)源許可證提供 wiki、問(wèn)題跟蹤以及持續(xù)集成和pipeline的功能。

在學(xué)習(xí)Gitlab的定義之前，首先需要了解一些術(shù)語(yǔ)?？赡苣?jīng)常遇到像Git，Gitlab，GitHub和Bitbucket這樣的術(shù)語(yǔ)。

Git - 它是一個(gè)源代碼版本控制系統(tǒng)，可讓您在本地跟蹤更改并從遠(yuǎn)程資源推送或提取更改。 GitLab ，GitHub和Bitbucket - 提供遠(yuǎn)程訪問(wèn)Git存儲(chǔ)庫(kù)的服務(wù)。除了托管代碼之外，這些服務(wù)還提供用來(lái)幫助管理軟件開(kāi)發(fā)生命周期的附加功能。這些附加功能包括管理不同人之間的代碼共享，錯(cuò)誤跟蹤，wiki空間和其他“社交編碼”工具。

• GitHub 是一項(xiàng)公開(kāi)可用的免費(fèi)服務(wù)，它要求所有代碼(除非您有付費(fèi)帳戶)公開(kāi)。任何人都可以看到您推送給GitHub的代碼并提供改進(jìn)建議。GitHub目前承載數(shù)以萬(wàn)計(jì)的開(kāi)源項(xiàng)目的源代碼。
• GitLab是一種類(lèi)似github的服務(wù)，組織可以使用它來(lái)提供git存儲(chǔ)庫(kù)的內(nèi)部管理。它是一個(gè)自我托管的Git-repository管理系統(tǒng)，可以保持用戶代碼的私密性，并且可以輕松地部署代碼的更改。

GitLab是集中服務(wù)器上管理git存儲(chǔ)庫(kù)的一個(gè)好方法。GitLab讓您可以完全控制您的存儲(chǔ)庫(kù)或項(xiàng)目，并允許您自己決定是公共還是私有。

什么是HashiCorp Vault?

在企業(yè)級(jí)應(yīng)用開(kāi)發(fā)過(guò)程中，團(tuán)隊(duì)每時(shí)每刻都需要管理各種各樣的私密信息，從個(gè)人的登陸密碼、到生產(chǎn)環(huán)境的SSH Key以及數(shù)據(jù)庫(kù)登錄信息、API認(rèn)證信息等。通常的做法是將這些秘密信息保存在某個(gè)文件中，并且放置到git之類(lèi)的源代碼管理工具中。個(gè)人和應(yīng)用可以通過(guò)拉取倉(cāng)庫(kù)來(lái)訪問(wèn)這些信息。但這種方式弊端很多，比如跨團(tuán)隊(duì)分享存在安全隱患、文件格式難以維護(hù)、私密信息難以回收等。

尤其是微服務(wù)大行其道的今天，如何讓開(kāi)發(fā)者添加私密信息、應(yīng)用程序能輕松的獲取私密信息、采用不同策略更新私密信息、適時(shí)回收私密信息等變得越來(lái)越關(guān)鍵。所以企業(yè)需要一套統(tǒng)一的接口來(lái)處理私密信息的方方面面，而HashiCorp Vault就是這樣的一款工具。

Vault 是 hashicorp 推出的 secrets 管理、加密即服務(wù)與權(quán)限管理工具。

它提供了這些功能：

• 集中管理各種私密信息;
• 為私密信息設(shè)置租期(Lease)，到期后自動(dòng)失效;
• 密鑰的動(dòng)態(tài)生成、注銷(xiāo)和滾動(dòng)更新;
• 動(dòng)態(tài)創(chuàng)建無(wú)需保存的一次性登錄密鑰;
• 作為數(shù)據(jù)加密/解密接口;
• 完整的審計(jì)記錄;
• 命令行 以及 RESTful API 訪問(wèn)接口;

Valut存儲(chǔ)私密信息

不僅可以存放現(xiàn)有的私密信息，還可以動(dòng)態(tài)生成用于管理第三方資源的私密信息。所有存放的數(shù)據(jù)都是加密的。任何動(dòng)態(tài)生成的私密信息都有租期，并且到期會(huì)自動(dòng)回收。

滾動(dòng)更新秘鑰

用戶可以隨時(shí)更新存放的私密信息。Vault提供了加密即服務(wù)(encryption-as-a-service)的功能，可以隨時(shí)將密鑰滾動(dòng)到新的密鑰版本，同時(shí)保留對(duì)使用過(guò)去密鑰版本加密的值進(jìn)行解密的能力。對(duì)于動(dòng)態(tài)生成的秘密，可配置的最大租賃壽命確保密鑰滾動(dòng)易于實(shí)施。

審計(jì)日志

保管庫(kù)存儲(chǔ)所有經(jīng)過(guò)身份驗(yàn)證的客戶端交互的詳細(xì)審核日志：身份驗(yàn)證，令牌創(chuàng)建，私密信息訪問(wèn)，私密信息撤銷(xiāo)等?？梢詫徍巳罩景l(fā)送到多個(gè)后端以確保冗余副本。

另外，HaishiCorp Vault提供了多種方式來(lái)管理私密信息。用戶可以通過(guò)命令行、HTTP API等集成到應(yīng)用中來(lái)獲取私密信息。HashiCorp Vault也能與Ansible、Chef、Consul等DevOps工具鏈無(wú)縫結(jié)合使用。

什么是 CI/CD?

CI/CD 自動(dòng)化了將代碼從開(kāi)發(fā)人員機(jī)器交付到生產(chǎn)環(huán)境的過(guò)程。雖然只有短短數(shù)語(yǔ)，但如上圖所示，該流程本質(zhì)上包含很多步驟的。本節(jié)將詳細(xì)描述該過(guò)程。CI/CD 代表持續(xù)集成和持續(xù)部署，正如上面縮寫(xiě)以及圖所示，這是兩個(gè)不同的階段。持續(xù)集成是集成代碼更改的過(guò)程，驗(yàn)證新代碼更改仍然可以構(gòu)建/編譯應(yīng)用程序，并確保新代碼通過(guò)一組測(cè)試。

縮略詞 CI / CD 具有幾個(gè)不同的含義。CI/CD 中的"CI"始終指持續(xù)集成，它屬于開(kāi)發(fā)人員的自動(dòng)化流程。成功的 CI 意味著應(yīng)用代碼的新更改會(huì)定期構(gòu)建、測(cè)試并合并到共享存儲(chǔ)庫(kù)中。該解決方案可以解決在一次開(kāi)發(fā)中有太多應(yīng)用分支，從而導(dǎo)致相互沖突的問(wèn)題。

CI/CD 中的"CD"指的是持續(xù)交付和/或持續(xù)部署，這些相關(guān)概念有時(shí)會(huì)交叉使用。兩者都事關(guān)管道后續(xù)階段的自動(dòng)化，但它們有時(shí)也會(huì)單獨(dú)使用，用于說(shuō)明自動(dòng)化程度。

持續(xù)交付通常是指開(kāi)發(fā)人員對(duì)應(yīng)用的更改會(huì)自動(dòng)進(jìn)行錯(cuò)誤測(cè)試并上傳到存儲(chǔ)庫(kù)(如 GitHub 或Gitlab)，然后由運(yùn)維團(tuán)隊(duì)將其部署到實(shí)時(shí)生產(chǎn)環(huán)境中。這旨在解決開(kāi)發(fā)和運(yùn)維團(tuán)隊(duì)之間可見(jiàn)性及溝通較差的問(wèn)題。因此，持續(xù)交付的目的就是確保盡可能減少部署新代碼時(shí)所需的工作量。

例如，假設(shè)您有一個(gè)用 GoLang 編寫(xiě)的 Web 應(yīng)用程序。作為開(kāi)發(fā)人員，您對(duì)本地開(kāi)發(fā)機(jī)器上的現(xiàn)有應(yīng)用程序進(jìn)行一些更改，并將更改推送到 Gitlab。接下來(lái)，Gitlab 將嘗試使用您的更改編譯現(xiàn)有代碼庫(kù)。假設(shè)編譯成功，Gitlab 將對(duì)新編譯的代碼進(jìn)行多次測(cè)試，以確保應(yīng)用程序按預(yù)期運(yùn)行。如果測(cè)試成功，開(kāi)發(fā)人員可以將更改合并到 MAIN 分支中。

現(xiàn)在你可能會(huì)問(wèn)如果這個(gè)階段不成功會(huì)發(fā)生什么?使用上面的示例，假設(shè)您初始化了一個(gè)未使用的變量。如果您是 GoLang 開(kāi)發(fā)人員，您已經(jīng)知道這將無(wú)法編譯，但對(duì)于本示例，假設(shè)代碼已推送到 Gitlab。Gitlab 將再次嘗試編譯包含您的更改的代碼。但是，編譯將失敗，并且通常管道將在第一次出現(xiàn)錯(cuò)誤時(shí)停止運(yùn)行。Gitlab 將為開(kāi)發(fā)人員提供審查產(chǎn)生的錯(cuò)誤的能力。在解決此問(wèn)題之前，Gitlab 將不允許合并新代碼。

持續(xù)部署是再次評(píng)估/測(cè)試新提交的代碼的過(guò)程，將應(yīng)用程序推送給 QA 以進(jìn)行進(jìn)一步評(píng)估，最后在人工交互后將代碼推送到生產(chǎn)環(huán)境。推送到產(chǎn)線(生產(chǎn))意味著將您的代碼推送到環(huán)境中，以便用戶可以使用您的新代碼。同樣，正如上面的圖表所示，此過(guò)程還有更多內(nèi)容，但希望讀者能夠去了解更多的關(guān)于CICD的過(guò)程。

了解 JWT 授權(quán)

JSON Web Token (JWT)是目前最流行的跨域身份驗(yàn)證解決方案。簡(jiǎn)單說(shuō)，OAuth 就是一種授權(quán)機(jī)制。數(shù)據(jù)的所有者告訴系統(tǒng)，同意授權(quán)第三方應(yīng)用進(jìn)入系統(tǒng)，獲取這些數(shù)據(jù)。系統(tǒng)從而產(chǎn)生一個(gè)短期的進(jìn)入令(token)，用來(lái)代替密碼，供第三方應(yīng)用使用。

傳統(tǒng)的授權(quán)認(rèn)證方式，需要持久化session數(shù)據(jù)，寫(xiě)入數(shù)據(jù)庫(kù)或文件持久層等，且授權(quán)校驗(yàn)依賴于數(shù)據(jù)持久層。這樣的方式，對(duì)于結(jié)構(gòu)維護(hù)成本大，實(shí)現(xiàn)單點(diǎn)登錄較為復(fù)雜，且沒(méi)有分布式架構(gòu)，無(wú)法支持橫向擴(kuò)展，風(fēng)險(xiǎn)較大(如果持久層失敗，整個(gè)認(rèn)證體系都會(huì)掛掉)。

JWT則無(wú)須持久化會(huì)話數(shù)據(jù)，是以加密簽名的方式實(shí)現(xiàn)了用戶身份認(rèn)證授權(quán)，很好的解決了跨域身份驗(yàn)證，分布式session共享、單點(diǎn)登錄和橫向擴(kuò)展等問(wèn)題。另外，需要注意JWT：

• JWT默認(rèn)不加密，但可以加密。生成原始令牌后，可以使用改令牌再次對(duì)其進(jìn)行加密。
• JWT不僅可用于認(rèn)證，還可用于信息交換。善用JWT有助于減少服務(wù)器請(qǐng)求數(shù)據(jù)庫(kù)的次數(shù)。
• JWT的最大缺點(diǎn)是服務(wù)器不保存會(huì)話狀態(tài)，一旦JWT簽發(fā)，在有效期內(nèi)將會(huì)一直有效。
• JWT的有效期不宜設(shè)置太長(zhǎng)，認(rèn)證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。
• 為了減少JWT數(shù)據(jù)盜用和竊取的風(fēng)險(xiǎn)，JWT建議使用加密的HTTPS協(xié)議進(jìn)行傳輸。

^什么是 JWT，為什么要使用 JWT^

(https://www.youtube.com/watch?v=7Q17ubqLfaM&t=1s)

第 1 步：身份驗(yàn)證/授權(quán)

JWT 代表 JSON 網(wǎng)絡(luò)令牌。需要注意的是，JWT 用于授權(quán)而不是身份驗(yàn)證。所以你可能會(huì)問(wèn)有什么區(qū)別???身份驗(yàn)證是當(dāng)您第一次訪問(wèn) Web 服務(wù)器并使用用戶名和密碼登錄時(shí)。通過(guò)提供正確的用戶名和密碼，您將作為該用戶進(jìn)行身份驗(yàn)證。

一旦您通過(guò)身份驗(yàn)證，用戶就會(huì)被授予一個(gè)秘密。此密鑰用于 Web 服務(wù)器的每個(gè)后續(xù)操作。因此，在下一個(gè)請(qǐng)求中，您會(huì)將您的密鑰發(fā)送到 Web 服務(wù)器，它會(huì)驗(yàn)證該密鑰是否有效，以及它是否有權(quán)執(zhí)行請(qǐng)求的操作，即授權(quán)。然后讓我們繼續(xù)，JWT/OIDC Auth Method(https://www.vaultproject.io/docs/auth/jwt)詳細(xì)描述了該認(rèn)證。

第 2 步：生成 JWT

身份驗(yàn)證成功后，將為用戶生成一個(gè) JWT 令牌并由服務(wù)器簽名。此 JWT 被發(fā)送給用戶以存儲(chǔ)在其瀏覽器的緩存中。按照目前所描述的，您可能會(huì)認(rèn)為這與當(dāng)前使用的典型流程(即會(huì)話 ID)沒(méi)有什么不同。JWT 和會(huì)話 ID 實(shí)現(xiàn)之間的最大區(qū)別是 JWT 不需要服務(wù)器記住/存儲(chǔ)任何內(nèi)容。使用會(huì)話 ID，服務(wù)器必須為所有未來(lái)的請(qǐng)求記住/存儲(chǔ)該會(huì)話。JWT 包含有關(guān)用戶的所有必要信息，以便服務(wù)器為所有未來(lái)請(qǐng)求驗(yàn)證 JWT 令牌。

第 3 步：使用 JWT 進(jìn)行授權(quán)

JWT是一個(gè)base64編碼的blob，包含授權(quán)用戶所需的所有信息。如果解碼JWT，它將包含上面截圖中列出的部分，即標(biāo)header，payload以及signature。header部分定義了類(lèi)型(type)，即JWT，以及使用的加密/解密算法(alg)，即HS256。

payload部分包含一個(gè)主題(子)鍵值對(duì)，該鍵值對(duì)通常是用戶ID，iat代表發(fā)出，iat是生成令牌時(shí)的時(shí)間戳，最后，該部分可以包含與應(yīng)用程序相關(guān)的任何數(shù)據(jù)(名稱)，例如用戶名。此部分可以包含用戶名的鍵值對(duì)。但是，提到的鍵值對(duì)是最常見(jiàn)的。最后，我們有驗(yàn)證部分，用于確保發(fā)送的 JWT 有效。

1. Header： 用于說(shuō)明簽名的加密算法等，下面類(lèi)型的json經(jīng)過(guò)base64編碼后得到JWT頭部。

{  "typ": "JWT",  "alg": "HS256"}

2. Payload： 標(biāo)準(zhǔn)定義了7個(gè)字段，載荷json經(jīng)過(guò)base64編碼后得到JWT的載荷。

{ iss (issuer)：簽發(fā)人 exp (expiration time)：過(guò)期時(shí)間 sub (subject)：主題 aud (audience)：受眾 nbf (Not Before)：生效時(shí)間 iat (Issued At)：簽發(fā)時(shí)間 jti (JWT ID)：編號(hào)}

示例：

{    "sub": "1",    "iss": "http://localhost:8000/user/sign_up",    "iat": 1451888119,    "exp": 1454516119,    "nbf": 1451888119,    "jti": "37c107e4609ddbcc9c096ea5ee76c667"}

3.Signature： 將頭部和載荷用'.'號(hào)連接，再加上一串密鑰，經(jīng)過(guò)頭部聲明的加密算法加密后得到簽名。

HMACSHA256(    base64UrlEncode(header) + "." +    base64UrlEncode(payload),    secret)

了解Gitlab + Vault + JWT 授權(quán)

HashiCorp Vault GitLab 集成：為什么以及如何?(https://www.youtube.com/watch?v=VmQZwfgp3aA)

下面的步驟將對(duì)Gitlab，Vault，JWT CICD的流程進(jìn)行詳解。

第 0 步：創(chuàng)建 Gitlab 項(xiàng)目/存儲(chǔ)庫(kù)

正如我們將在下面的步驟說(shuō)明中看到的，您需要首先創(chuàng)建一個(gè)Gitlab repo/project。Gitlab為repo生成的project id(下圖所示)將用于指定 Vault 在該項(xiàng)目可以訪問(wèn)哪些密鑰信息。

第 1 步：配置 Vault 和密鑰

這聽(tīng)起來(lái)很直觀，但要訪問(wèn)密鑰，它們必須首先存在于 Vault 中。因此，用戶必須首先創(chuàng)建一個(gè) Vault 密鑰路徑并將項(xiàng)目的所有必要密鑰放置在那里。接下來(lái)，必須創(chuàng)建一個(gè)Vault policy來(lái)授予對(duì)這些密鑰的權(quán)限。

正如您在下圖中看到的那樣，該策略允許讀取和列出存儲(chǔ)在以下路徑中的密鑰：secrets/gitlab/project_1

最后，此策略必須附加到指定身份驗(yàn)證機(jī)制 (JWT) 和綁定聲明(稍后會(huì)詳細(xì)介紹)的 Vault 角色，該聲明可以訪問(wèn)附加策略中定義的那些密鑰。

步驟 2a：設(shè)置 Gitlab pipeline

接下來(lái)，我們需要配置一個(gè) Gitlab CI/CD 管道，使用.gitlab-ci.yml配置。首先，這個(gè)文件是在項(xiàng)目 repo 中定義的。雖然此配置可能是各式各樣的，但基本內(nèi)容將如下圖所示。首先在變量部分定義vault address、vault secret path和vault role。當(dāng) CI/CD 管道被觸發(fā)時(shí)，Gitlab 將生成一個(gè) JWT 作為以下環(huán)境變量傳遞給管道CI_JOB_JWT。

在接下來(lái)的部分中，我們將深入探討此配置的各個(gè)細(xì)節(jié)部分。但是，首先，此配置需求從 Vault 請(qǐng)求 Vault 令牌。接下來(lái)，如果請(qǐng)求成功，則返回一個(gè) Vault 令牌，Gitlab 運(yùn)行程序可以使用它來(lái)請(qǐng)求密鑰。

步驟 2b：生成 JWT

正如在上一節(jié)中所述，當(dāng)觸發(fā) CI/CD 管道時(shí)，會(huì)生成 JWT。讓我們看一下這個(gè) JSON 文檔，看看它是如何組成的。通常，Gitlab JWT 將包括 Gitlab 服務(wù)器、執(zhí)行管道作業(yè)的用戶、Gitlab 項(xiàng)目 ID、Vault 密鑰路徑和 Gitlab 作業(yè)詳細(xì)信息的信息。下圖顯示了一個(gè)生成并發(fā)送到 Vault 的示例 JWT 有效payload。

第 3 步和第 4 步：向 Vault 進(jìn)行身份驗(yàn)證 + Vault 驗(yàn)證 JWT

在本節(jié)中，我們將把第 3 步(向 Vault 驗(yàn)證)和第 4 步(Vault 驗(yàn)證 JWT)合并為一個(gè)部分。當(dāng) Vault 收到來(lái)自 Gitlab 的 JWT payload以及對(duì)機(jī)密的請(qǐng)求時(shí)，它需要驗(yàn)證 JWT。在下面的分步說(shuō)明中，我們將在 Vault 上啟用 JWT 身份驗(yàn)證，這需要bounder_issuer以及要提供的 JKWS 端點(diǎn)。

bound_issuer通常被設(shè)置為 Gitlab 的 FQDN，以指示 Vault“誰(shuí)”可以使用此身份驗(yàn)證方法并設(shè)置一個(gè)指向JKWS端點(diǎn)的URL，從而來(lái)指示 Vault“如何”驗(yàn)證 JWT。因此，當(dāng) Vault 收到 JWT 請(qǐng)求時(shí)，它會(huì)確保請(qǐng)求者已被批準(zhǔn)使用此身份驗(yàn)證方法，并且可以驗(yàn)證 JWT 的創(chuàng)建者。

為了驗(yàn)證 JWT，Vault 會(huì)提取bound_issuer/iss字段，通常是來(lái)自 JWT payload的 Gitlab 的 FQDN。接下來(lái)，Vault 對(duì)提取的字段進(jìn)行查找以獲取該字段的 JWKS 端點(diǎn)bound_issuer。Vault 使用 JKWS 端點(diǎn)驗(yàn)證簽名的 JWT payload，以確保 Gitlab 是請(qǐng)求的創(chuàng)建者。

例如，案例中 Gitlab 實(shí)例的 FQDN：gitlab.hackinglab.local。 正如您將在下面的分步說(shuō)明中看到的那樣，我設(shè)置bound_issuer到gitlab.hackinglab.local。并且 JWKS 端點(diǎn)設(shè)置為jwks_url = "https://gitlab.hackinglab.local/-/jwks"。

那么，這意味著什么?這意味著當(dāng) Vault 收到請(qǐng)求訪問(wèn)密鑰的 JWT 時(shí)，將提取iss應(yīng)該匹配的字段bound_issuer提供給Vault。接下來(lái)，Vault 將通過(guò)將 JWT 簽名與位于所提供的 JWKS 端點(diǎn)的簽名進(jìn)行比較來(lái)驗(yàn)證 JWT 簽名。

第 5 步：Vault檢測(cè)邊界聲明和附加策略

驗(yàn)證 JWT payload后，Vault 將提取試圖被假定的 Vault 角色。下面的 Vault 角色聲明它可以用于 JWT 身份驗(yàn)證，它具有g(shù)itlab-vault-readonly附加政策，以及bound_claims定義“誰(shuí)”的附加參數(shù)的部分可以承擔(dān)這個(gè)角色。

bound_claims部分指出必須滿足以下標(biāo)準(zhǔn)：只有 Gitlab project/repo project_id為2可以擔(dān)任此角色，并且僅構(gòu)建一個(gè) CI/CD 管道m(xù)aster主可以承擔(dān)這個(gè)角色。

如果JWT有效負(fù)載中包含的bound_claims符合此標(biāo)準(zhǔn)，則可以擔(dān)任此角色。最后，假設(shè)JWT包含此角色的必要條件，Vault將生成一個(gè)令牌。此Vault令牌將被授予擔(dān)任此角色的能力。

第 6 步和第 7 步：Vault 返回令牌 + Gitlab runner從 Vault 讀取密鑰

在本節(jié)中，我將把第 6 步(Vault 返回令牌)和第 7 步(Gitlab runner從 Vault 讀取密鑰)合并為一個(gè)部分。在上一節(jié)中，生成了一個(gè) Vault 令牌并將其返回給 Gitlab runner。

Gitlab runner可以使用此 Vault 令牌從 Vault 請(qǐng)求密鑰。如上所述，Vault 令牌被授予具有一組已定義策略的角色。當(dāng) Vault 收到訪問(wèn)密鑰的請(qǐng)求時(shí)，它將檢查附加到角色的策略，以確保它已被授予訪問(wèn)此密鑰的權(quán)限。

根據(jù)下圖，附加到此角色的策略授予對(duì)以下路徑的機(jī)密的 READ 和 LIST 權(quán)限：secrets/gitlab/project_1。那么這是什么意思?假設(shè) Gitlab runner正在嘗試讀取以下密鑰：secrets/gitlab/project_1/password，根據(jù)策略，它可以讀取該密鑰。

但是，假設(shè) Gitlab runner正在嘗試讀取以下密鑰：secrets/mysql_db/super_secret_db_passwrd，根據(jù)策略，它沒(méi)有讀取該密鑰的權(quán)限。

前提條件

• 為每個(gè)服務(wù)生成 DNS A 記錄
• 現(xiàn)有的 Gitlab 基礎(chǔ)環(huán)境
• 至少有一個(gè) Gitlab runner
• 預(yù)先部署好的 Vault服務(wù)

創(chuàng)建一個(gè) Gitlab 存儲(chǔ)庫(kù)

正如我在上面的“假設(shè)”部分所述，這篇博文假設(shè)你有一個(gè) Gitlab EE 實(shí)例正在運(yùn)行

• 登錄到 Gitlab
• 選擇左上角的“項(xiàng)目”
• 選擇“創(chuàng)建空白項(xiàng)目”

進(jìn)入Vault Gitlab作為項(xiàng)目名稱

選擇“創(chuàng)建項(xiàng)目”

• 選擇左上角的“項(xiàng)目概覽”
• 記錄項(xiàng)目ID

設(shè)置Vault

啟用 JWT 身份驗(yàn)證

• 使用 CLI 工具登錄 Vault
• curl -s -k -X GET https://gitlab.: 8443 ///jwks

測(cè)試 Gitlab JWT 身份驗(yàn)證

• 以管理員身份通過(guò) CLI 登錄 Vault
• echo | openssl s_client -connect gitlab.: 2 >& 1 | sed - ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/gitlab.crt

如果 Gitlab 由自簽名證書(shū)提供服務(wù)，請(qǐng)下拉證書(shū)

• vault auth enable jwt
• vault write auth/jwt/config jwks_url= "https://gitlab.:/-/jwks" bound_issuer= "gitlab." jwks_ca_pem= "$( cat /tmp/gitlab.crt) "

• Vault read auth/jwt/config

測(cè)試 Vault JWT 身份驗(yàn)證

創(chuàng)建密鑰

• vault secrets enable -version=2 -path=secrets kv啟用Vault服務(wù)
• vault kv put secrets/<secret path> <secret_key>=<secret_value>  

• vault kv get secrets/gitlab/project_1取回密碼

設(shè)置 Vault 以提供 Gitlab 對(duì)密鑰的訪問(wèn)權(quán)限

• Vault Policy

cd GitlabVaultCICD進(jìn)入相關(guān)目錄

cp conf/vault/policies/gitlab-vault-policy.hcl.example conf/vault/policies/gitlab-vault-policy.hcl

vim conf/vault/policies/gitlab-vault-policy.hcl并設(shè)置：

• {{ vault_secret_path }}將此設(shè)置為密鑰所在的 Vault 路徑

• vault policy write conf/vault/policies/gitlab-vault-policy.hcl

• 示例策略名稱：gitlab-vault-readonly

• Vault role

• 登錄到 Gitlab
• 瀏覽到您要授予對(duì) Vault 機(jī)密訪問(wèn)權(quán)限的 Gitlab 存儲(chǔ)庫(kù)
• 選擇左上角的“項(xiàng)目概覽”
• 獲取項(xiàng)目 ID

• cp conf/vault/roles/gitlab-jwt-role.json.example conf/vault/roles/gitlab-jwt-role.json
• vim conf/vault/roles/gitlab-jwt-role.json并設(shè)置：

a.{{ gitlab_project_id }}– 將此設(shè)置為項(xiàng)目 ID

• 上面的圖顯示了project_id 為 2

b.{{ gitlab_vault_role }}

• 上一節(jié)中 Vault 策略的名稱 – 使用gitlab-vault-readonly

• cat conf/vault/roles/gitlab-jwt-role.json | vault write auth/jwt/role/gitlab-vault-readonly -

.gitlab-ci.yml - 獲取 Vault 密鑰

• 登錄到 Gitlab
• 瀏覽到您要授予對(duì) Vault 機(jī)密訪問(wèn)權(quán)限的 Gitlab 存儲(chǔ)庫(kù)
• 選擇左上角的“項(xiàng)目概覽”
• 選擇“新建文件”

• VAULT_ADDR – 設(shè)置為 Vault 的 HTTP URL 地址
• {{vault_search_path}}– 設(shè)置為上面創(chuàng)建的 Vault 密鑰路徑
• {{gitlab_vault_role}} – 設(shè)置為上面為 Gitlab 創(chuàng)建的 Vault 角色

• 保存并退出
• 進(jìn)入.gitlab-ci.yml作為文件名
• 復(fù)制內(nèi)容conf/gitlab/gitlab-ci-example.yml.example進(jìn)入.gitlab-ci.yml并設(shè)置：

• 選擇左側(cè)的 CI/CD > 管道
• 選擇最新的管道作業(yè)

• 選擇Vault_secrets stage

總結(jié)：

HashiCorp Vault 是一個(gè)密鑰管理工具。與 Git 相比，Vault 的核心功能是以本機(jī)方式來(lái)處理機(jī)密信息的。所以對(duì)于配置密鑰信息來(lái)說(shuō)，使用 Vault 作為 Config Server 的后端存儲(chǔ)，是一種更好的選擇。

生產(chǎn)環(huán)境代碼泄露的危害，一方面是業(yè)務(wù)邏輯被不懷好意的人分析，容易被找出可利用的漏洞，當(dāng)然更危險(xiǎn)的是如果代碼里面有一些明文存儲(chǔ)secrets、Token、Api Key等，這些內(nèi)容被別人拿到，服務(wù)就很容易遭到致命的攻擊，給我們帶來(lái)不可估量的損失 。所以合理存儲(chǔ)程序中的secrets是十分有必要的。

本文也主要介紹了如何使用Vault對(duì)基于Gitlab的CICD流程的加密。另外Vault的場(chǎng)景也是非常廣泛的。本文的目的也僅僅是拋磚引玉，通過(guò)本文，你可以了解如下的知識(shí)點(diǎn)。

• 了解 JWT 授權(quán)的工作原理
• 了解授權(quán)和認(rèn)證的區(qū)別
• 如何從 Vault 為 Gitlab CI/CD 管道請(qǐng)求密鑰
• 如何設(shè)置 Vault JWT 身份驗(yàn)證方法
• 如何創(chuàng)建一個(gè) .gitlab-ci.yml配置

參考：

在 docker-compose 替換 NGINX 配置中的環(huán)境變量(https://stackoverflow.com/questions/56649582/substitute-environment-variables-in-nginx-config-from-docker-compose)

在 GNU/Linux 上手動(dòng)安裝 GitLab Runner(https://docs.gitlab.com/runner/install/linux-manually.html)

在 Windows 10 上安裝 Hyper-V(https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/quick-start/enable-hyper-v)

使用 openssl 從服務(wù)器獲取證書(shū)(http://using%20openssl%20to%20get%20the%20certificate%20from%20a%20server/)

Vaults – JWT/OIDC 身份驗(yàn)證方法(https://www.vaultproject.io/docs/auth/jwt)

Youtube – HashiCorp Vault GitLab 集成：為什么以及如何?(https://www.youtube.com/watch?v=VmQZwfgp3aA)

Youtube – 什么是 JWT，為什么要使用 JWT(https://www.youtube.com/watch?v=7Q17ubqLfaM&t=2s)

原文：https://holdmybeersecurity.com/2021/03/04/gitlab-ci-cd-pipeline-with-vault-secrets/