建站
咨詢
售后
建站咨詢
新聞中心
目的
在 Vault 上啟用 JWT 身份驗(yàn)證方法
成都創(chuàng)新互聯(lián)2013年開創(chuàng)至今，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都網(wǎng)站建設(shè)、網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元吳川做網(wǎng)站,已為上家服務(wù),為吳川各地企業(yè)和個人服務(wù),聯(lián)系電話:028-86922220
利用 JWT 授權(quán)從 Vault 中讀取密鑰以進(jìn)行 Gitlab CI/CD 作業(yè)
背景
什么是 Gitlab?
GitLab 是一個基于 Web 的 DevOps 生命周期工具 ，它提供了一個 Git 代碼存儲庫管理，同時它使用 GitLab Inc 開發(fā)的開源許可證提供 wiki、問題跟蹤以及持續(xù)集成和pipeline的功能。
在學(xué)習(xí)Gitlab的定義之前，首先需要了解一些術(shù)語?？赡苣?jīng)常遇到像Git，Gitlab，GitHub和Bitbucket這樣的術(shù)語。
Git - 它是一個源代碼版本控制系統(tǒng)，可讓您在本地跟蹤更改并從遠(yuǎn)程資源推送或提取更改。 GitLab ，GitHub和Bitbucket - 提供遠(yuǎn)程訪問Git存儲庫的服務(wù)。除了托管代碼之外，這些服務(wù)還提供用來幫助管理軟件開發(fā)生命周期的附加功能。這些附加功能包括管理不同人之間的代碼共享，錯誤跟蹤，wiki空間和其他“社交編碼”工具。
- GitHub 是一項(xiàng)公開可用的免費(fèi)服務(wù)，它要求所有代碼(除非您有付費(fèi)帳戶)公開。任何人都可以看到您推送給GitHub的代碼并提供改進(jìn)建議。GitHub目前承載數(shù)以萬計的開源項(xiàng)目的源代碼。
- GitLab是一種類似github的服務(wù)，組織可以使用它來提供git存儲庫的內(nèi)部管理。它是一個自我托管的Git-repository管理系統(tǒng)，可以保持用戶代碼的私密性，并且可以輕松地部署代碼的更改。
GitLab是集中服務(wù)器上管理git存儲庫的一個好方法。GitLab讓您可以完全控制您的存儲庫或項(xiàng)目，并允許您自己決定是公共還是私有。
什么是HashiCorp Vault?
在企業(yè)級應(yīng)用開發(fā)過程中，團(tuán)隊每時每刻都需要管理各種各樣的私密信息，從個人的登陸密碼、到生產(chǎn)環(huán)境的SSH Key以及數(shù)據(jù)庫登錄信息、API認(rèn)證信息等。通常的做法是將這些秘密信息保存在某個文件中，并且放置到git之類的源代碼管理工具中。個人和應(yīng)用可以通過拉取倉庫來訪問這些信息。但這種方式弊端很多，比如跨團(tuán)隊分享存在安全隱患、文件格式難以維護(hù)、私密信息難以回收等。
尤其是微服務(wù)大行其道的今天，如何讓開發(fā)者添加私密信息、應(yīng)用程序能輕松的獲取私密信息、采用不同策略更新私密信息、適時回收私密信息等變得越來越關(guān)鍵。所以企業(yè)需要一套統(tǒng)一的接口來處理私密信息的方方面面，而HashiCorp Vault就是這樣的一款工具。
Vault 是 hashicorp 推出的 secrets 管理、加密即服務(wù)與權(quán)限管理工具。
它提供了這些功能：
- 集中管理各種私密信息;
- 為私密信息設(shè)置租期(Lease)，到期后自動失效;
- 密鑰的動態(tài)生成、注銷和滾動更新;
- 動態(tài)創(chuàng)建無需保存的一次性登錄密鑰;
- 作為數(shù)據(jù)加密/解密接口;
- 完整的審計記錄;
- 命令行 以及 RESTful API 訪問接口;
Valut存儲私密信息
不僅可以存放現(xiàn)有的私密信息，還可以動態(tài)生成用于管理第三方資源的私密信息。所有存放的數(shù)據(jù)都是加密的。任何動態(tài)生成的私密信息都有租期，并且到期會自動回收。
滾動更新秘鑰
用戶可以隨時更新存放的私密信息。Vault提供了加密即服務(wù)(encryption-as-a-service)的功能，可以隨時將密鑰滾動到新的密鑰版本，同時保留對使用過去密鑰版本加密的值進(jìn)行解密的能力。對于動態(tài)生成的秘密，可配置的最大租賃壽命確保密鑰滾動易于實(shí)施。
審計日志
保管庫存儲所有經(jīng)過身份驗(yàn)證的客戶端交互的詳細(xì)審核日志：身份驗(yàn)證，令牌創(chuàng)建，私密信息訪問，私密信息撤銷等?？梢詫徍巳罩景l(fā)送到多個后端以確保冗余副本。
另外，HaishiCorp Vault提供了多種方式來管理私密信息。用戶可以通過命令行、HTTP API等集成到應(yīng)用中來獲取私密信息。HashiCorp Vault也能與Ansible、Chef、Consul等DevOps工具鏈無縫結(jié)合使用。
什么是 CI/CD?
CI/CD 自動化了將代碼從開發(fā)人員機(jī)器交付到生產(chǎn)環(huán)境的過程。雖然只有短短數(shù)語，但如上圖所示，該流程本質(zhì)上包含很多步驟的。本節(jié)將詳細(xì)描述該過程。CI/CD 代表持續(xù)集成和持續(xù)部署，正如上面縮寫以及圖所示，這是兩個不同的階段。持續(xù)集成是集成代碼更改的過程，驗(yàn)證新代碼更改仍然可以構(gòu)建/編譯應(yīng)用程序，并確保新代碼通過一組測試。
縮略詞 CI / CD 具有幾個不同的含義。CI/CD 中的"CI"始終指持續(xù)集成，它屬于開發(fā)人員的自動化流程。成功的 CI 意味著應(yīng)用代碼的新更改會定期構(gòu)建、測試并合并到共享存儲庫中。該解決方案可以解決在一次開發(fā)中有太多應(yīng)用分支，從而導(dǎo)致相互沖突的問題。
CI/CD 中的"CD"指的是持續(xù)交付和/或持續(xù)部署，這些相關(guān)概念有時會交叉使用。兩者都事關(guān)管道后續(xù)階段的自動化，但它們有時也會單獨(dú)使用，用于說明自動化程度。
持續(xù)交付通常是指開發(fā)人員對應(yīng)用的更改會自動進(jìn)行錯誤測試并上傳到存儲庫(如 GitHub 或Gitlab)，然后由運(yùn)維團(tuán)隊將其部署到實(shí)時生產(chǎn)環(huán)境中。這旨在解決開發(fā)和運(yùn)維團(tuán)隊之間可見性及溝通較差的問題。因此，持續(xù)交付的目的就是確保盡可能減少部署新代碼時所需的工作量。
例如，假設(shè)您有一個用 GoLang 編寫的 Web 應(yīng)用程序。作為開發(fā)人員，您對本地開發(fā)機(jī)器上的現(xiàn)有應(yīng)用程序進(jìn)行一些更改，并將更改推送到 Gitlab。接下來，Gitlab 將嘗試使用您的更改編譯現(xiàn)有代碼庫。假設(shè)編譯成功，Gitlab 將對新編譯的代碼進(jìn)行多次測試，以確保應(yīng)用程序按預(yù)期運(yùn)行。如果測試成功，開發(fā)人員可以將更改合并到 MAIN 分支中。
現(xiàn)在你可能會問如果這個階段不成功會發(fā)生什么?使用上面的示例，假設(shè)您初始化了一個未使用的變量。如果您是 GoLang 開發(fā)人員，您已經(jīng)知道這將無法編譯，但對于本示例，假設(shè)代碼已推送到 Gitlab。Gitlab 將再次嘗試編譯包含您的更改的代碼。但是，編譯將失敗，并且通常管道將在第一次出現(xiàn)錯誤時停止運(yùn)行。Gitlab 將為開發(fā)人員提供審查產(chǎn)生的錯誤的能力。在解決此問題之前，Gitlab 將不允許合并新代碼。
持續(xù)部署是再次評估/測試新提交的代碼的過程，將應(yīng)用程序推送給 QA 以進(jìn)行進(jìn)一步評估，最后在人工交互后將代碼推送到生產(chǎn)環(huán)境。推送到產(chǎn)線(生產(chǎn))意味著將您的代碼推送到環(huán)境中，以便用戶可以使用您的新代碼。同樣，正如上面的圖表所示，此過程還有更多內(nèi)容，但希望讀者能夠去了解更多的關(guān)于CICD的過程。
了解 JWT 授權(quán)
JSON Web Token (JWT)是目前最流行的跨域身份驗(yàn)證解決方案。簡單說，OAuth 就是一種授權(quán)機(jī)制。數(shù)據(jù)的所有者告訴系統(tǒng)，同意授權(quán)第三方應(yīng)用進(jìn)入系統(tǒng)，獲取這些數(shù)據(jù)。系統(tǒng)從而產(chǎn)生一個短期的進(jìn)入令(token)，用來代替密碼，供第三方應(yīng)用使用。
傳統(tǒng)的授權(quán)認(rèn)證方式，需要持久化session數(shù)據(jù)，寫入數(shù)據(jù)庫或文件持久層等，且授權(quán)校驗(yàn)依賴于數(shù)據(jù)持久層。這樣的方式，對于結(jié)構(gòu)維護(hù)成本大，實(shí)現(xiàn)單點(diǎn)登錄較為復(fù)雜，且沒有分布式架構(gòu)，無法支持橫向擴(kuò)展，風(fēng)險較大(如果持久層失敗，整個認(rèn)證體系都會掛掉)。
JWT則無須持久化會話數(shù)據(jù)，是以加密簽名的方式實(shí)現(xiàn)了用戶身份認(rèn)證授權(quán)，很好的解決了跨域身份驗(yàn)證，分布式session共享、單點(diǎn)登錄和橫向擴(kuò)展等問題。另外，需要注意JWT：
- JWT默認(rèn)不加密，但可以加密。生成原始令牌后，可以使用改令牌再次對其進(jìn)行加密。
- JWT不僅可用于認(rèn)證，還可用于信息交換。善用JWT有助于減少服務(wù)器請求數(shù)據(jù)庫的次數(shù)。
- JWT的最大缺點(diǎn)是服務(wù)器不保存會話狀態(tài)，一旦JWT簽發(fā)，在有效期內(nèi)將會一直有效。
- JWT的有效期不宜設(shè)置太長，認(rèn)證信息，因此一旦信息泄露，任何人都可以獲得令牌的所有權(quán)限。
- 為了減少JWT數(shù)據(jù)盜用和竊取的風(fēng)險，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)證。所以你可能會問有什么區(qū)別???身份驗(yàn)證是當(dāng)您第一次訪問 Web 服務(wù)器并使用用戶名和密碼登錄時。通過提供正確的用戶名和密碼，您將作為該用戶進(jìn)行身份驗(yàn)證。
一旦您通過身份驗(yàn)證，用戶就會被授予一個秘密。此密鑰用于 Web 服務(wù)器的每個后續(xù)操作。因此，在下一個請求中，您會將您的密鑰發(fā)送到 Web 服務(wù)器，它會驗(yàn)證該密鑰是否有效，以及它是否有權(quán)執(zhí)行請求的操作，即授權(quán)。然后讓我們繼續(xù)，JWT/OIDC Auth Method(https://www.vaultproject.io/docs/auth/jwt)詳細(xì)描述了該認(rèn)證。
第 2 步：生成 JWT
身份驗(yàn)證成功后，將為用戶生成一個 JWT 令牌并由服務(wù)器簽名。此 JWT 被發(fā)送給用戶以存儲在其瀏覽器的緩存中。按照目前所描述的，您可能會認(rèn)為這與當(dāng)前使用的典型流程(即會話 ID)沒有什么不同。JWT 和會話 ID 實(shí)現(xiàn)之間的最大區(qū)別是 JWT 不需要服務(wù)器記住/存儲任何內(nèi)容。使用會話 ID，服務(wù)器必須為所有未來的請求記住/存儲該會話。JWT 包含有關(guān)用戶的所有必要信息，以便服務(wù)器為所有未來請求驗(yàn)證 JWT 令牌。
第 3 步：使用 JWT 進(jìn)行授權(quán)
JWT是一個base64編碼的blob，包含授權(quán)用戶所需的所有信息。如果解碼JWT，它將包含上面截圖中列出的部分，即標(biāo)header，payload以及signature。header部分定義了類型(type)，即JWT，以及使用的加密/解密算法(alg)，即HS256。
payload部分包含一個主題(子)鍵值對，該鍵值對通常是用戶ID，iat代表發(fā)出，iat是生成令牌時的時間戳，最后，該部分可以包含與應(yīng)用程序相關(guān)的任何數(shù)據(jù)(名稱)，例如用戶名。此部分可以包含用戶名的鍵值對。但是，提到的鍵值對是最常見的。最后，我們有驗(yàn)證部分，用于確保發(fā)送的 JWT 有效。
1. Header： 用于說明簽名的加密算法等，下面類型的json經(jīng)過base64編碼后得到JWT頭部。
{ "typ": "JWT", "alg": "HS256"}
2. Payload： 標(biāo)準(zhǔn)定義了7個字段，載荷json經(jīng)過base64編碼后得到JWT的載荷。
{ iss (issuer)：簽發(fā)人 exp (expiration time)：過期時間 sub (subject)：主題 aud (audience)：受眾 nbf (Not Before)：生效時間 iat (Issued At)：簽發(fā)時間 jti (JWT ID)：編號}
示例：
{ "sub": "1", "iss": "http://localhost:8000/user/sign_up", "iat": 1451888119, "exp": 1454516119, "nbf": 1451888119, "jti": "37c107e4609ddbcc9c096ea5ee76c667"}
3.Signature： 將頭部和載荷用'.'號連接，再加上一串密鑰，經(jīng)過頭部聲明的加密算法加密后得到簽名。
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
了解Gitlab + Vault + JWT 授權(quán)
HashiCorp Vault GitLab 集成：為什么以及如何?(https://www.youtube.com/watch?v=VmQZwfgp3aA)
下面的步驟將對Gitlab，Vault，JWT CICD的流程進(jìn)行詳解。
第 0 步：創(chuàng)建 Gitlab 項(xiàng)目/存儲庫
正如我們將在下面的步驟說明中看到的，您需要首先創(chuàng)建一個Gitlab repo/project。Gitlab為repo生成的project id(下圖所示)將用于指定 Vault 在該項(xiàng)目可以訪問哪些密鑰信息。
第 1 步：配置 Vault 和密鑰
這聽起來很直觀，但要訪問密鑰，它們必須首先存在于 Vault 中。因此，用戶必須首先創(chuàng)建一個 Vault 密鑰路徑并將項(xiàng)目的所有必要密鑰放置在那里。接下來，必須創(chuàng)建一個Vault policy來授予對這些密鑰的權(quán)限。
正如您在下圖中看到的那樣，該策略允許讀取和列出存儲在以下路徑中的密鑰：secrets/gitlab/project_1
最后，此策略必須附加到指定身份驗(yàn)證機(jī)制 (JWT) 和綁定聲明(稍后會詳細(xì)介紹)的 Vault 角色，該聲明可以訪問附加策略中定義的那些密鑰。
步驟 2a：設(shè)置 Gitlab pipeline
接下來，我們需要配置一個 Gitlab CI/CD 管道，使用.gitlab-ci.yml配置。首先，這個文件是在項(xiàng)目 repo 中定義的。雖然此配置可能是各式各樣的，但基本內(nèi)容將如下圖所示。首先在變量部分定義vault address、vault secret path和vault role。當(dāng) CI/CD 管道被觸發(fā)時，Gitlab 將生成一個 JWT 作為以下環(huán)境變量傳遞給管道CI_JOB_JWT。
在接下來的部分中，我們將深入探討此配置的各個細(xì)節(jié)部分。但是，首先，此配置需求從 Vault 請求 Vault 令牌。接下來，如果請求成功，則返回一個 Vault 令牌，Gitlab 運(yùn)行程序可以使用它來請求密鑰。
步驟 2b：生成 JWT
正如在上一節(jié)中所述，當(dāng)觸發(fā) CI/CD 管道時，會生成 JWT。讓我們看一下這個 JSON 文檔，看看它是如何組成的。通常，Gitlab JWT 將包括 Gitlab 服務(wù)器、執(zhí)行管道作業(yè)的用戶、Gitlab 項(xiàng)目 ID、Vault 密鑰路徑和 Gitlab 作業(yè)詳細(xì)信息的信息。下圖顯示了一個生成并發(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)合并為一個部分。當(dāng) Vault 收到來自 Gitlab 的 JWT payload以及對機(jī)密的請求時，它需要驗(yàn)證 JWT。在下面的分步說明中，我們將在 Vault 上啟用 JWT 身份驗(yàn)證，這需要bounder_issuer以及要提供的 JKWS 端點(diǎn)。
bound_issuer通常被設(shè)置為 Gitlab 的 FQDN，以指示 Vault“誰”可以使用此身份驗(yàn)證方法并設(shè)置一個指向JKWS端點(diǎn)的URL，從而來指示 Vault“如何”驗(yàn)證 JWT。因此，當(dāng) Vault 收到 JWT 請求時，它會確保請求者已被批準(zhǔn)使用此身份驗(yàn)證方法，并且可以驗(yàn)證 JWT 的創(chuàng)建者。
為了驗(yàn)證 JWT，Vault 會提取bound_issuer/iss字段，通常是來自 JWT payload的 Gitlab 的 FQDN。接下來，Vault 對提取的字段進(jìn)行查找以獲取該字段的 JWKS 端點(diǎn)bound_issuer。Vault 使用 JKWS 端點(diǎn)驗(yàn)證簽名的 JWT payload，以確保 Gitlab 是請求的創(chuàng)建者。
例如，案例中 Gitlab 實(shí)例的 FQDN：gitlab.hackinglab.local。 正如您將在下面的分步說明中看到的那樣，我設(shè)置bound_issuer到gitlab.hackinglab.local。并且 JWKS 端點(diǎn)設(shè)置為jwks_url = "https://gitlab.hackinglab.local/-/jwks"。
那么，這意味著什么?這意味著當(dāng) Vault 收到請求訪問密鑰的 JWT 時，將提取iss應(yīng)該匹配的字段bound_issuer提供給Vault。接下來，Vault 將通過將 JWT 簽名與位于所提供的 JWKS 端點(diǎn)的簽名進(jìn)行比較來驗(yàn)證 JWT 簽名。
第 5 步：Vault檢測邊界聲明和附加策略
驗(yàn)證 JWT payload后，Vault 將提取試圖被假定的 Vault 角色。下面的 Vault 角色聲明它可以用于 JWT 身份驗(yàn)證，它具有g(shù)itlab-vault-readonly附加政策，以及bound_claims定義“誰”的附加參數(shù)的部分可以承擔(dān)這個角色。
bound_claims部分指出必須滿足以下標(biāo)準(zhǔn)：只有 Gitlab project/repo project_id為2可以擔(dān)任此角色，并且僅構(gòu)建一個 CI/CD 管道m(xù)aster主可以承擔(dān)這個角色。
如果JWT有效負(fù)載中包含的bound_claims符合此標(biāo)準(zhǔn)，則可以擔(dān)任此角色。最后，假設(shè)JWT包含此角色的必要條件，Vault將生成一個令牌。此Vault令牌將被授予擔(dān)任此角色的能力。
第 6 步和第 7 步：Vault 返回令牌 + Gitlab runner從 Vault 讀取密鑰
在本節(jié)中，我將把第 6 步(Vault 返回令牌)和第 7 步(Gitlab runner從 Vault 讀取密鑰)合并為一個部分。在上一節(jié)中，生成了一個 Vault 令牌并將其返回給 Gitlab runner。
Gitlab runner可以使用此 Vault 令牌從 Vault 請求密鑰。如上所述，Vault 令牌被授予具有一組已定義策略的角色。當(dāng) Vault 收到訪問密鑰的請求時，它將檢查附加到角色的策略，以確保它已被授予訪問此密鑰的權(quán)限。
根據(jù)下圖，附加到此角色的策略授予對以下路徑的機(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ù)策略，它沒有讀取該密鑰的權(quán)限。
前提條件
- 為每個服務(wù)生成 DNS A 記錄
- 現(xiàn)有的 Gitlab 基礎(chǔ)環(huán)境
- 至少有一個 Gitlab runner
- 預(yù)先部署好的 Vault服務(wù)
創(chuàng)建一個 Gitlab 存儲庫
正如我在上面的“假設(shè)”部分所述，這篇博文假設(shè)你有一個 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
測試 Gitlab JWT 身份驗(yàn)證
- 以管理員身份通過 CLI 登錄 Vault
- echo | openssl s_client -connect gitlab.: 2 >& 1 | sed - ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /tmp/gitlab.crt
如果 Gitlab 由自簽名證書提供服務(wù)，請下拉證書
- 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
測試 Vault JWT 身份驗(yàn)證
創(chuàng)建密鑰
- vault secrets enable -version=2 -path=secrets kv啟用Vault服務(wù)
- vault kv put secrets/
=
- vault kv get secrets/gitlab/project_1取回密碼
設(shè)置 Vault 以提供 Gitlab 對密鑰的訪問權(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
- 瀏覽到您要授予對 Vault 機(jī)密訪問權(quán)限的 Gitlab 存儲庫
- 選擇左上角的“項(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
- 瀏覽到您要授予對 Vault 機(jī)密訪問權(quán)限的 Gitlab 存儲庫
- 選擇左上角的“項(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 是一個密鑰管理工具。與 Git 相比，Vault 的核心功能是以本機(jī)方式來處理機(jī)密信息的。所以對于配置密鑰信息來說，使用 Vault 作為 Config Server 的后端存儲，是一種更好的選擇。
生產(chǎn)環(huán)境代碼泄露的危害，一方面是業(yè)務(wù)邏輯被不懷好意的人分析，容易被找出可利用的漏洞，當(dāng)然更危險的是如果代碼里面有一些明文存儲secrets、Token、Api Key等，這些內(nèi)容被別人拿到，服務(wù)就很容易遭到致命的攻擊，給我們帶來不可估量的損失 。所以合理存儲程序中的secrets是十分有必要的。
本文也主要介紹了如何使用Vault對基于Gitlab的CICD流程的加密。另外Vault的場景也是非常廣泛的。本文的目的也僅僅是拋磚引玉，通過本文，你可以了解如下的知識點(diǎn)。
- 了解 JWT 授權(quán)的工作原理
- 了解授權(quán)和認(rèn)證的區(qū)別
- 如何從 Vault 為 Gitlab CI/CD 管道請求密鑰
- 如何設(shè)置 Vault JWT 身份驗(yàn)證方法
- 如何創(chuàng)建一個 .gitlab-ci.yml配置
參考：
在 docker-compose 替換 NGINX 配置中的環(huán)境變量(https://stackoverflow.com/questions/56649582/substitute-environment-variables-in-nginx-config-from-docker-compose)
在 GNU/Linux 上手動安裝 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ù)器獲取證書(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/
網(wǎng)站名稱：使用Vault加密的GITLABCICDPipeline
文章URL：http://fisionsoft.com.cn/article/cdedece.html
