Loading...
No results found.

Create policies

Check my progress

/ 30

Create and manage policies using CLI commands

Check my progress

/ 35

Policies for Secrets

Check my progress

/ 35

This lab may incorporate AI tools to support your learning.
This content is not yet optimized for mobile devices.
For the best experience, please visit us on a desktop computer using a link sent by email.

本實驗室由 Google 與合作夥伴 HashiCorp 攜手開發。若您在「帳戶設定檔」中選擇接收產品最新消息、公告和優惠資訊，我們可能會向本實驗室的贊助者 HashiCorp 提供您的個人資訊。

GSP1004

Google Cloud 自學實驗室

總覽

Vault 會依據政策控管用戶端行為，並指定存取權限 (即「授權」) 來實行角色式存取控管 (RBAC)。透過政策，使用者能以宣告式做法授權或禁止存取特定路徑和操作。本實作實驗室將帶您瞭解如何編寫及運用 Vault 政策。

目標

在本實驗室中，您將：

  • 建立 Vault 政策
  • 管理 Vault 政策
  • 建立 Vault 政策關聯
  • 驗證及測試 Vault 政策

設定和需求

瞭解以下事項後，再點選「Start Lab」按鈕

請詳閱以下操作說明。實驗室活動會計時，且中途無法暫停。點選「Start Lab」後就會開始計時，顯示可使用 Google Cloud 資源的時間。

您將在真正的雲端環境完成實作實驗室活動，而不是模擬或示範環境。為此，我們會提供新的暫時憑證，供您在實驗室活動期間登入及存取 Google Cloud。

為了順利完成這個實驗室，請先確認：

  • 可以使用標準的網際網路瀏覽器 (Chrome 瀏覽器為佳)。
注意事項：請使用無痕模式 (建議選項) 或私密瀏覽視窗執行此實驗室，這可以防止個人帳戶和學員帳戶之間的衝突，避免個人帳戶產生額外費用。
  • 是時候完成實驗室活動了！別忘了，活動一旦開始將無法暫停。
注意事項：務必使用實驗室專用的學員帳戶。如果使用其他 Google Cloud 帳戶，可能會產生額外費用。

如何開始實驗室及登入 Google Cloud 控制台

  1. 按一下「Start Lab」按鈕。如果實驗室會產生費用，請在開啟的對話方塊中選取付款方式。右側的「Lab setup and access」面板會顯示下列項目：

    • 「Open Google Cloud console」按鈕
    • 此實驗室所需的臨時憑證 (使用者名稱和密碼)
    • 完成此實驗室所需的其他資訊 (如有)

    請注意，實驗室計時器位於頁面頂端附近，會顯示剩餘時間。

  2. 按一下「Open Google Cloud console」。如果使用 Chrome 瀏覽器，也可以按一下滑鼠右鍵，選取「在無痕視窗中開啟連結」。

    接著，實驗室會啟動相關資源，並開啟另一個分頁，顯示「登入」頁面。

    提示：您可以在不同的視窗並排開啟分頁。

    注意：頁面顯示「選擇帳戶」對話方塊時，請點選「使用其他帳戶」。

  3. 如有必要，請將下方的 Username 貼到「登入」對話方塊。

    {{{user_0.username | "Username"}}}

    您也可以在「Lab setup and access」面板找到「Username」。

  4. 點選「下一步」。

  5. 複製下方的 Password，並貼到「歡迎使用」對話方塊。

    {{{user_0.password | "Password"}}}

    您也可以在「Lab setup and access」面板找到「Password」。

  6. 點選「下一步」。

    重要事項：請務必使用實驗室提供的憑證，而非自己的 Google Cloud 帳戶憑證。 注意：如果使用自己的 Google Cloud 帳戶來進行這個實驗室，可能會產生額外費用。

  7. 繼續點按後續頁面：

    • 接受條款及細則。
    • 由於這是臨時帳戶，請勿新增救援選項或雙重驗證機制。
    • 請勿申請免費試用。

Google Cloud 控制台稍後會在這個分頁開啟。

注意：如要使用 Google Cloud 產品和服務，請按一下「導覽選單」，或在「搜尋」欄位輸入服務或產品名稱。「導覽選單」圖示和搜尋欄位

啟動 Cloud Shell

Cloud Shell 是搭載多項開發工具的虛擬機器，提供永久的 5 GB 主目錄，而且在 Google Cloud 中運作。Cloud Shell 提供指令列存取權，方便您使用 Google Cloud 資源。

  1. 點按 Google Cloud 控制台頂端的「啟用 Cloud Shell」圖示 「啟動 Cloud Shell」圖示。

  2. 系統顯示視窗時，請按照下列步驟操作：

    • 繼續操作 Cloud Shell 視窗。
    • 授權 Cloud Shell 使用您的憑證發出 Google Cloud API 呼叫。

連線建立完成即代表已通過驗證，而且專案已設為您的 Project_ID：。輸出內容中有一行文字，宣告本工作階段的 Project_ID：

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

gcloud 是 Google Cloud 的指令列工具，已預先安裝於 Cloud Shell，並支援 Tab 鍵自動完成功能。

  1. (選用) 您可以執行下列指令來列出使用中的帳戶：
gcloud auth list
  1. 點按「授權」。

輸出內容：

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`
  1. (選用) 您可以使用下列指令來列出專案 ID：
gcloud config list project

輸出內容：

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注意：如需 gcloud 的完整說明，請前往 Google Cloud 參閱 gcloud CLI 總覽指南。

工作 1：安裝 Vault

  1. 在 Cloud Shell 中，新增 HashiCorp GPG 金鑰：
curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - 注意：如果出現警告，請直接忽略。
  1. 新增官方 HashiCorp Linux 存放區：
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
  1. 更新並安裝 Vault：
sudo apt-get update sudo apt-get install vault

驗證安裝

安裝完成後，請確認 Vault 二進位檔可用，藉此驗證安裝是否成功。

  • 執行 vault 指令，驗證安裝作業：
vault

您應會看見類似下方的說明輸出內容：

Usage: vault <command> [args] Common commands: read Read data and retrieves secrets write Write data, configuration, and secrets delete Delete secrets and configuration list List data or secrets login Authenticate locally agent Start a Vault agent server Start a Vault server status Print seal and HA status unwrap Unwrap a wrapped secret Other commands: audit Interact with audit devices auth Interact with auth methods debug Runs the debug command kv Interact with Vault's Key-Value storage lease Interact with leases monitor Stream log messages from a Vault server namespace Interact with namespaces operator Perform operator-specific tasks path-help Retrieve API help for paths plugin Interact with Vault plugins and catalog policy Interact with policies print Prints runtime configurations secrets Interact with secrets engines ssh Initiate an SSH session token Interact with tokens

工作 2：啟動 Vault 伺服器

安裝 Vault 之後，請啟動 Vault 伺服器。

Vault 應用程式採用主從式架構，只有 Vault 伺服器會與資料儲存庫和後端互動。凡是透過 Vault CLI 執行的作業，都會透過 TLS 連線與伺服器互動。

在本實驗室中，您會啟動並使用以開發模式運作的 Vault 伺服器。

您不需要進一步設定開發模式伺服器，本機 Vault CLI 即可通過驗證並與該伺服器通訊。因此，您可以輕鬆使用 Vault 進行測試，也可以啟動 Vault 執行個體來執行開發工作。「開發」模式提供 Vault 的所有功能。-dev 旗標會略過許多設定，直接採用不安全的預設值。

警告：切勿在正式環境中執行「開發」模式伺服器。這樣做並不安全，且由於資料儲存在記憶體中，每次重新啟動都會全數遺失。這個模式僅供開發或測試之用。

啟動開發伺服器

請先啟動 Vault 的「開發伺服器」。這個內建伺服器已預先設定完畢，雖然安全性不高，但適合在本機測試 Vault。

  1. 執行以下指令，啟動 Vault 開發伺服器：
vault server -dev

輸出內容應會與 Vault 伺服器設定相關。請注意，畫面上會顯示解除密封金鑰和根權杖的值。

==> Vault server configuration: Api Address: http://127.0.0.1:8200 Cgo: disabled Cluster Address: https://127.0.0.1:8201 Listener 1: tcp (addr: "127.0.0.1:8200", cluster address: "127.0.0.1:8201", max_request_duration: "1m30s", max_request_size: "33554432", tls: "disabled") Log Level: info Mlock: supported: false, enabled: false Recovery Mode: false Storage: inmem Version: Vault v1.4.1 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. You may need to set the following environment variable: $ export VAULT_ADDR='http://127.0.0.1:8200' The unseal key and root token are displayed below in case you want to seal/unseal the Vault or re-authenticate. Unseal Key: 1+yv+v5mz+aSCK67X6slL3ECxb4UDL8ujWZU/ONBpn0= Root Token: s.XmpNPoi9sRhYtdKHaQhkHP6x Development mode should NOT be used in production installations! 注意：開發伺服器會將所有資料儲存在記憶體中 (但仍會加密)、監聽 localhost (但不使用 TLS)，並自動解除密封及顯示解除密封金鑰和根層級存取金鑰。 注意：不安全的作業

請勿在正式環境執行 Vault 開發伺服器！本實驗室是為了在示範時簡化解除密封程序，才採取這種做法。

Vault 開發伺服器已開始運作，您可以接著設定存取權。

  1. 開啟新的 Cloud Shell 分頁。

  2. 從終端機輸出內容複製並執行 VAULT_ADDR ... 匯出指令，將 Vault 用戶端設為與開發伺服器通訊：

export VAULT_ADDR='http://127.0.0.1:8200'

Vault CLI 會使用 VAULT_ADDR 環境變數，判斷要將要求傳至哪些 Vault 伺服器。

確認伺服器已在運作

  • 執行 vault status 指令，確認伺服器已在運作：
vault status

如果執行成功，輸出內容應如下所示：

$ vault status Key Value --- ----- Seal Type shamir Initialized true Sealed false Total Shares 1 Threshold 1 Version 1.13.2 Build Date 2023-04-25T13:02:50z Storage Type inmem Cluster Name vault-cluster-e2392b81 Cluster ID 48d7aba0-5416-a36b-2c27-0b256b222f57 HA Enabled false

太好了！您已啟動第一個 Vault 開發伺服器。現在可以進入下一節，瞭解如何編寫 Vault 政策了。

工作 3：Vault 政策

Vault 會在初始化時建立根政策。這項政策可對全部路徑執行所有作業，並會指派給初始化完成時顯示的「根」權杖。該權杖會提供給初始超級使用者，用於啟用密鑰引擎、定義政策及設定驗證方式。

Vault 也會建立預設政策，其中定義一組通用權限，使權杖能檢視及管理自身。這項政策也會指派給「根」權杖，並預設附加至所有權杖。

政策語法

政策是以 HCL 或 JSON 格式編寫，說明使用者或裝置可存取 Vault 中的哪些「路徑」。政策會定義路徑清單，每個路徑都代表著允許的權限。基於「預設採用安全設定」原則，Vault 預設會拒絕所有路徑權限，因此您必須明確授予路徑權限。

政策的基本格式如下：

path "<path>" { capabilities = ["list of capabilities"] }

舉例來說，下方的簡單政策可授予 "secret/foo" 路徑的讀取權限。

path "secret/foo" { capabilities = ["read"] }

將這項政策指派給權杖後，該權杖即可從 "secret/foo" 讀取資料，但沒有更新或刪除 "secret/foo" 的權限。由於政策遵循「預設拒絕」原則，權杖在 Vault 中將不具備其他任何存取權。換句話說，空白的 Vault 政策不會在系統中授予權限。

權限

政策會定義一或多個路徑，以及一份許可權限清單。每個路徑都須定義一或多項權限，用於精細管理許可 (或拒絕) 的操作。如以下範例所示，權限一律會以字串清單的形式指定，即使只有一項權限也不例外。這些權限大多會對應至 Vault API 支援的 HTTP 動詞。權限清單如下：

政策權限 關聯的 HTTP 動詞
create POST/PUT
read GET
update POST/PUT
delete DELETE
list LIST
patch PATCH
sudo -
deny -


sudo 權限允許存取受根層級保護的路徑，詳情請參閱「受根層級保護的端點」教學章節。deny 權限會停用路徑存取權，且在與其他權限併用時，一律會優先生效。

政策範例

如要定義更詳細的政策來授予 "secret/*" 的所有存取權，可以參考以下範例：

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] }

如要定義其他限制，可以加入以下 deny 權限：

path "secret/*" { capabilities = ["create", "read", "update", "delete", "list"] } path "secret/super-secret" { capabilities = ["deny"] }

即使您允許了 secret/*，上方範例中新增的一行程式碼仍會明確拒絕 secret/super-secret，因為拒絕操作具有優先權。

政策也可指定「allowed」(允許)、「disallowed」(禁止) 和「required」(必要) 參數。在下方範例中，"secret/restricted" 鍵只能包含「foo」(任意值) 和「bar」(「zip」或「zap」擇一)。

path "secret/restricted" { capabilities = ["create"] allowed_parameters = { "foo" = [] "bar" = ["zip", "zap"] } }

政策採用「路徑式」比對機制，用於驗證要求是否具備相應權限組合。政策 path 可能會明確指定要比對的路徑，或指定 glob 模式來引導 Vault 比對前置字元。

舉例來說，這項政策只允許讀取 "secret/foo" 或 "secret/foo/bar"。

path "secret/foo" { capabilities = ["read"] }

此外，此政策允許讀取 "secret/bar" 下的所有內容。附加的權杖可讀取 "secret/bar/zip"、"secret/bar/zip/zap"，但無法讀取 "secret/bars/zip"。

path "secret/bar/*" { capabilities = ["read"] }

此外，這項政策會允許讀取前置字元為 "zip-" 的所有內容。附加的權杖可讀取 "secret/zip-zap" 或 "secret/zip-zap/zong"，但無法讀取 "secret/zip/zap。

path "secret/zip-*" { capabilities = ["read"] }

最後，+ 可用來表示單一路徑區段內的任意多個字元。以下政策允許讀取 secret/ 下任何頂層路徑中的 "teamb" 路徑。

path "secret/+/teamb" { capabilities = ["read"] }

這個政策則會允許讀取 secret/foo/bar/teamb、secret/bar/foo/teamb 等路徑。

path "secret/+/+/teamb" { capabilities = ["read"] }

如您所見，Vault 的架構類似於檔案系統，其中每項操作都有對應的路徑和權限，即使是 Vault 的內部核心設定端點，也位於 "sys/" 路徑之下。政策定義了路徑存取權和權限，用於控管權杖對 Vault 內憑證的存取。

範本政策

政策語法允許在部分政策字串中，以權杖可用的值替換變數。目前可插入 identity 資訊，且政策中的 path 鍵允許插入。現在您還不需要擔心實體或別名，此處只是列出這些資訊以供日後參考。

參數

名稱 說明
identity.entity.id 實體 ID
identity.entity.name 實體名稱
identity.entity.metadata.<metadata key> 與指定鍵的實體相關聯的中繼資料
identity.entity.aliases.<mount accessor>.id 指定掛接點的實體別名 ID
identity.entity.aliases.<mount accessor>.name 指定掛接點的實體別名
identity.entity.aliases.<mount accessor>.metadata.<metadata key> 與指定掛接點別名和中繼資料鍵相關聯的中繼資料
identity.entity.aliases.<mount accessor>.custom_metadata.<custom_metadata key> 與指定掛接點別名和自訂中繼資料鍵相關聯的自訂中繼資料
identity.groups.ids.<group id>.name 指定群組 ID 的群組名稱
identity.groups.names.<group name>.id 指定群組名稱的群組 ID
identity.groups.ids.<group id>.metadata.<metadata key> 與指定鍵的群組相關聯的中繼資料
identity.groups.names.<group name>.metadata.<metadata key> 與指定鍵的群組相關聯的中繼資料

範例

以下政策會為特定使用者建立 KVv2 Secret Engine 區段：

path "secret/data/{{identity.entity.id}}/*" { capabilities = ["create", "update", "read", "delete"] } path "secret/metadata/{{identity.entity.id}}/*" { capabilities = ["list"] }

如要進一步瞭解範本政策，請參閱這份說明文件。

注意：開發範本政策時，請盡量使用 ID。每組 ID 都是使用者的專屬識別碼，而名稱則可能隨時間變更及重複使用。因此，這種做法能確保即使特定使用者或群組的名稱有所變動，政策仍會對應至目標實體或群組。

驗證內建政策權限

瞭解政策編寫方式後，接著來快速認識 root 和 default 政策的權限。

  1. 在開啟的 Cloud Shell 分頁中執行以下指令，以根權杖登入 Vault：
vault login token=<your root token>

您應會看到以下輸出內容：

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.mCWmZyVNi6ZDU7HSq7vQXwvj token_accessor nFDgTnm7FYCHNLSERwiVsbWf token_duration ∞ token_renewable false token_policies ["root"] identity_policies [] policies ["root"] 注意：請留意，附加的政策是根政策。
  1. 根政策允許您在 Vault 內執行任何操作，請執行基本指令來驗證是否確實如此：
vault secrets list

您會看見類似下方的輸出內容：

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_f0f2e28e per-token private secret storage identity/ identity identity_a554d41f identity store secret/ kv kv_ca28f047 key/value secret storage sys/ system system_1a7dcf93 system endpoints..

現在，請嘗試以僅附加 default 政策的使用者身分，執行相同的指令。

  1. 首先啟用 userpass 驗證方式，然後建立新使用者：
vault auth enable userpass vault write auth/userpass/users/example-user password=password!
  1. 接著，使用剛建立的使用者身分登入 Vault：
vault login -method=userpass username=example-user password=password!

您應會收到以下內容：

Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.Ov9GkScxp5AYDjzmbdHNN4r0 token_accessor UewGCCotUMjccmD1EjssgHqf token_duration 768h token_renewable true token_policies ["default"] identity_policies [] policies ["default"] token_meta_username example-user 注意：請留意，附加的政策是預設政策。
  1. 執行先前用來檢查政策權限的相同指令：
vault secrets list

您應會收到以下錯誤訊息：

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

如您所見，Vault 正在向路徑 sys/mounts 提出 GET API 要求。由於收到「權限遭拒」錯誤訊息，您無法存取該路徑並列出密鑰引擎。現在，請編寫您的第一項政策，用於存取這個路徑並列出密鑰引擎！

工作 4：建立政策

由於 Vault 可集中保護、儲存及控管分散式基礎架構和應用程式的密鑰存取權，因此務必在任何使用者或裝置獲得存取權前妥善控管權限。

為此應限制使用根政策，並編寫精細的政策來落實最小權限原則。例如：如果應用程式從 Vault 取得 Google Cloud 憑證，則編寫政策來授予 Google Cloud 密鑰引擎的讀取權限，但不允許刪除等操作。

政策會附加至權杖和角色，用於在 Vault 強制執行用戶端權限。您已瞭解政策的語法定義方式，該試著編寫第一項 Vault 政策了。

登入 Vault 網頁版 UI

  1. 首先，點選 Cloud Shell 工具列上的「網頁預覽」圖示。

「網頁預覽」圖示

  1. 點選「變更通訊埠」。

  2. 將通訊埠編號變更為 8200，然後點選「變更並預覽」。

「變更預覽通訊埠」對話方塊，內含「變更並預覽」按鈕。

  1. 您應會重新導向至 Vault 登入頁面。

登入 Vault 頁面。

  1. 輸入先前在實驗室儲存的根權杖，然後點選「登入」。

Vault 開發伺服器應會如下所示。

「Secret Engines」頁面，其中列出了「cubbyhole/」和「secret/」，以及「Enable new engine」按鈕。

您已登入開發伺服器網頁版 UI，可以進入下一節了。

建立新政策

  1. 在首頁點選「存取控管」。您應會看到 default 和 root ACL 政策。

「ACL 政策」頁面列出兩項 ACL 政策。

  1. 點選「Create ACL policy」。

  2. 首先將政策命名為 demo-policy。

接下來可以開始編寫政策了。回顧上一節，您無法存取 sys/mounts 路徑來讀取密鑰引擎。接著要新增相關設定。

  1. 在「Policy rules」中，選取「Code editor」並新增下列預留位置程式碼：
path "path" { capabilities = [""] }
  1. 現在，先將 path 更新為先前嘗試存取的 sys/mounts：
path "sys/mounts" { capabilities = [""] }
  1. 接下來要新增權限。由於 Vault 嘗試在此路徑發出 GET API 呼叫，您需要具備 read 權限。將 read 新增至權限清單：
path "sys/mounts" { capabilities = ["read"] }

政策內容應如下所示：

在「Policy」頁面輸入的程式碼。

  1. 點選「Create policy」。

現在，您需要將此政策與先前建立的 example-user 建立關聯。

  1. 點選「Back to main navigation」。

  2. 在左窗格依序點選「Access」>「Authentication methods」，然後按一下「userpass」。

「Authentication Methods」頁面。

  1. 點選 example-user 使用者旁的三點圖示，然後選取「Edit user」。

「Userpass」的「Users」分頁，「More」選單已展開

  1. 在密碼欄位下方點選「Tokens」，開啟子選單。

  2. 在「Generated Token's Policies」下方，新增剛才建立的 demo-policy 政策，然後點選「Add」。

「Add」按鈕

  1. 按一下「Save」。

太好了！您已建立新政策，並與 example-user 關聯。

  1. 返回 Cloud Shell，然後重新執行以下指令：
vault secrets list

您會看到與先前相同的錯誤訊息：

Error listing secrets engines: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/mounts Code: 403. Errors: * 1 error occurred: * permission denied

為什麼新增政策並套用至使用者後會發生錯誤？這是因為新政策與「使用者」建立關聯後，就不會與該使用者的現有「權杖」關聯。您需要替該使用者產生新的權杖，然後將新政策附加至該權杖，才能解決此問題。

  1. 執行以下指令來登入，並產生 example-user 的新權杖。
vault login -method=userpass username=example-user password=password! 注意：輸出內容應會顯示新的權杖。提醒您，目前已附加 default 和 demo-policy 政策。 Success! You are now authenticated. The token information displayed below is already stored in the token helper. You do NOT need to run "vault login" again. Future Vault requests will automatically use this token. Key Value --- ----- token s.7AVelOPORi1zhjH5iLototw7 token_accessor H1ee2gTXzTXUU9ptpU3ailnJ token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username example-user
  1. 現在，再次嘗試列出密鑰引擎：
vault secrets list

輸出內容應大致如下：

Path Type Accessor Description ---- ---- -------- ----------- cubbyhole/ cubbyhole cubbyhole_76cb59ae per-token private secret storage identity/ identity identity_7fa27e52 identity store secret/ kv kv_f6e83366 key/value secret storage sys/ system system_414d50aa system endpoints..
  1. 您也可使用 vault token capabilities 指令來檢查權杖的權限。執行以下指令，確認 sys/mounts 路徑的政策：
vault token capabilities <your token> sys/mounts

您應會看到以下輸出內容：

read
  1. 接下來，請檢查 sys/policies/acl 路徑的權杖權限：
vault token capabilities <your token> sys/policies/acl

您應會看到以下輸出內容：

deny
  1. 如要確認，請執行以下指令來列出政策：
vault policy list

您應會收到以下錯誤訊息：

Error listing policies: Error making API request. URL: GET http://127.0.0.1:8200/v1/sys/policies/acl?list=trueCode: 403. Errors: * 1 error occurred: * permission denied

如您所見，在 sys/policies/acl 路徑的GET API 要求，會傳回權限遭拒的錯誤訊息。請注意路徑中額外的 list=true；您也需要新增這項權限。我們接著來更新現有政策，以便修正此問題。

  1. 返回您在 Vault UI 中建立的 demo-policy。

「demo-policy」頁面

  1. 點選「Edit policy」。

  2. 在「Policy」方塊中找到先前編寫的現有政策，然後新增以下預留位置程式碼：

path "path" { capabilities = [""] }
  1. 同樣地，先將 path 更新為您嘗試存取的 sys/policies/acl 路徑：
path "sys/policies/acl" { capabilities = [""] }
  1. 現在要新增權限。由於 Vault 會嘗試在該路徑發出 GET API 呼叫，您需要再次新增 read 權限。此外，該項呼叫會傳遞 list=true 到目標網址，因此您也需要新增這項權限。
path "sys/policies/acl" { capabilities = ["read", "list"] }

更新後的政策應如下所示：

更新後的政策程式碼。

  1. 按一下「Save」。

  2. 返回 Cloud Shell，然後重新執行以下指令：

vault policy list

輸出內容應如下所示：

default default-ceiling demo-policy root
  1. 執行以下指令，將政策值複製到文字檔：
vault policy list > policies.txt
  1. 最後，再次檢查 sys/policies/acl 路徑的權杖權限：
vault token capabilities <your token> sys/policies/acl

您應會看到以下輸出內容：

list, read
  1. 執行以下指令，將政策值複製到文字檔。請務必將 <your token> 替換為您的權杖值：
vault token capabilities <your token> sys/policies/acl > token_capabilities.txt
  1. 執行以下指令，將 policies 和 token_capabilities 文字檔複製到預先建立的 Cloud Storage bucket，以便追蹤進度：
export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

如您所見，「修改」與使用者相關聯的現有政策時，系統會反映異動內容，但不產生新的權杖。這是因為每當使用權杖時，系統都會即時剖析政策內容。因此，如果政策有異動，下次有人使用附有該政策的權杖呼叫 Vault 時，系統就會執行修改後的規則。

太好了！您已成功建立政策，將讀取權限授予給 sys/mounts 路徑，並與使用者建立關聯。接著，您新增了另一項政策，將讀取和列出權限授予給 sys/policies 路徑。

點選「Check my progress」，確認目標已達成。 建立政策

工作 5：管理政策

您可以使用慣用的編輯器，以 HCL 或 JSON 格式編寫政策，具體語法請參見上文。政策儲存後，還必須上傳到 Vault 才能發揮作用。

在上一節中，您使用 UI 編寫及管理了政策。本節將介紹可用於管理政策的 CLI 指令。

  • 首先，請務必在 Cloud Shell 執行以下指令，以根權杖登入 Vault：
vault login <your root token>

列出政策

  • 執行以下指令，列出 Vault 中所有已註冊的政策：
vault read sys/policy

您應會看到以下輸出內容：

Key Value --- ----- keys [default demo-policy root] policies [default demo-policy root

建立政策

CLI、UI 或 API 均可用於建立 (上傳) 政策。在上一節，您只是透過 UI 建立了 HCL 檔案。

如要在 Vault 建立新政策，請使用以下指令：

vault policy write policy-name policy-file.hcl
  1. 您可以先執行測試，用以下指令建立基本政策檔案：
tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } EOF
  1. 確認檔案正確建立：
cat example-policy.hcl
  1. 現在，使用 vault policy write 指令建立名為 example-policy 的新政策：
vault policy write example-policy example-policy.hcl

如果成功，您應會看到以下輸出內容：

Success! Uploaded policy: example-policy

本例中的政策名為「example-policy」。您可以將這個名稱視為政策存取控制清單的指標或符號連結。權杖是依名稱與政策建立關聯，而這些名稱則會對應到相應的一組規則。

更新政策

現有政策可透過 CLI 或 API 更新來變更權限。如要更新 Vault 中的現有政策，請按照建立政策的相同步驟操作，但使用現有政策的名稱。

  1. 首先，請執行以下指令來更新及覆寫現有政策檔案，使其能列出驗證方式：
tee example-policy.hcl <<EOF # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List auth methods path "sys/auth" { capabilities = ["read"] } EOF
  1. 確認檔案正確建立：
cat example-policy.hcl
  1. 更新政策：
vault write sys/policy/example-policy policy=@example-policy.hcl

太好了！您已成功使用 CLI 更新政策。

  1. 執行以下指令，將政策檔案複製到預先建立的 Cloud Storage bucket，以便追蹤進度：
gcloud storage cp example-policy.hcl gs://$PROJECT_ID

點選「Check my progress」，確認目標已達成。 使用 CLI 指令建立及管理政策

刪除政策

您可以透過 CLI、UI 或 API 刪除現有政策，只要執行以下指令即可：

vault delete sys/policy/policy-name
  1. 我們來實際演練一下。執行以下指令，刪除剛才建立的政策：
vault delete sys/policy/example-policy

如果成功，您應會看到以下輸出內容：

Success! Data deleted (if it existed) at: sys/policy/example-policy
  1. 使用以下指令列出政策：
vault policy list

您應會看到以下輸出內容：

default default-ceiling demo-policy root

太好了！您已成功刪除 example-policy。

注意：這是一項冪等作業。即使要刪除的政策不存在，Vault 也不會傳回錯誤。

工作 6：建立政策關聯

Vault 可根據授權，自動將一組政策與權杖建立關聯。不同驗證後端的設定方式差異極大。為求簡便，本例將採用 Vault 內建的 userpass 驗證方式。

  1. 執行以下指令，在 Vault 建立 firstname-lastname 使用者，並附上相關聯的政策清單：
vault write auth/userpass/users/firstname-lastname \ password="s3cr3t!" \ policies="default, demo-policy" Success! Data written to: auth/userpass/users/firstname-lastname

這會建立政策驗證對應，讓使用者成功完成 Vault 驗證時，能獲得附加政策清單的權杖。

  1. 執行以下指令來進行 Vault 驗證：
vault login -method="userpass" username="firstname-lastname" password="s3cr3t!"

您應會看到以下輸出內容：

Key Value --- ----- token s.XnRsinhsokVUiN7XbsnyCOEC token_accessor JFErk5Rgb7vtW47CJjY2OCsF token_duration 768h token_renewable true token_policies ["default" "demo-policy"] identity_policies [] policies ["default" "demo-policy"] token_meta_username firstname-lastname

由於提供的資訊正確無誤，Vault 會產生權杖並指派設定好的政策清單，再傳回給驗證使用者。

權杖

權杖有兩組政策：身分識別政策是根據實體和其群組運算得出；權杖政策則可依登入方式定義，或在透過 API 明確建立權杖時輸入相應設定。以下內容僅適用於權杖政策：除非修改底層實體、群組和群組成員，否則無法直接控管權杖的身分識別政策。

  1. 首先，使用根權杖重新登入 Vault：
vault login <your root token>
  1. 權杖會在建立時與政策建立關聯。請執行以下指令，建立附有 dev-readonly 和 logs 政策的權杖：
vault token create -policy=dev-readonly -policy=logs

您應會看到以下輸出內容：

Key Value --- ----- token s.gKRV6vzFmpdJ9iwvPfzNjAuI token_accessor S4jfdYvy8jQP7GGDa947CBlT token_duration 768h token_renewable true token_policies ["default" "dev-readonly" "logs"] identity_policies [] policies ["default" "dev-readonly" "logs"] 注意：您尚未建立政策，因此可以忽略「政策不存在」的警告。

一般來說，您只能指定目前權杖 (即新權杖的上層權杖) 中已有的權杖政策。不過，超級使用者可以指派任何政策。

權杖一經核發，相關聯的政策便無法修改。如要接收新的一組政策，您必須撤銷並重新取得權杖。

不過，每次使用權杖時，系統都會即時剖析政策的「內容」。因此，如果政策有異動，下次有人使用附有該政策的權杖呼叫 Vault 時，系統就會執行修改後的規則。

工作 7：密鑰政策

本節將帶您建立 Vault 政策，授予使用者 Vault 內各種層級的存取權，並執行測試。

  • 首先，在 Cloud Shell 中建立幾個使用者，並分別搭配不同的政策：
vault write auth/userpass/users/admin \ password="admin123" \ policies="admin" vault write auth/userpass/users/app-dev \ password="appdev123" \ policies="appdev" vault write auth/userpass/users/security \ password="security123" \ policies="security"

接下來，您需要建立與這些新使用者關聯的政策。首先是 admin 政策。該政策應具備完整權限，可存取 Vault 中的所有密鑰。

建立 admin 政策

在本實驗室中，admin 使用者必須能：

  • 讀取系統健康狀態檢查資料
  • 建立及管理整個 Vault 中的 ACL 政策
  • 啟用及管理整個 Vault 中的驗證方式
  • 管理在 secret/ 路徑啟用的鍵/值密鑰引擎

  1. 在 Vault UI 的左側窗格中，前往「ACL policies」。您應會看到 default、default-ceiling、demo-policy 和 root 政策。

  2. 點選「Create ACL policy」。

  3. 首先，將政策命名為 admin。

  4. 在「Policy rules」中，選取「Code editor」，然後新增以下政策程式碼：

# Read system health check path "sys/health" { capabilities = ["read", "sudo"] } # Create and manage ACL policies broadly across Vault # List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Enable and manage authentication methods broadly across Vault # Manage auth methods broadly across Vault path "auth/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, update, and delete auth methods path "sys/auth/*" { capabilities = ["create", "update", "delete", "sudo"] } # List auth methods path "sys/auth" { capabilities = ["read"] } # Enable and manage the key/value secrets engine at `secret/` path # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }

政策內容應如下所示：

更新後的「Policy」頁面。

  1. 點選「Create policy」。

建立 appdev 政策

在本實驗室中，appdev 使用者必須能：

  • 建立、讀取及更新密鑰引擎
  • 管理在 secret/appdev/ 路徑啟用的鍵/值密鑰引擎

  1. 返回「ACL Policies」頁面。

  2. 點選「Create ACL policy」。

  3. 首先，將政策命名為 appdev。

  4. 在「Policy rules」中，選取「Code editor」，然後新增以下政策程式碼：

# List, create, update, and delete key/value secrets path "secret/+/appdev/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Create, read, and update secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] }
  1. 點選「Create policy」。

建立 security 政策

在本實驗室中，security 使用者必須能：

  • 建立及管理整個 Vault 中的 ACL 政策
  • 管理密鑰引擎
  • 管理在 secret/ 路徑啟用的鍵/值密鑰引擎
  • 無法讀取或列出 secret/admin 路徑的密鑰

  1. 返回「ACL Policies」頁面。

  2. 點選「Create ACL policy」。

  3. 首先，將政策命名為 security。

  4. 在「Policy rules」中，選取「Code editor」，然後新增以下政策程式碼：

# List existing policies path "sys/policies/acl" { capabilities = ["list"] } # Create and manage ACL policies path "sys/policies/acl/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Manage secrets engines path "sys/mounts/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # List existing secrets engines. path "sys/mounts" { capabilities = ["read"] } # List, create, update, and delete key/value secrets path "secret/*" { capabilities = ["create", "read", "update", "delete", "list", "sudo"] } # Deny access to secret/admin path "secret/data/admin" { capabilities = ["deny"] } path "secret/data/admin/*" { capabilities = ["deny"] } # Deny list access to secret/admin path "secret/metadata/admin" { capabilities = ["deny"] } path "secret/metadata/admin/*" { capabilities = ["deny"] }
  1. 點選「Create policy」。

建立密鑰

建立不同政策後，請接著新增一些密鑰。

  1. 返回 Cloud Shell 並執行以下指令，在 secret/security 路徑建立一些密鑰：
vault kv put secret/security/first username=password vault kv put secret/security/second username=password
  1. 在 secret/appdev 路徑建立一些密鑰：
vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password
  1. 在 secret/admin 路徑建立一些密鑰：
vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

驗證 appdev 的安全性

建立密鑰後，您需要驗證系統是否執行相關政策。請先以 app-dev 使用者身分登入，查看您有權存取的內容。

  1. 執行以下指令，以 app-dev 使用者身分登入：
vault login -method="userpass" username="app-dev" password="appdev123"
  1. 現在，試著擷取 appdev/first 密鑰：
vault kv get secret/appdev/first

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 擷取位於 secret/appdev/beta-app/second 的密鑰：
vault kv get secret/appdev/beta-app/second

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 建立新的密鑰：
vault kv put secret/appdev/appcreds credentials=creds123
  1. 刪除密鑰：
vault kv destroy -versions=1 secret/appdev/appcreds
  1. 嘗試從 secret/security 取得密鑰：
vault kv get secret/security/first

您應會收到以下錯誤訊息：

Error reading secret/data/security/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/security/first Code: 403. Errors: * 1 error occurred: * permission denied
  1. 嘗試列出 secret/ 中的所有密鑰：
vault kv list secret/

您應會再次收到錯誤訊息：

Error listing secret/metadata: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata?list=true Code: 403. Errors: * 1 error occurred: * permission denied

太好了！您已成功在 secret/appdev 路徑擷取及建立密鑰，並確認自己無法存取該路徑之外的密鑰。

驗證 security 政策

  1. 執行以下指令，以 security 使用者身分登入：
vault login -method="userpass" username="security" password="security123"
  1. 現在，試著擷取 security/first 密鑰：
vault kv get secret/security/first

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 擷取位於 secret/security/second 的密鑰：
vault kv get secret/security/second

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.829274247Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 在 secret/security/supersecure 建立新的密鑰：
vault kv put secret/security/supersecure/bigsecret secret=idk
  1. 刪除密鑰：
vault kv destroy -versions=1 secret/security/supersecure/bigsecret
  1. 嘗試從 secret/appdev 讀取密鑰：
vault kv get secret/appdev/first

您應會收到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 嘗試列出 secret/ 中的所有密鑰：
vault kv list secret/

您應會收到以下輸出內容：

Keys ---- admin/ appdev/ security/
  1. 啟用新密鑰引擎：
vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/
  1. 嘗試查看 secret/admin/first 密鑰：
vault kv get secret/admin/first

您應會收到以下錯誤訊息：

Error reading secret/data/admin/first: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/data/admin/first Code: 403. Errors: * 1 error occurred: * permission denied
  1. 嘗試列出 secret/admin 中的密鑰：
vault kv list secret/admin

您應會再次收到錯誤訊息：

Error listing secret/metadata/admin: Error making API request. URL: GET http://127.0.0.1:8200/v1/secret/metadata/admin?list=true Code: 403. Errors: * 1 error occurred: * permission denied

太好了！您可以在 secret/ 路徑擷取及建立密鑰、啟用密鑰引擎，並且根據政策規定，無法存取 secret/admin 路徑。

驗證 admin 政策

  1. 執行以下指令，以 admin 使用者身分登入：
vault login -method="userpass" username="admin" password="admin123"
  1. 現在，試著擷取 admin/first 密鑰：
vault kv get secret/admin/first

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:18.521925218Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ==== Data ==== Key Value --- ----- admin password
  1. 擷取位於 secret/security/first 的密鑰：
vault kv get secret/security/first

您應會看到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:04.299036073Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 建立新的密鑰：
vault kv put secret/webserver/credentials web=awesome
  1. 刪除密鑰：
vault kv destroy -versions=1 secret/webserver/credentials
  1. 嘗試從 secret/appdev 取得密鑰：
vault kv get secret/appdev/first

您應會收到以下輸出內容：

======= Metadata ======= Key Value --- ----- created_time 2022-01-12T18:58:13.18635501Z custom_metadata <nil> deletion_time n/a destroyed false version 1 ====== Data ====== Key Value --- ----- username password
  1. 嘗試列出 secret/appdev 中的所有密鑰：
vault kv list secret/appdev/

您應會收到以下輸出內容：

Keys ---- appcreds beta-app/ first
  1. 列出所有政策：
vault policy list

您應會收到以下輸出內容：

admin appdev default default-ceiling demo-policy security root
  1. 執行以下指令，將政策值複製到文字檔，然後把檔案上傳到 Cloud Storage bucket：
vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID
  1. 啟用 gcp 驗證方式：
vault auth enable gcp
  1. 最後，列出已啟用的驗證方式：
vault auth list Path Type Accessor Description ---- ---- -------- ----------- gcp/ gcp auth_gcp_faa3d15f n/a token/ token auth_token_066c5ebd token based credentials userpass/ userpass auth_userpass_929fe9bd n/a

太好了，您已確認自己擁有與所編寫政策相關聯的管理員權限。

點選「Check my progress」，確認目標已達成。 密鑰政策

路徑

您可能已經發現，提供給 security 使用者的政策程式碼中引入了兩個先前沒見過的主題：data/ 和 metadata/。

metadata/ 路徑端點會傳回指定位置的鍵名稱清單。此外，這個指令無法存取具體的值。寫入和讀取版本作業的開頭會加上 data/，列出、讀取及刪除作業的開頭則如下所示：

  • 寫入和讀取版本：data/
  • 列出鍵：metadata/
  • 讀取版本：metadata/
  • 刪除密鑰版本：destroy/
  • 刪除鍵的所有中繼資料版本：metadata/

舉例來說，如果您想拒絕 secret/example 的密鑰存取權，則需要使用以下 data/ 格式：

path "secret/data/example" { capabilities = ["deny"] }

如要拒絕 secret/examples 的列出存取權，則需使用以下 metadata/ 格式：

path "secret/metadata/examples/*" { capabilities = ["deny"] }

工作 8：精細控管

除了標準權限集外，Vault 還提供精細控管功能，可用於設定特定路徑的權限。路徑的關聯權限優先於參數權限。

參數限制

在 Vault 中，資料會以 key=value 組合的形式呈現。評估路徑權限時，Vault 政策可視需要根據鍵和其中的資料來進一步限制路徑。可用的精細控管選項如下：

  • required_parameters：必須指定的參數清單。
  • allowed_parameters：指定路徑的允許鍵/值清單。
  • denied_parameters：包含參數和值的拒絕清單，此處指定的值會優先於 allowed_parameters。

如要進一步瞭解精細控管功能，請參閱這份說明文件。

恭喜！

如您所見，政策是 Vault 的重要組成部分。儘管使用根權杖最容易上手，但您很快就會需要限制對 Vault 的存取，這時政策系統就能派上用場。

政策的語法與功能易於理解及運用，且所有驗證方式都必須對應到中央政策系統，因此您只需瞭解該套系統即可。

在本實驗室中，您瞭解了如何建立及管理政策、將政策與使用者和權杖建立關聯，以及驗證相關權限。

後續步驟/瞭解詳情

如要進一步瞭解 Vault，請參考下列資源：

Google Cloud 教育訓練與認證

協助您瞭解如何充分運用 Google Cloud 的技術。我們的課程會介紹專業技能和最佳做法，讓您可以快速掌握要領並持續進修。我們提供從基本到進階等級的訓練課程，並有隨選、線上和虛擬課程等選項，方便您抽空參加。認證可協助您驗證及證明自己在 Google Cloud 技術方面的技能和專業知識。

使用手冊上次更新日期：2026 年 6 月 4 日

實驗室上次測試日期：2026 年 6 月 4 日

Copyright 2026 Google LLC 保留所有權利。Google 和 Google 標誌是 Google LLC 的商標，其他公司和產品名稱則有可能是其關聯公司的商標。

Before you begin

  1. Labs create a Google Cloud project and resources for a fixed time
  2. Labs have a time limit and no pause feature. If you end the lab, you'll have to restart from the beginning.
  3. On the top left of your screen, click Start lab to begin

Use private browsing

  1. Copy the provided Username and Password for the lab
  2. Click Open console in private mode

Sign in to the Console

  1. Sign in using your lab credentials. Using other credentials might cause errors or incur charges.
  2. Accept the terms, and skip the recovery resource page
  3. Don't click End lab unless you've finished the lab or want to restart it, as it will clear your work and remove the project

This content is not currently available

We can notify you via email when it becomes available

Great!

We can contact you via email if it becomes available

One lab at a time

Confirm to end all existing labs and start this one

Use private browsing to run the lab

Using an Incognito or private browser window is the best way to run this lab. This prevents any conflicts between your personal account and the Student account, which may cause extra charges incurred to your personal account.