AppRole

approle 身份验证方法允许机器或应用程序使用 Vault 定义的角色进行身份验证。AppRole 的开放式设计支持使用不同的工作流和配置来应对大量应用程序。这种身份验证方法主要是面向自动化工作流程（机器和服务）设计的，对人类操作者不太有用。

“AppRole”代表一组 Vault 策略和登录约束，必须满足这些策略才能使用这些策略获取令牌。范围可以根据需要进行调整。可以为特定机器、甚至该机器上的特定用户或跨机器的服务创建 AppRole。成功登录所需的凭据取决于相关联的 AppRole 所设置的约束。

身份验证

通过命令行工具

默认路径是/approle。如果该引擎被挂载了其他挂载点上，请使用 auth/my-path/login 替代：

$ vault write auth/approle/login \
    role_id=db02de05-fa39-4855-059b-67221c5c2f63 \
    secret_id=6a174c20-f6de-a53c-74d2-6018fcceff64

Key                Value
---                -----
token              65b74ffd-842c-fd43-1386-f7d7006e520a
token_accessor     3c29bc22-5c72-11a6-f778-2bc8f48cea0e
token_duration     20m0s
token_renewable    true
token_policies     [default]

通过 API

默认端点是 auth/approle/login。如果该引擎被挂载到了其他挂载点上，请使用其他值代替 approle。

$ curl \
    --request POST \
    --data '{"role_id":"988a9df-...","secret_id":"37b74931..."}' \
    http://127.0.0.1:8200/v1/auth/approle/login

响应中 auth.client_token 字段会包含令牌：

{
  "auth": {
    "renewable": true,
    "lease_duration": 2764800,
    "metadata": {},
    "policies": ["default", "dev-policy", "test-policy"],
    "accessor": "5d7fb475-07cb-4060-c2de-1ca3fcbf0c56",
    "client_token": "98a4c7ab-b1fe-361b-ba0b-e307aacfd587"
  }
}

集成到自己的应用程序：请参阅代码示例部分，了解使用 AppRole 身份验证方法对 Vault 进行身份验证的代码片段。

配置

在用户或机器进行身份验证之前，必须预先配置身份验证方法。这些步骤通常由系统操作员或配置管理工具完成。

通过命令行工具配置

1. 启用 AppRole 身份验证方法：

$ vault auth enable approle

1. 创建一个命名角色：

$ vault write auth/approle/role/my-role \
    secret_id_ttl=10m \
    token_num_uses=10 \
    token_ttl=20m \
    token_max_ttl=30m \
    secret_id_num_uses=40

注意：如果您的 approle 签发的令牌需要能够创建子令牌，您需要将 token_num_uses 设置为 0。

有关配置选项的完整列表，请参阅 API 文档。

1. 获取 AppRole 的 RoleID：

$ vault read auth/approle/role/my-role/role-id
role_id     db02de05-fa39-4855-059b-67221c5c2f63

1. 为指定 AppRole 签发一个 SecretID：

$ vault write -f auth/approle/role/my-role/secret-id
secret_id               6a174c20-f6de-a53c-74d2-6018fcceff64
secret_id_accessor      c454f7e5-996e-7230-6074-6ef26b7bcf86
secret_id_ttl           10m

通过 API 配置

1. 启用 AppRole 身份验证方法：

$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data '{"type": "approle"}' \
    http://127.0.0.1:8200/v1/sys/auth/approle

1. 创建包含指定策略的 AppRole：

$ curl \
    --header "X-Vault-Token: ..." \
    --request POST \
    --data '{"policies": "dev-policy,test-policy"}' \
    http://127.0.0.1:8200/v1/auth/approle/role/my-role

1. 获取 AppRole 的 ID：

$ curl \
    --header "X-Vault-Token: ..." \
    http://127.0.0.1:8200/v1/auth/approle/role/my-role/role-id

响应看起来大概是这样的：

{
  "data": {
    "role_id": "988a9dfd-ea69-4a53-6cb6-9d6b86474bba"
  }
}

1. 用该角色创建一个新的 SecretID：

curl \
    --header "X-Vault-Token: ..." \
    --request POST \
     http://127.0.0.1:8200/v1/auth/approle/role/my-role/secret-id

响应看起来可能是这样的：

{
  "data": {
    "secret_id_accessor": "45946873-1d96-a9d4-678c-9229f74386a5",
    "secret_id": "37b74931-c4cd-d49a-9246-ccc62d682a25",
    "secret_id_ttl": 600
  }
}

凭据和约束

RoleID

RoleID 是一个标识符，指定用来计算拥有的凭据的 AppRole。在针对此身份验证方法的登录端点进行身份验证时，RoleID 始终是必需的参数（通过 role_id）。默认情况下，RoleID 是一个全局唯一的 UUID，但是，它们可以被设置为特定值。

SecretID

SecretID 是默认情况下任何登录（通过 secret_id）都需要的凭据，并且应该始终保密。 （一种进阶用法，可以通过设置 AppRole 的 bind_secret_id 参数来避免传递 SecretID，允许只知道 RoleID 或匹配其他设置约束的机器获取令牌）。可以通过角色本身生成 128 位纯随机 UUID（Pull模式），或通过特定的自定义值（Push 模式）针对 AppRole 创建 SecretID。与令牌类似，SecretID 具有使用限制、TTL 和过期等属性。

Pull 和 Push 模式

如果用于登录的 SecretID 是从 AppRole 获取的，则这是在 Pull 模式下运行。如果客户端针对 AppRole 设置了“自定义”SecretID，则称为 Push 模式。Push 模式模仿已弃用的 App-ID 身份验证方法的行为；然而，在大多数情况下，Pull 模式是更好的方法。原因是 Push 模式需要其他一些系统了解完整的客户端凭据集（RoleID 和 SecretID）才能创建条目，即使这些凭据是通过不同路径分发的。但是，在 Pull 模式下，即使必须知道 RoleID 才能将其分发给客户端，也可以通过使用响应封装对除终端用户以外的所有各方保密 SecretID。

Push 模式可用于和 App-ID 工作流保持兼容性，在某些特定情况下更可取，但在大多数情况下，Pull 模式更安全，应该首选 Pull 模式。

进一步的约束

role_id 是登录端点所需的凭据。 role_id 指向的 AppRole 将对其设置约束。这决定了登录所需要的其他 required 的凭据。 bind_secret_id 约束要求在登录端点使用 secret_id 的值。展望未来，此身份验证方法可以支持更多约束参数来支持不同的应用集合。某些约束不需要凭据，但仍会强制执行登录约束。例如，secret_id_bound_cidrs 将只允许 IP 在 CIDR 块范围内的 AppRole 的登录。