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

Posted 2023-04-19

【中文标题】如何在生产中使用 Hashicorp Vault 的 AppRole？

【英文标题】：How to use Hashicorp Vault's AppRole in production?

【发布时间】：2019-12-26 18:22:52

【问题描述】：

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

我已经阅读了使用 AppRoles 的概念，它们似乎非常适合我们的用例，但在此到期之前。我们不想每个月都重新生成secret_id。

根据我的阅读，如果您在没有设置secret_id_ttl 的情况下创建角色，它应该不会过期，但事实并非如此。这可能是由于 AppRole 身份验证方法的配置方式，但我没有看到任何可靠的东西。

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

最后，我希望secret_id 不会过期。永远。

【问题讨论】：

我认为这里的根本误解是 Vault 希望机密是动态的——这意味着出于安全目的按需生成和短暂存在。如果您不想频繁轮换机密，Vault 不适合这样做。

【参考方案1】：

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

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

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

【参考方案2】：

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

话虽如此，这是我根据 Vault 文档中的几篇文章使用的过程，但主要是 AppRole Pull Authentication。

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

注意：对于为以下字段提供的值，vault 似乎接受的最大值是 999,999,999。对于 TTL 字段，这是超过 31 年的秒数。这不是永远，但它已经足够长，更新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，您就可以开始了。

【参考方案3】：

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

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

其他巧克力蛋糕信息：理想情况下，最好保留 TTL 低，最多 30 分钟 - 如果您的应用程序是有状态的，或者 如果它是一个无状态的应用程序，可能会更少。的秘钥 Vault approle 也应该每 90 天轮换一次。请注意 默认情况下，Vault approle 后端有 31 天的 TTL，所以如果你想 设置为90天，你需要增加approle后端的TTL为 好吧。

但是（在同一个问题中）：

您可以生成无限期的秘密 ID。但这样做会 就像把你的秘密保存在配置文件中一样好。

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

想法：

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