HashiCorp Vault：将 Secret_id 包装在 appRole 身份验证中有何安全优势？

Question

我们的用例是一个 jenkins 运行程序，计划每年运行 1 次，并发出特定的保管库写入命令（CSR 的 pki 标志）。它需要一个 ttl=0 的“长期运行”秘密来执行此操作，并且不能使用令牌，但必须使用带有 approle 或 userpass 身份验证方法的 Secret_ID。

这个想法是，对于此操作，跑步者上有一个可用的 SecretID+角色 ID（如用户名+通行证）：

但是！

最佳实践建议包装 Secret_id 并拥有初始令牌。是什么让这个更安全，以及哪些特定攻击使得额外的配置值得。 ttl=0 的永久令牌/秘密是否仍然需要保存在某个地方？

资源： https://www.hashicorp.com/blog/how-and-why-to-use-approle- Correctly-in-hashicorp-vault https://www.hashicorp.com/resources/vault-response-wrapping-makes-the-secret-zero-challenge-a-piece-of-cake

Answer 1

您所描述的是推式和拉式AppRole身份验证之间的区别，并且文档解释了两者之间的一些高级差异。该文档还链接到响应包装文档，进一步解释了其优点。您和文档所指的“包装”是 AppRole 的拉取方法。

两者在安全性方面的重要区别（这是您在这里的主要问题）是，在推送模式下，Jenkins 将包含用于身份验证的角色和秘密 ID。在拉模式下，Jenkins 只知道角色 ID，并且会从其自身和 Vault 之间的中介接收动态生成的秘密 ID。请注意，Jenkins 可以在此过程中既充当消费者又充当中介，但这会大大削弱安全优势。

对于拉取优于推送的情况之一，一个简单的场景是攻击者获得对 Jenkins 的访问权限，从而获得对角色 ID 和静态秘密 ID 的访问权限。然后，攻击者可以轻松地使用关联的 Vault 策略来冒充 Jenkins 代理，生成未包装的令牌，并开始检索授权的秘密而不受惩罚。相反，如果 AppRole 配置为 pull，则攻击者只能获得对角色 id 的访问权限，并且在尝试请求动态秘密 id 并解开临时令牌进行身份验证时会被中间实体拒绝。这就是攻击期间成功和不成功的违规之间的区别。