Question

我们通过将role_id和secret_id存储在服务器上的本地文件中，为一台服务器安装并配置了Hashicorp Vault AppRole身份验证，并且能够读取服务器上的代码文件中的值，通过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 系统本身如何通过保险柜验证？还是我错过了什么？

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

Answer 1

这可能不是标准答案，但是我发现它是空的，因此决定添加一些指针。

根据numpy.random.choice：

其他布朗尼信息：理想情况下，最好的做法是保留 TTL低，最长30分钟-如果您的应用是有状态的，或者如果是无状态应用程序，则可能更少。的秘诀保管箱方法也应每90天轮换一次。请注意默认情况下，保管箱应用程序后端具有31天的TTL，因此如果您要将其设置为90天，则需要增加该后端的TTL，好吧。

但是（在同一问题中）：

您可以生成有效期不确定的secret-id。但是这样做会最好将您的秘密保存在配置文件中。

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

想法：

TLS证书可能在Windows上运行良好，对Linux不了解。
GitHub个人访问令牌，但这不是组织。友好。
查看其他可用的Hashicorp Vault AppRole: role-id and secret-id，看看是否有满足您要求的设备（例如AWS）。

Answer 2

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

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

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

Answer 3

可以创建具有基本上永不过期的 secret_id 的保险柜 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，您就可以开始使用了。

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

3 个答案: