如何在生产中使用 Hashicorp Vault 的 AppRole？

Question

我们已经为一台服务器安装并配置了 Hashicorp Vault AppRole 身份验证，方法是将 role_id 和 secret_id 存储在服务器的本地文件中，我们可以在服务器从文件中读取值，向 Vault 进行身份验证，接收令牌，然后从 Vault 中读取所需的秘密。到目前为止，一切都很好。但是，secret_id 在 31 天后过期，因此该过程失败。

我已经阅读了有关使用 AppRoles 的概念，它们似乎非常适合我们的用例，但对于这个过期。我们不想每个月都重新生成 secret_id。

根据我的阅读，如果您创建角色时没有设置 secret_id_ttl 它应该不会过期，但事实并非如此。这可能是由于 AppRole auth 方法的配置方式所致，但我还没有看到任何可靠的信息。

所以我找到了一个 article on the Hashicorp website，其中详细讨论了 AppRoles。这篇文章为在 CI/CD 环境中使 secret_id 过期提供了很好的论据，甚至通过 8 个简单的步骤说明了这是如何工作的。我明白这是如何工作的，但这篇文章没有提到 CI/CD 和 Orchestrator 系统本身已通过 Vault 身份验证？还是我遗漏了什么？

最后，我希望 secret_id 不会过期。曾经。

Answer 1

这可能不是规范的答案，但我发现它是空的，所以决定添加一些指示。

根据Hashicorp Vault AppRole: role-id and secret-id：

Additional brownie information: Ideally, it's best practice to keep the TTL low, 30 minutes max - if your application is stateful, or maybe even less if it's a stateless application. The secret key of Vault approle should also be rotated every 90 days. Please note by default, Vault approle backend has 31 days of TTL, so if you want to set it to 90 days, you need to increase TTL of the approle backend as well.

然而（同题）：

You can generate secret-id with indefinite validity. But doing so will be as good as keeping your secrets in the configuration file.

对于临时实例，您可以使用配置管理通过第三方（代理）角色传递秘密。关于无限期存在的服务器，我还在研究中...

想法：

TLS 证书可能在 Windows 上运行良好，不知道 Linux。
GitHub 个人访问令牌，但这不是 org.友好。
查看其他 auth methods 可用的，看看是否有满足您要求的（例如 AWS）。

Answer 2

如果您的环境没有额外的支持，您将不得不在安装程序中编写一些逻辑，并有某种服务管理器来启动您的服务。在许多云环境中，您可能已经拥有等效的实体（Terraform、Cloud Formation 等），您应该在需要时利用它们的机密管理功能。

对于自定义安装，这是我使用的工作流程。

有一个可以调用来执行安装/升级的安装管理器进程。确保服务的安装/升级始终通过此过程。
有一个服务管理器进程负责启动各个服务并监视它们/重新启动它们。确保服务启动始终通过此服务管理器。
在安装过程中，为 Vault、安装管理器和服务管理器生成自签名证书。保管库证书应该信任安装管理器和服务管理器的证书。将这些以有限权限 (600) 存储在安装用户或服务管理器用户拥有的目录中（视情况而定）。使用这些证书在 Vault 中设置基于证书的身份验证。
这些凭据应该具有与其关联的有限功能。安装管理员应该只能创建新角色而不能删除任何内容。服务管理员应该只能为安装管理员创建的命名角色创建机密，并且不能删除任何内容。
在安装/升级期间，安装管理器应连接到 Vault 并创建所有必要的服务特定角色。它还应该能够在服务可能在启动时读取的每个服务配置文件中为各个服务设置角色 ID。
在每个服务启动期间，服务管理器应连接到 Vault 并创建与每个服务角色相对应的秘密 ID。它应该在环境变量中设置秘密 ID 并启动服务。 secret id 应该有时间限制的有效性（通过设置 TTL），这样它们就不能用于创建 auth 令牌之外的更多用途（参见#7）。
每个服务都应该从配置文件中读取角色 ID，并从环境变量中读取秘密 ID。然后它应该使用这两个生成身份验证令牌，并使用令牌在其生命周期内通过保险库对自己进行身份验证。

Answer 3

可以使用 secret_id 创建基本上永不过期的 Vault AppRole。但是，这应该仅限于在 Vault 开发服务器上使用——不包含任何生产凭证的服务器——以及在开发环境中使用。

也就是说，这是我根据 Vault 文档中的几篇文章使用的过程，但主要是 AppRole Pull Authentication。

这假定 Vault approle 身份验证方法已安装在 approle/ 并且您已登录到 Vault，在保管库服务器并具有有效的、未过期的令牌。

注意： 对于为以下字段提供的值，vault 似乎接受的最大值是 999,999,999 .对于 TTL 字段，这是超过 31 年的秒数。那不是 forever，但它足够长，更新 secret_id 可能是别人的问题 (SEP)。

# Vault server address to be used by the Vault CLI.

export VAULT_ADDR="https://vault-dev.example.com:8200/"

# Vault namespace to be used by the CLI. 
#   Required for Cloud and Enterprise editions
#   Not applicable for Open Source edition

export VAULT_NAMESPACE="admin"

# The name of the Vault AppRole

export VAULT_ROLE=my-approle

# Override defaults on the approle authentication method

#   NOTE: In this command, the field names, default-lease-ttl
#         and max-lease-ttl contain dashes ('-'), NOT 
#         underscores ('_'), and are preceded by a single
#         dash ('-').

vault auth tune \
  -default-lease-ttl=999999999 \
  -max-lease-ttl=999999999 approle/

# Override defaults on the approle

#   NOTE: In this command, the field names, secret_id_ttl and 
#         secret_id_num contain underscores ('_'), NOT
#         dashes ('-'), and are NOT preceded by a single
#         dash ('-'). 

vault write auth/approle/role/my-approle \
  secret_id_ttl=999999999 \
  secret_id_num_uses=999999999

# Create a new secret_id for the approle which uses the new defaults

vault write -f auth/approle/role/my-approle/secret-id

更新服务器配置文件以使用新的 secret_id，您就可以开始了。

如何在生产中使用 Hashicorp Vault 的 AppRole？

How to use Hashicorp Vault's AppRole in production?

app-secret

hashicorp-vault