GSS 技術部落格
在這個園地裡我們將從技術、專案管理、客戶對談面和大家分享我們多年的經驗，希望大家不管是喜歡或是有意見，都可以回饋給我們，讓我們有機會和大家對話並一起成長！
若有任何問題請來信：gss_crm@gss.com.tw
上次在保護你的密碼文中，提到了 Hashicorp Vault 的簡單應用，但那畢竟是為了快速入門，也不想在一篇文章裡放太多元素。如果要能夠長期服務，我們來看看必須增加哪些認識：
- 脫離試用情境
- 最小組態檔
- 初始化
- 封存與解封
-
使用內建的 Cubbyhole
首先是「脫離試用情境」，還記得上次在安裝後，我們是開一個命令列視窗，執行 vault server -dev 並且留在那不動嗎？這個行程的生命週期自然就隨著 Ctrl+C 或關閉視窗，或關機而結束了。為了下次執行時能用共同的組態設定，執行命令要改成 vault server -config=<configFile> 這樣的形式。
<configFile> 代表的是組態設定檔的絕對路徑，例如 "C:\Users\david\Documents\vault\config.hcl"，附檔名慣例是如此，用雙引號包圍可以防止路徑含有空白的問題，最小組態的內容大致像以下六行：
- storage "File" {
- path = "C:\\Users\\david\\Documents\\vault\\file"
- }
- listener "TCP" {
- tls_disable = true
- }
這裡請注意到，組態檔內容表示路徑時，在 Windows 作業系統環境下，要用連續兩個反斜線分隔目錄，file 是 vault 下的一個子目錄。當這檔案準備好，執行「脫離試用情境」，也就是正式情境下的 vault server -config="C:\Users\david\Documents\vault\config.hcl" 時，如果是第一次用這個組態檔，事實上它會在「not initialized」狀態下，什麼事都不能做。那要如何初始化呢？請另開命令視窗下指令：
- set VAULT_ADDR=http://127.0.0.1:8200
- vault operator init
這時我們應該會得到五把 Unseal Key 以及一個 Root Token，請好好保管！在 vault status 得到的一些資訊值得我們仔細了解：
- Initialized: true
- Sealed: true
- Total Shares: 5
- Threshold: 3
- Unseal Progress: 0/3
以上翻成白話的意思是：初始化了，還在封存中，總共有五把解封相關的金鑰，每次解封需要三把，現在已用到零把來解封。要解封的指令是：
- vault opeartor unseal <UnsealKey>
連續三次都給正確且不同的金鑰之後就解封了，這時任何有 Token 的人都要登入才能使用，也就是說，Vault 的管理總共可以拆分成：
- 硬體管理員：負責通電開機
- 系統管理員：負責起 vault server 行程，不論手動或自動
- 組態管理員：負責組態檔內容
- 備份管理員：負責 vault\file 路徑下的所有檔案備份
- 封存管理員：負責 M 把金鑰中的 N 把保管，在服務前拿出來解封
- 密文管理員：負責將密文送入庫保管，以及出庫應用
身為持有 Token 的密文管理員，在 vault login <Token> 後，可以使用既有的 cubbyhole 來熟悉一下 vault 的性能，如：
- vault write cubbyhole/a b=c (a 是路徑，b 是 key，c 是要保護的密文)
- vault read cubbyhole/a (get key value pair b=c)
- vault write cubbyhole/a d=e
- vault read cubbyhole/a (get key value pair d=e 每個路徑只能存一對鍵值)
- vault write cubbyhole/a/f g=h (路徑可以延伸)
- vault read cubbyhole/a (get key value pair d=e 完整路徑與部份路徑視為不同的路徑)
- vault read cubbyhole/a/f (get key value pair g=h)
- vault read -field=g cubbyhole/a/f (get h 這在批次檔不需再解鍵值對，比較好用，尤其在 cubbyhole 限制每個路徑下僅能存一對鍵值時，key 已沒有太大意義)
評論
尚無評論