0

我们运行一个容器化的 Spring Boot 应用程序。为了访问第三方 API，这些 API 的秘密保存在 Vault 实例中。我们的应用程序使用令牌身份验证通过 Spring Vault Core 连接到 Vault：

spring:
  cloud:
    vault:
      fail-fast: true
      ...
      authentication: token
      session:
        lifecycle:
          refresh-before-expiry: 15s
          expiry-threshold: 25s

令牌在启动时通过环境变量传递给我们的应用程序spring.cloud.vault.token。

令牌本身是使用vault token create -policy=<some policy> -period 4h. 它显示renewable=true并且没有明确的最大 TTL。因此，如果在应用程序生命周期内正确更新，它永远不会过期。这是由 Spring Vault 的LifecycleAwareSessionManager.

现在在测试和生产环境中，生成的令牌实际上会不时过期，即使在过期之前被更新。返回到 Spring Vault 的续订尝试的剩余 TTL 表明 TTL 没有重置，而是继续减少，直到令牌过期。

有谁知道为什么会发生这种情况？或者：即使正确更新，什么可能导致定期服务令牌过期？

4

1 回答 1

1

Two different notes:

  • First, child token cannot outlive it's parent. If the parent token expires, the child token regardless of it's TTL left, will also expire. If you need the token to outlive its parent you need to provide -orphan param when creating the token.
  • Second, renewable does not mean, you can renew forever, you can keep extending the life of a token UP TO the "max ttl". But that's it. The token will expire. "Renew" does not get you a now token, it simply extends the life of the current TTL. You still cannot get past the max-ttl age limit. My suggestion is not to use service tokens, switch to batch tokens (still will run into maxttl issues) or even better an auth system (approle for example) to get your apps access.

If you're in secure environment (kub pods, or locked VM for example) consider using the Vault Agent. It'll help you to keep your session alive.

于 2021-09-26T20:35:48.427 回答