本实验由 Google 与我们的合作伙伴 Hashicorp 共同开发。如果您在账号个人资料中选择接收产品动态、通知和优惠信息，那么我们可能会与实验赞助商 Hashicorp 共享您的个人信息。

GSP1004

概览

Vault 使用政策来管理客户端行为，并通过指定访问权限（称为“授权”）来实施基于角色的访问控制 (RBAC)。政策提供了一种声明式方法，用于授予或禁止对特定路径和操作的访问。在本实操实验中，您将学习如何编写和使用 Vault 政策。

目标

在本实验中，您将执行以下操作：

• 创建 Vault 政策
• 管理 Vault 政策
• 关联 Vault 政策
• 验证和测试 Vault 政策

设置和要求

点击“开始实验”按钮前的注意事项

请阅读以下说明。实验是计时的，并且您无法暂停实验。计时器在您点击开始实验后即开始计时，显示 Google Cloud 资源可供您使用多长时间。

此实操实验可让您在真实的云环境中开展实验活动，免受模拟或演示环境的局限。为此，我们会向您提供新的临时凭据，您可以在该实验的规定时间内通过此凭据登录和访问 Google Cloud。

为完成此实验，您需要：

• 能够使用标准的互联网浏览器（建议使用 Chrome 浏览器）。

注意：请使用无痕模式（推荐）或无痕浏览器窗口运行此实验。这可以避免您的个人账号与学生账号之间发生冲突，这种冲突可能导致您的个人账号产生额外费用。

• 完成实验的时间 - 请注意，实验开始后无法暂停。

注意：请仅使用学生账号完成本实验。如果您使用其他 Google Cloud 账号，则可能会向该账号收取费用。

如何开始实验并登录 Google Cloud 控制台

1. 点击开始实验按钮。如果该实验需要付费，系统会打开一个对话框供您选择支付方式。右侧是实验设置和访问权限面板，其中包含以下内容：

   • 打开 Google Cloud 控制台按钮
   • 您在本实验中必须使用的临时凭证（用户名和密码）
   • 帮助您逐步完成该实验所需的其他信息（如果需要）

   请注意，实验计时器位于页面顶部附近，将显示剩余时间。

2. 点击打开 Google Cloud 控制台（如果您使用的是 Chrome 浏览器，请右键点击并选择在无痕式窗口中打开链接）。

   该实验会启动资源并打开另一个标签页，显示“登录”页面。

   提示：可以将这些标签页分别放在不同的窗口中，并排显示。

   注意：如果您看见选择账号对话框，请点击使用其他账号。

3. 如有必要，请复制下方的用户名，然后将其粘贴到登录对话框中。

   {{{user_0.username | "<用户名>"}}}

   您也可以在实验设置和访问权限面板中找到“用户名”。

4. 点击下一步。

5. 复制下面的密码，然后将其粘贴到欢迎对话框中。

   {{{user_0.password | "<密码>"}}}

   您也可以在实验设置和访问权限面板中找到“密码”。

6. 点击下一步。

   重要提示：您必须使用实验提供的凭证。请勿使用您的 Google Cloud 账号凭证。 注意：在本实验中使用您自己的 Google Cloud 账号可能会产生额外费用。

7. 依次点击进入后续页面：

   • 接受条款及条件。
   • 由于这是临时账号，请勿添加账号恢复选项或双重身份验证。
   • 请勿注册免费试用。

片刻之后，系统会在此标签页中打开 Google Cloud 控制台。

注意：如需访问 Google Cloud 产品和服务，请点击导航菜单，或在搜索字段中输入服务或产品的名称。

激活 Cloud Shell

Cloud Shell 是一种装有开发者工具的虚拟机。它提供了一个永久性的 5GB 主目录，并且在 Google Cloud 上运行。Cloud Shell 提供可用于访问您的 Google Cloud 资源的命令行工具。

1. 点击 Google Cloud 控制台顶部的激活 Cloud Shell 。

2. 在弹出的窗口中执行以下操作：

   • 继续完成 Cloud Shell 信息窗口中的设置。
   • 授权 Cloud Shell 使用您的凭据进行 Google Cloud API 调用。

如果您连接成功，即表示您已通过身份验证，且项目 ID 会被设为您的 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 自动补全功能。

3. （可选）您可以通过此命令列出活跃账号名称：

gcloud auth list

4. 点击授权。

输出：

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

5. （可选）您可以通过此命令列出项目 ID：

gcloud config list project

输出：

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} 注意：如需查看在 Google Cloud 中使用 gcloud 的完整文档，请参阅 gcloud CLI 概览指南。

任务 1. 安装 Vault

1. 在 Cloud Shell 中，添加 HashiCorp GPG 密钥：

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add - 注意：如有警告，请予以忽略。

2. 添加官方 HashiCorp Linux 代码库：

sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"

3. 更新并安装 Vault：

sudo apt-get update sudo apt-get install vault

验证安装

安装 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 架构中唯一与数据存储和后端交互的部分。通过 Vault CLI 执行的所有操作均通过 TLS 连接与服务器交互。

在本实验中，您将启动以开发模式运行的 Vault 服务器并与之交互。

此开发模式服务器无需进一步设置，本地 Vault CLI 将通过身份验证与其通信。这样，您就可以轻松地试用 Vault 或启动一个 Vault 实例进行开发。Vault 的所有功能在“开发”模式下均可用。-dev 标志只是跳过了许多设置步骤，直接使用不安全的默认值。

警告：切勿在生产环境中运行“开发”模式服务器。该模式极不安全，且每次重启都会丢失数据（因为它将数据存储在内存中）。它仅用于开发或实验。

启动开发服务器

首先，启动 Vault 开发服务器。开发服务器是一个内置的预配置服务器，虽然安全性不高，但非常适合在本地试用 Vault。

1. 如需启动 Vault 开发服务器，请运行以下命令：

vault server -dev

您应该会看到与 Vault 服务器配置相关的输出。请注意，系统会显示 Unseal Key（解封密钥）和 Root Token（根令牌）值：

==> 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! 注意：开发服务器将所有数据存储在内存中（但仍会加密），在不使用 TLS 的情况下监听 localhost，并自动解封，向您显示解封密钥和根访问密钥。 注意：不安全的操作

切勿在生产环境中运行 Vault 开发服务器！本演示采用此方法，只是为了简化解封过程。

现在，Vault 开发服务器已在运行，您可以继续设置对它的访问权限。

2. 打开新的 Cloud Shell 标签页。

3. 从终端输出中复制并运行 export 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 会在初始化期间创建 root 政策。root 政策能对所有路径执行所有操作。此政策会分配给初始化完毕后显示的 root 令牌。这会提供一个初始超级用户，用于启用 Secret 引擎、定义政策并配置身份验证方法。

Vault 还会创建一个default（默认）政策。default 政策定义了一组通用能力，使令牌能够反映和管理自身。此政策也会分配给 root 令牌，并且默认附加到所有令牌。

政策语法

政策使用 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 能力允许访问受 root 保护的路径（请参阅受 root 保护的端点教程部分）。deny 能力会停用对路径的访问权限。如果与其他能力一起使用，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 中的每项操作都有对应的路径和能力，即使 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"] 注意：请注意，附加的政策是 root 政策。

2. root 政策允许您在 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 政策的用户身份运行同一命令。

3. 首先启用 userpass 身份验证方法，并创建新用户：

vault auth enable userpass vault write auth/userpass/users/example-user password=password!

4. 随后使用您创建的新用户登录 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 注意：请注意，附加的政策是 default 政策。

5. 再次运行之前的命令，检查政策功能：

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 请求。由于您收到了表示权限遭拒的错误，因此无法访问该路径并列出 Secret 引擎。下面该您来编写自己的第一项政策了，目标是获取对该路径的访问权限并列出 Secret 引擎！

任务 4. 创建政策

由于 Vault 集中保护、存储和控制分布式基础设施及应用中的密钥的访问，因此在任何用户或机器获得访问权限之前，控制权限至关重要。

为满足此需求，解决方案是限制使用 root 政策，并编写精细的政策来践行最小权限原则。例如，如果应用从 Vault 获取 Google Cloud 凭据，则写入政策会授予从 Google Cloud Secret 引擎读取的权限，但不会授予删除等权限。

政策会附加到令牌和角色，以在 Vault 上强制执行客户端权限。至此，您已经了解了政策的语法定义方式，接下来可以编写您的第一项 Vault 政策了。

登录 Vault 网页界面

1. 首先，点击 Cloud Shell 工具栏上的“网页预览”图标。

2. 点击Change port（更改端口）。

3. 将端口号更改为 8200，然后点击 Change and Preview（更改并预览）。

4. 系统应该会将您重定向至 Vault 登录页面。

5. 输入您在本实验前面步骤中保存的根令牌，然后点击 Sign In（登录）。

您的 Vault 开发服务器应类似于下面这样。

现在您已登录开发服务器 Web 界面，可以继续前往下一部分了。

创建新政策

1. 在首页中，点击 Access control（访问权限控制）。您应该会看到 default 和 root ACL 政策。

2. 点击 Create ACL policy（创建 ACL 政策）。

3. 首先将政策命名为 demo-policy。

您现在可以开始编写政策了。回想一下，在上一部分中，您无法访问 sys/mounts 路径来读取 Secret 引擎。现在您将添加该路径。

4. 在 Policy rules（政策规则）中，选择 Code editor（代码编辑器）并添加以下占位符代码：

path "path" { capabilities = [""] }

5. 现在，我们先将 path 更新为之前尝试访问的 sys/mounts 路径：

path "sys/mounts" { capabilities = [""] }

6. 接下来，您要添加一项能力。Vault 尝试在此路径上执行 GET API 调用，因此您需要具有 read 能力。将 read 添加到能力列表中：

path "sys/mounts" { capabilities = ["read"] }

您的政策应如下所示：

7. 点击 Create policy（创建政策）。

现在，您需要将此政策与之前创建的 example-user 相关联。

8. 点击 Back to main navigation（返回主导航）。

9. 点击左侧窗格中的 Access > Authentication methods（访问 > 身份验证方法），然后点击 userpass。

10. 点击 example-user 用户旁边的三点状图标，然后选择 Edit user（修改用户）。

11. 在 password（密码）字段下方，点击 Tokens（令牌）以打开子菜单。

12. 在 Generated Token's Policies（生成的令牌的政策）下，添加您刚刚创建的政策 (demo-policy)，然后点击 Add（添加）。

13. 点击 Save（保存）。

太棒了！您已经创建了新政策，并将其与 example-user 相关联。

14. 返回 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

在您为该用户添加了政策之后，为什么会出错？原因在于，一旦您将新政策与用户相关联，该政策就不会与该用户的现有令牌相关联。要解决此问题，您需要为该用户生成一个新令牌，以便将新政策附加到该令牌。

15. 运行以下命令，登录并为 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

16. 现在再次尝试列出 Secret 引擎：

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..

17. 您还可以使用 vault token capabilities 命令来检查令牌的能力。运行以下命令，验证您在 sys/mounts 路径上的政策：

vault token capabilities <your token> sys/mounts

输出应该如下所示：

read

18. 随后检查 sys/policies/acl 路径的令牌能力：

vault token capabilities <your token> sys/policies/acl

输出应该如下所示：

deny

19. 如需进行验证，请尝试运行以下命令来列出政策：

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；您也需要添加此能力。我们来更新现有政策，以解决此问题。

20. 返回您在 Vault 界面中创建的 demo-policy。

21. 点击 Edit policy（修改政策）。

22. 在 Policy（政策）框中，在您编写的现有政策下添加以下占位符代码：

path "path" { capabilities = [""] }

23. 同样，我们首先将 path 更新为要访问的 sys/policies/acl 路径：

path "sys/policies/acl" { capabilities = [""] }

24. 接下来，您要添加能力。 Vault 尝试在该路径上执行 GET API 调用，因此您需要再次添加 read 能力。此外，该尝试在网址中传入了 list=true，因此您也需要添加此能力。

path "sys/policies/acl" { capabilities = ["read", "list"] }

更新后的政策现在应如下所示：

25. 点击 Save（保存）。

26. 返回 Cloud Shell 并再次运行以下命令：

vault policy list

您的输出结果现在应该如下所示：

default default-ceiling demo-policy root

27. 运行以下命令，将政策的值复制到一个文本文件中：

vault policy list > policies.txt

28. 最后，再次检查 sys/policies/acl 路径的令牌能力：

vault token capabilities <your token> sys/policies/acl

输出应该如下所示：

list, read

29. 运行以下命令，将政策的值复制到一个文本文件中。请务必将 <your token> 替换为您的令牌的值：

vault token capabilities <your token> sys/policies/acl > token_capabilities.txt

30. 运行以下命令，将 policies 和 token_capabilities 文本文件复制到预先创建的 Cloud Storage 存储桶中，以跟踪您的进度：

export PROJECT_ID=$(gcloud config get-value project) gcloud storage cp *.txt gs://$PROJECT_ID

可以看到，当您修改与用户关联的现有政策时，更改会立即生效，不需要生成新令牌。这是因为每当使用令牌时，系统都会实时解析政策内容。因此，如果修改了政策，那么在下次使用附加了该政策的令牌调用 Vault 时，系统将强制执行修改后的规则。

太棒了！您成功创建了一项政策，该政策授予了对 sys/mounts 路径的读取权限，并将其与一个用户相关联。随后，您添加了另一项政策，以授予对 sys/policies 路径的读取和列出权限。

点击检查我的进度以验证是否完成了以下目标： 创建政策

任务 5. 管理政策

政策在您选择的编辑器中编写。它们可以使用 HCL 或 JSON 编写，上文详细介绍了其语法。保存之后，必须将政策上传到 Vault 才能使用。

在上一部分中，您使用界面编写并管理了一项政策。本部分将介绍用于管理政策的 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、界面或 API 创建（上传）政策。在上一部分中，您只是使用界面创建了 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

2. 检查是否已正确创建文件：

cat example-policy.hcl

3. 现在，使用 vault policy write 命令，创建一个名为 example-policy 的新政策：

vault policy write example-policy example-policy.hcl

如果成功，您应该会看到以下输出内容：

Success! Uploaded policy: example-policy

在此示例中，政策名称为“example-policy”。您可以将此名称视为指向政策 ACL 的指针或符号链接。令牌根据名称附加到政策，然后映射到与该名称对应的一组规则。

更新政策

您可以通过 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

2. 检查是否已正确创建文件：

cat example-policy.hcl

3. 更新政策：

vault write sys/policy/example-policy policy=@example-policy.hcl

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

4. 运行以下命令，将政策文件复制到预先创建的 Cloud Storage 存储桶中，以跟踪您的进度：

gcloud storage cp example-policy.hcl gs://$PROJECT_ID

点击检查我的进度以验证是否完成了以下目标： 使用 CLI 命令创建和管理政策

删除政策

现有政策可通过 CLI、界面或 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

2. 使用以下命令列出您的政策：

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 身份验证时，他们将获得一个附加了政策列表的令牌。

2. 运行以下命令，向 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>

2. 令牌在创建时与其政策相关联。运行以下命令，创建具有 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. Secret 政策

在本部分中，您将创建 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 中的所有 Secret。

创建管理员政策

就本实验而言，admin 用户必须能够：

• 读取系统健康检查
• 在 Vault 中广泛创建和管理 ACL 政策
• 在 Vault 中广泛启用和管理身份验证方法
• 管理在 secret/ 路径处启用的键值对 Secret 引擎

1. 在 Vault 界面中，通过左侧窗格前往 ACL policies（ACL 政策）。您应该会看到 default、default-ceiling、demo-policy 和 root 政策。

2. 点击 Create ACL policy（创建 ACL 政策）。

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"] }

您的政策应如下所示：

5. 点击 Create policy（创建政策）。

创建 appdev 政策

在本实验中，appdev 用户必须能够：

• 创建、读取和更新 Secret 引擎
• 管理在 secret/appdev/ 路径下启用的键值对 Secret 引擎

1. 返回 ACL Policies（ACL 政策）页面。

2. 点击 Create ACL policy（创建 ACL 政策）。

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"] }

5. 点击 Create policy（创建政策）。

创建安全政策

在本实验中，security 用户必须能够：

• 在 Vault 中广泛创建和管理 ACL 政策
• 管理 Secret 引擎
• 管理在 secret/ 路径处启用的键值对 Secret 引擎
• 无权读取或列出 secret/admin 路径上的 Secret

1. 返回 ACL Policies（ACL 政策）页面。

2. 点击 Create ACL policy（创建 ACL 政策）。

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"] }

5. 点击 Create policy（创建政策）。

创建 Secret

现在您已经创建了不同的政策，下面就该创建一些 Secret 了。

1. 返回 Cloud Shell，运行以下命令，在 secret/security 路径中创建一些 Secret：

vault kv put secret/security/first username=password vault kv put secret/security/second username=password

2. 在 secret/appdev 路径中创建一些 Secret：

vault kv put secret/appdev/first username=password vault kv put secret/appdev/beta-app/second username=password

3. 在 secret/admin 路径中创建一些 Secret：

vault kv put secret/admin/first admin=password vault kv put secret/admin/supersecret/second admin=password

验证 appdev 安全性

现在您已经创建了一些 Secret，下面我们来验证一下这些政策是否正在执行。您首先要以 app-dev 用户身份登录，看看您拥有哪些访问权限。

1. 运行以下命令，以 app-dev 用户身份登录：

vault login -method="userpass" username="app-dev" password="appdev123"

2. 现在尝试提取 appdev/first Secret：

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

3. 提取位于 secret/appdev/beta-app/second 的 Secret：

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

4. 创建新 Secret：

vault kv put secret/appdev/appcreds credentials=creds123

5. 销毁 Secret：

vault kv destroy -versions=1 secret/appdev/appcreds

6. 尝试从 secret/security 获取 Secret：

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

7. 尝试列出 secret/ 中的所有 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 路径中提取和创建了 Secret，并验证了您无法访问该路径之外的 Secret。

验证安全政策

1. 运行以下命令，以 security 用户身份登录：

vault login -method="userpass" username="security" password="security123"

2. 现在尝试提取 security/first Secret：

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

3. 提取位于 secret/security/second 的 Secret：

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

4. 在 secret/security/supersecure 中创建一个新 Secret：

vault kv put secret/security/supersecure/bigsecret secret=idk

5. 销毁 Secret：

vault kv destroy -versions=1 secret/security/supersecure/bigsecret

6. 尝试从 secret/appdev 读取 Secret：

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

7. 尝试列出 secret/ 下的所有 Secret：

vault kv list secret/

您应该会看到下面的输出内容：

Keys ---- admin/ appdev/ security/

8. 启用新的 Secret 引擎：

vault secrets enable -path=supersecret kv Success! Enabled the kv secrets engine at: supersecret/

9. 尝试查看 secret/admin/first Secret：

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

10. 尝试列出 secret/admin 处的 Secret：

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，并能启用 Secret 引擎。同时，系统已按照政策规定，拒绝了您对 secret/admin 路径的访问。

验证管理员政策

1. 运行以下命令，以 admin 用户身份登录：

vault login -method="userpass" username="admin" password="admin123"

2. 现在，尝试提取 admin/first Secret：

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

3. 提取位于 secret/security/first 的 Secret：

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

4. 创建新 Secret：

vault kv put secret/webserver/credentials web=awesome

5. 销毁 Secret：

vault kv destroy -versions=1 secret/webserver/credentials

6. 尝试从 secret/appdev 获取 Secret：

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

7. 尝试列出 secret/appdev 下的所有 Secret：

vault kv list secret/appdev/

您应该会看到下面的输出内容：

Keys ---- appcreds beta-app/ first

8. 列出所有政策：

vault policy list

您应该会看到下面的输出内容：

admin appdev default default-ceiling demo-policy security root

9. 运行以下命令，将政策值复制到文本文件中，然后将其上传到 Cloud Storage 存储桶：

vault policy list > policies-update.txt gcloud storage cp policies-update.txt gs://$PROJECT_ID

10. 启用 gcp 身份验证方法：

vault auth enable gcp

11. 最后列出已启用的身份验证方法：

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

太棒了，您已确认自己拥有与所编写政策关联的管理员权限。

点击检查我的进度以验证是否完成了以下目标： Secret 政策

路径

您可能已经看到，为 security 用户提供的政策代码中引入了您之前未见过的两个主题：data/ 和 metadata/。

metadata/ 路径端点会返回指定位置的键名列表。此外，使用此命令无法访问值本身。写入和读取版本的前缀为 data/。列出、读取和销毁操作如下：

• 写入和读取版本 - data/
• 列出密钥 - metadata/
• 读取版本 - metadata/
• 销毁 Secret 的版本 - destroy/
• 销毁一个键的所有元数据版本 - metadata/

例如，如果您要拒绝访问 secret/example 中的 Secret，则需要使用以下 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 的更多信息

• Vault 入门教程
• Vault 文档
• Vault 政策文档
• Vault 政策教程

Google Cloud 培训和认证

…可帮助您充分利用 Google Cloud 技术。我们的课程会讲解各项技能与最佳实践，可帮助您迅速上手使用并继续学习更深入的知识。我们提供从基础到高级的全方位培训，并有点播、直播和虚拟三种方式选择，让您可以按照自己的日程安排学习时间。各项认证可以帮助您核实并证明您在 Google Cloud 技术方面的技能与专业知识。

本手册的最后更新时间：2026 年 6 月 4 日

本实验的最后测试时间：2026 年 6 月 4 日

版权所有 2026 Google LLC 保留所有权利。Google 和 Google 徽标是 Google LLC 的商标。其他所有公司名和产品名可能是其各自相关公司的商标。