为部署提供凭据

Goal

一个部署在启动时读取密码或 API 密钥，其中材料存储在描述之外且不受版本控制。

Before you start

• 一个你可以更新的部署。
• 一个基于它属于什么而非哪个部署读取它的凭据名称—— 参见 密钥。

Dashboard

Steps

1. 打开部署并选择 密钥。
2. 添加一个引用，命名凭据的路径。
3. 粘贴材料，或要求平台生成它并说明需要哪些密钥以及持续时间。
4. 保存。材料存储在描述之外；描述仅保留引用。

YAML manifest

Steps

1. 添加一个 secrets 条目，其中包含凭据的路径。
2. 提供内联材料，或声明平台应生成它。
3. 应用文档。材料会被写入并在描述存储前被剥离， 因此保留的内容与仅引用的文档相同。字段位于 部署参考。

REST API

Steps

1. PUT /api/v1/deployments/{name}，其中包含 secrets 列表。请记住，发送列表 会替换已存储的列表，因此请整体发送。
2. GET /api/v1/secrets/resources 以查看租户中引用的所有凭据路径。
3. 在轮换之前 GET /api/v1/secrets/resources/{name}/consumers，以查看谁在读取它。
4. POST /api/v1/deployments/{name}/secrets/rotate 以进行轮换并重启。

以文件形式使用密钥

传递方式是通过环境变量。如果请求将密钥材料挂载为文件的路径，系统会明确拒绝而非静默忽略，且拒绝信息会说明原因——必须读取文件的应用程序应在启动时通过其自身的入口点从环境变量中渲染文件内容。

Verify

部署启动，应用程序找到其凭据。存储的描述中不包含该材料，也没有路由返回它。

Evidence this worked

GET /api/v1/deployments/{name}显示引用而非值。消费者路由将此部署列在凭据下，这使得轮换安全：读取器在每次调用时都从存储的描述中派生，因此答案不会过时。

When it fails

• 路径因形状被拒绝。 路径为 <namespace>/<name>，且第一段必须是已授予的命名空间之一 — 第一段是每个 Vault 策略授权所针对的命名空间。
• 路径因拆分被拒绝。 同一凭据已在另一个命名空间下被引用：同一凭据在两个命名空间下是两份 Vault 文档，必须手动保持一致。拒绝信息会指明另一个部署以及需要合并的单一路径。
• 部署在没有凭据的情况下启动。 发送了更短的 secrets 列表的更新替换了已存储的列表。参见 发送描述的一部分。
• 所有代码：拒绝与更改。