6

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

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

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

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

最后，我想让它secret_id不会过期。曾经。

4

3 回答 3

3

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

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

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

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

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

这假设 Vaultapprole身份验证方法已安装在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，您就可以开始了。

于 2021-07-21T13:39:11.293 回答
0

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

根据Hashicorp Vault AppRole： role-id 和 secret-id：

额外的巧克力蛋糕信息：理想情况下，最好将 TTL 保持在较低水平，最长 30 分钟 - 如果您的应用程序是有状态的，或者如果它是无状态应用程序，则可能更少。Vault approle 的密钥也应该每 90 天轮换一次。请注意，Vault approle 后端默认有 31 天的 TTL，所以如果您想将其设置为 90 天，您还需要增加 approle 后端的 TTL。

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

您可以生成无限期的秘密 ID。但是这样做与将您的秘密保存在配置文件中一样好。

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

想法：

  • TLS 证书可能在 Windows 上运行良好，不了解 Linux。
  • GitHub 个人访问令牌，但这不是 org. 友好。
  • 查看其他可用的身份验证方法，看看是否有适合您的要求的方法（例如 AWS）。
于 2019-09-06T06:02:40.897 回答