(接上文)如何使用Vault 存儲和共享機密添加身份驗證方法我們將使用用戶名和密碼進行身份驗證。默認情況下,它是禁用的,因此我們必須啟用它。但在此之前,我們應該使用之前生成的根令牌登錄Vault:
屏幕截圖4. 登錄Vault
現在,我們可以更改身份驗證方法和其他受保護的服務器部分。讓我們添加身份驗證方法:
如果您使用Web UI 而不是命令行,請按照以下路徑啟用身份驗證方法:訪問-身份驗證方法-啟用新方法-用戶名和密碼-下一步-啟用方法。我們不會在這裡更改任何設置,因此您可以保持原樣。
屏幕截圖5. 方法驗證
現在我們已經設置了用戶名和密碼身份驗證,讓我們添加一個秘密引擎。
添加秘密引擎默認情況下,Vault 僅啟用cubbyhole 作為秘密引擎。至少,它是我們可以用來存儲數據的唯一引擎。我們可以通過運行以下命令來檢查:
屏幕截圖6. Secrets Engines 選項卡
該引擎允許我們包裝和解開我們的秘密以安全地共享它們。包裝意味著生成一個具有可配置生存時間(TTL) 的一次性令牌,該令牌引用了我們的秘密。這個秘密只存在於我們的小房間裡,直到令牌被打開或過期。
您可以將cubbyhole 視為一個鍵值對,其中一次性令牌是鍵。它使我們能夠安全地共享收件人無法訪問的內容,而無需授予他們永久訪問權限。這是一種簡單、快速且可靠的方式來發送我們不希望以明文形式發送的數據。
然而,Cubbyhole 提供了一種臨時且短期的秘密共享方式。這就是我們要添加鍵值引擎的原因。與cubbyhole 一樣,它遵循鍵值邏輯,但它允許我們創建、讀取、更新和刪除鍵值對。 KV 引擎適用於秘密、配置數據或任何其他結構化鍵值信息的長期存儲和管理。
讓我們添加一個鍵值秘密引擎:
按照以下路徑啟用鍵值秘密引擎:Secrets-Enable new engine-KV。然後,將Path更改為kv-engine並選擇Enable Engine。
屏幕截圖7. 啟用KV Secrets 引擎
我們將使用鍵值引擎的第二個版本。此版本具有一些附加功能,包括秘密的版本控制和恢復已刪除的秘密。
現在我們可以添加策略,允許用戶使用我們的新秘密引擎存儲和讀取秘密。
添加策略我們需要遵循最小特權原則的政策。該原則規定,實體(用戶、組等)只能訪問完成特定任務所需的資源。
例如,開發人員應該有權訪問API 密鑰或開發中所需的其他憑據。另一方面,DevOps 專家需要雲託管平台的憑據,但他們不應該能夠訪問所有其他秘密,因為這會增加秘密洩露的可能性。通過添加特定於應用程序的訪問權限,我們可以將訪問控制遊戲提升到一個新的水平。我們的服務器可能需要數據庫憑據,但我們的應用程序不需要。
基本上,策略只是命名為訪問控制列表(ACL)。在此示例中,我們希望用戶將機密存儲在自己的目錄中,任何其他用戶都無法訪問該目錄。
為此,我們將使用ACL 模板。我們可以在策略中使用雙花括號作為模板分隔符。有一些可用的模板參數;您可以在ACL 策略路徑模板頁面上閱讀有關它們的更多信息。
在添加策略之前,讓我們找出新身份驗證方法的標識符,以便在模板中使用它。
我們可以通過運行以下命令來做到這一點:
您可以在訪問器列中看到標識符。通過訪問-身份驗證方法找到身份驗證方法。
屏幕截圖8. 身份驗證方法
現在我們可以創建一個策略:
替換ACCESSOR 為我們在上一步中獲得的標識符。
此策略將允許我們的用戶在其主目錄中創建、讀取、刪除、列出和更新機密。我們將使用策略路徑模板來利用策略規則中的身份參數。這將使我們能夠根據身份驗證時返回給我們的用戶身份屬性來微調訪問控制。
這些屬性可以是任何內容:用戶的角色、用戶名、電子郵件地址、組成員身份等。根據屬性,我們將能夠授予不同級別的訪問權限,從而遵守最小權限原則。
在此示例中,我們使用用戶使用用戶名和密碼身份驗證成功進行身份驗證時返回的名稱。
注意data後面的前綴kv-engine。這是第二版的鍵值存儲中實際數據的存儲位置。裡面還有其他幾個路徑kv-engine,包括metadata和delete。您可以在HashiCorp 文檔中閱讀有關KV Secrets 引擎的更多信息。
此外,我們還添加了元數據路徑的規則。此規則允許我們的用戶列出其文件夾內所有存儲的密鑰。此外,我們還為每個用戶添加了列出kv-engine路徑內容的權限,以便更輕鬆地使用Web UI 進行導航。該規則不允許用戶讀取kv-engine內文件夾的內容- 只能查看它們。
讓我們保存我們的政策:
進入策略-創建ACL 策略創建ACL 策略:
屏幕截圖9. 創建ACL 策略
現在我們擁有一個功能齊全的系統,具有ACL 策略和身份驗證。讓我們嘗試一下。
使用鍵值引擎存儲和讀取機密現在我們已經添加了身份驗證方法,我們可以創建一個新用戶。這個過程相當簡單:
按照UI 中的以下路徑創建用戶: Access-AuthMethods-userpass-Create user。輸入用戶名和密碼,然後添加我們在令牌下拉菜單內的生成令牌的策略部分中創建的策略。
屏幕截圖10. 創建用戶
我們創建了一個用戶名user和密碼1234的用戶。我們還將此用戶分配給我們創建的策略。
現在我們可以以新用戶身份登錄:
要在Web UI 中執行此操作,請使用右上角的下拉菜單從root 帳戶註銷,然後選擇用戶名身份驗證方法並輸入我們的用戶名和密碼。
截圖11.通過用戶名/密碼認證方式登錄
現在讓我們在主目錄中添加一些內容:
按照以下路徑創建密鑰:Secrets-kv-engine/-Create Secret。
屏幕截圖12. 創建秘密
我們可以通過運行以下命令來確認我們的秘密已添加:
要使用Vault 的UI 在KV 引擎中查找您的密鑰,請按照以下路徑操作:Secrets-kv-engine/-user/。
屏幕截圖13. Secret 添加到KV 引擎
偉大的!一切正常。讓我們嘗試閱讀我們剛剛添加的秘密:
按照以下路徑讀取KV 引擎中的Secret:Secrets-kv-engine/-user/-my-secret。
屏幕截圖14. 讀取KV 引擎中的秘密
讓我們通過嘗試在用戶主目錄之外保存新的機密來驗證我們的策略是否有效:
按照以下路徑嘗試創建秘密:Secrets-kv-engine/-Create Secret。
屏幕截圖15. 嘗試在用戶主目錄之外創建機密失敗
用戶無法在其主目錄之外讀取或存儲機密,就像我們預期的那樣。
使用cubbyhole 引擎實現安全的秘密共享讓我們嘗試一下cubbyhole 秘密引擎。為了共享秘密,我們可以使用Vault 的cubbyhole 響應包裝。讀取秘密時,我們可以添加一個參數,告訴秘密引擎將該秘密包裝在一次性令牌中,稍後可以將其解開:
要將您的密鑰包裝在一次性令牌中,請按照以下路徑操作:Secrets-kv-engine/-user/-my-secret-Copy-Wrap Secret。然後,複製生成的令牌。
屏幕截圖16. 將秘密包裝在令牌中
輸出包含一個包裝令牌,我們稍後可以使用它來解開秘密。指定的參數告訴cubbyhole 創建的令牌的有效時間(以秒為單位)。在我們的例子中,令牌將在接下來的十分鐘內有效。
讓我們打開它:
$vaultunwrap$WRAPPING_TOKEN
KeyValue
--------
datamap[importantValue:secret]
metadatamap[created_time:2022-12-29T16:18:45.076362889Zcustom_metadata:nildeletion_time:destroyed:falseversion:1]按照以下路徑解包令牌:工具- 解包。然後,粘貼WRAPPING_TOKEN。
屏幕截圖17. 解開令牌
正如你所看到的,我們成功地檢索到了秘密。該令牌可以與任何用戶共享,使我們能夠安全地共享秘密,而無需以明文形式發送它們。
但是,如果我們不想一遍又一遍地複制秘密只是為了與人們分享怎麼辦?有一個解決方案。
使用策略動態共享秘密目前,我們只能通過使用cubbyhole 秘密引擎包裝秘密來共享秘密。雖然它肯定比以明文形式發送它們更好,但它仍然需要我們手動包裝和發送秘密。如果我們可以共享現有的秘密而不復制它怎麼辦?
我們之前實施的政策可以幫助我們動態共享。讓我們看看如何實現它。
首先,讓我們創建另一個我們想要與之分享秘密的用戶:
要創建新用戶,請遵循以下路徑:Access-AuthMethods-userpass-Create user。
屏幕截圖18. 創建新用戶帳戶
現在,我們希望該用戶能夠讀取kv-engine/data/user/my-secret中的秘密。我們可以添加另一個策略,允許我們的第二個用戶讀取這個秘密:
我們還可以賦予該用戶更改、刪除該機密或對其執行任何操作的能力。在某些情況下,您可能也想使用這些訪問權限。
現在我們應該保存這個策略,就像我們之前做的那樣:
您可以在此處創建另一個策略:策略-創建ACL 策略。
屏幕截圖19. 創建策略
最後,我們將新策略添加到user2:
您可以在此處編輯您的user2 :訪問-身份驗證方法-用戶密碼-user2-編輯用戶。然後,在令牌下拉菜單內的生成令牌的策略部分中添加新策略。
屏幕截圖20. 將策略添加到user2
向現有用戶添加新策略時,添加舊策略也很重要,因為我們會覆蓋用戶擁有的所有策略。在我們的例子中,我們還應該包括一個模板策略。
讓我們以該用戶身份登錄並檢查我們的策略是否有效:
屏幕截圖21. 以user2 身份登錄Vault
您可以在這裡找到秘密:Secrets-kv-engine/-user/-my-secret。