如果你希望追蹤最新的草稿，請見鐵人賽2023 本 workshop 也接受網友的許願清單，如果有興趣的題目可於第一篇底下留言，筆者會盡力實現，但不做任何保證 整篇 Workshop 會使用的範例與原始碼，放在 Github Repository: vault-playground Day 08: Vault in Docker and Initialization Vault in container 前幾天我們使用 vault dev Server 來啟用測試用的 Vault server。 在 production 環境我們不會使用 dev Server。Vault 提供許多安裝方法 可以使用 binary 直接安裝在VM上 也可以透過 hashicorp/vault official docker image，在container 環境中執行 或是使用 hashicorp official helm chart，安裝在kuberntes上 使用範例 repository 你可以使用筆者準備的範例 repository https://github.com/chechiachang/vault-playground git clone git@github.com:chechiachang/vault-playground.git cd deploy/00-docker-dev/ 你可以使用下列指令啟動 vault in docker 並使用 -v flag 來掛載 ./config/ volume 到 container 中的 /vault/config.d/ docker run --cap-add=IPC_LOCK \ --volume ./vault/config/:/vault/config.d \ --volume ./vault/file/:/vault/file \ --volume ./vault/logs/:/vault/logs \ -p 8200:8200 \ --name vault_1 \ -d \ hashicorp/vault:1.14.3 \ vault server -config=/vault/config.d/vault.hcl 然後使用 docker logs 指令檢視 vault server log ...

如果你希望追蹤最新的草稿，請見鐵人賽2023 本 workshop 也接受網友的許願清單，如果有興趣的題目可於第一篇底下留言，筆者會盡力實現，但不做任何保證 整篇 Workshop 會使用的範例與原始碼，放在 Github Repository: vault-playground Day 07: Policy & Approle 在 Vault 中，策略（Policies）控制著使用者可以訪問的資源。在上一篇身份驗證中，你已經學到了身份驗證方法(authentication method)。而這一節是關於授權(Authorization)，也就是合法的用戶登入後，應該能夠取得怎樣的權限。 在身份驗證方面，Vault 提供了多種啟用和使用的選項或方法。Vault 在授權和 policy 方面也使用相同的設計。所有身份驗證方法都將登入者的身份 map 回與 Vault 配置的核心 policy。 準備環境 在 vault 官方網站文件中，Hashicorp 官方準備了 https://instruqt.com/的 session lab 筆者個人覺得 interactive lab 的 browser tab 很難用，也不喜歡 Terminal session 連 remote VM 的延遲，以下內容還是會使用 local dev Server 說明。 觀眾們可以自己斟酌使用。 Policy 格式 策略（Policies）是以HCL撰寫的，但也兼容JSON格式。以下是一個範例策略： # Dev servers have version 2 of KV secrets engine mounted by default, so will # need these paths to grant permissions: path "secret/data/*" { capabilities = ["create", "update"] } path "secret/data/foo" { capabilities = ["read"] } 這個範例 policy 授予了對 KV v2 秘密管理（secrets engine）的資源的能力。如果你對於與這個秘密管理引擎相關的路徑不熟悉，可以查閱該秘密管理引擎文件中的 ACL 規則部分。 ...

如果你希望追蹤最新的草稿，請見鐵人賽2023 本 workshop 也接受網友的許願清單，如果有興趣的題目可於第一篇底下留言，筆者會盡力實現，但不做任何保證 整篇 Workshop 會使用的範例與原始碼，放在 Github Repository: vault-playground Day 06：Github auth method 不需要使用 root token 的 auth method: github Vault 支援用於人員使用者的身份驗證方法。GitHub 身份驗證，使用戶可以通過提供他們的 GitHub 憑證來驗證 Vault，並收到一個 Vault token。 簡單來說，github organization chechia-net，可以設定適當的權限給成員 chechiachang，讓 chechiachang 可以透過 github 取得有權限的 token。 注意 在練習中所描述的這種身份驗證方法，需要你擁有 GitHub、屬於 GitHub org 中的一個 team ，並生成了具有 read:org scope 的 GitHub personal access token。你可以於 github 創建一個 free plan 的 org，並設定一個 team，然後透過個人 Settings / Developer Settings 來產生一把具有 read:org 權限的 personal access token 啟用 github auth method 你可以使用下列指令，在 path=github/ 下啟用 GitHub 身份驗證方法。 ...

如果你希望追蹤最新的草稿，請見鐵人賽2023 本 workshop 也接受網友的許願清單，如果有興趣的題目可於第一篇底下留言，筆者會盡力實現，但不做任何保證 整篇 Workshop 會使用的範例與原始碼，放在 Github Repository: vault-playground Day 05：Authentication 在前面的文章中，你已經創建了第一個秘密，了解了秘密引擎，並在以開發模式啟動的 Vault 服務器中探索了動態秘密。 接下來的內容中，我們將深入研究使用 Vault token 和 GitHub 憑證進行身份驗證。 Token 身份驗證 Token 身份驗證已自動啟用。當你啟動開發模式服務器時，輸出顯示了 Root token。Vault CLI 從 $VAULT_TOKEN 環境變數中讀取 Root token。這個根 token 可以在 Vault 內執行任何操作，因為它被分配了 Root policy 權限。允許的權限中包含創建新的 token。 現在，讓我們創建一個新的 token。 啟動全新的 dev Vault Server vault server -dev output，server log 回傳 dev 模式的警告 WARNING! dev mode is enabled! In this mode, Vault runs entirely in-memory and starts unsealed with a single unseal key. The root token is already authenticated to the CLI, so you can immediately begin using Vault. # 警告！已啟用開發模式！在此模式下，Vault完全運行在內存中，使用單個unseal key解封。 # root token已被CLI驗證，因此你可以立即開始使用Vault。 You may need to set the following environment variables: $ export VAULT_ADDR='http://127.0.0.1:8200' # 以下顯示了unseal key 和 root token，以防你想要封存/解封Vault，或重新進行身份驗證。 The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. # dev 模式預設配置的 unseal key 與 root token Unseal Key: QDUA...im4= Root Token: hvs.J30e...0DJaN # 開發模式絕不應在生產安裝中使用！ Development mode should NOT be used in production installations! 依據提示 export 需要的變數 ...

如果你希望追蹤最新的草稿，請見鐵人賽2023 本 workshop 也接受網友的許願清單，如果有興趣的題目可於第一篇底下留言，筆者會盡力實現，但不做任何保證 整篇 Workshop 會使用的範例與原始碼，放在 Github Repository: vault-playground Day 04：Secret Engine KV V2 KV秘密引擎，用於在Vault的已配置物理Storage中，存儲任意秘密。 key 名稱必須始終是字符串。如果你直接通過CLI編寫非字串 value，它們將被轉換為字串。但是，你可以通過從JSON文件中將key-value pair寫入Vault，或使用HTTP API來保留非字串 value。 此秘密引擎遵照ACL policy中，創建(create)和更新(update)權限之間的設定。它還支持patch功能，用於表示部分更新(patch)，而更新功能(update)則表示完全覆蓋。 設置 大多數秘密引擎必須在執行其功能之前事先配置。這些步驟通常由操作人員或配置管理工具完成。 啟用v2 kv秘密引擎： 啟動一個乾淨的本地的開發模式 Vault Server，全新的 Vault Server 包含底下預設啟用的引擎 vault server -dev export VAULT_ADDR='http://127.0.0.1:8200' vault secrets list Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_57a4ca51 per-token private secret storage identity/ identity identity_c2ecbd49 identity store secret/ kv kv_c41afde8 key/value secret storage sys/ system system_c063e514 system endpoints used for control, policy and debugging 你可以在指定的路徑下，啟用一個新的 v2 kv 秘密引擎。若不指定 -path 參數，則預設 path 為 type，也就是 path=kv。 ...