这显然是一个愚蠢的问题，因为我找不到答案，但我对Hashicorp Vault和获取机密的方式感到困惑。
Vault的部分理念是，您可以将机密存储在其中，而不需要将一堆敏感的东西粘在可检查的环境变量中。
假设您有一个Vault服务在某个地方运行，其中包含一些机密，并且您需要使用令牌对Vault进行身份验证，以便在docker容器中的脚本中获取机密，那么令牌是如何进入的？当然，如果你使用一个环境变量，那就没有意义了，因为有人可以接受这个令牌。您是否装入了包含它的卷？或者更具创造性的东西？
一些需要考虑的事情，没有特别的顺序：
- 是的，如果攻击者能够检查正在运行的应用程序的属性，他们很可能会读取其中的任何机密。要创建一个安全的应用程序，面对有足够权限在应用程序中四处走动的攻击者，是非常困难的
- 如果env-var持有一个令牌，那么这不是一个直接可用的秘密——攻击者需要使用它从Vault中检索实际的秘密。虽然这是可以实现的，但它确实带来了额外的困难
- 令牌的创建寿命有限，因此在一段时间后，就无法再使用它从Vault中检索机密
- 令牌也可以通过有限的使用次数(例如一次(来创建。这意味着，一旦应用程序使用该令牌来检索机密，该令牌就不再可用
- Vault支持原始令牌以外的其他身份验证机制。例如，正如@davidmaze在评论中所提到的，如果应用程序在Kubernetes下运行，那么您可以将Vault设置为使用k8s ServiceAccount进行身份验证(不需要直接令牌(
- 在容器中具有外壳访问权限的攻击者并不是唯一需要保护的载体。仅仅保守源代码的秘密(尤其是源代码控制(是一件非常重要的事情
- 简单的密钥/值并不是Vault可以管理的唯一一种机密。它还可以自动生成AWS的访问令牌和Postgres的凭据，以及许多其他功能
关于您的直接问题
代币是如何进入的？
有多种方法可以实现。简单地替换环境变量是一种选择，但它也可以安装在卷中，作为参数传递，提供API调用，从数据库中提取，或任何其他您可以想象的方式。这完全取决于您的部署过程、威胁模型、风险评估、应用程序详细信息，以及您是否可以使用其他身份验证机制等