Short lived tokens as credentials

[nresare]

I am currently looking into moving away from long lived tokens for git authentication in flipt. It seems it might be feasible to set something up where a sidecar would renew a short-lived token periodically.

However, looking at the Flipt code, it seems to me like the access_token field in the credentials config, whether read directly from the config file or pulled in through the secrets mechanism with an expression such as ${secret:file:github-token}, is only read from the filesystem on Flipt startup and there are no provisions for reloading short lived data from the filesystem without restarting flipt.

First off, am I right in this assumption, that access_token values are only read on Flipt startup?

Wold you be open to introducing an access_token_path configuration key, which could be read from the filesystem on each attempt along the lines of how the GitAuthentication() method creates a new PublicKeys object on each invocation, reading the file as it is requested?

If you are open to that I would be happy to provide an implementation and give it some real life testing.

Another option would be to have general purpose re-loading of configuration once the file timestamp changes, but this seems like something that could potentially have some non-obvious implications.

[dosubot[bot]]

You're correct: the access_token for git authentication is only read at Flipt startup, whether it's set directly in the config or loaded via the secrets mechanism—there's no dynamic reload without a restart. This is confirmed both in the documentation and in the code handling credentials and config loading, which only runs at initialization and doesn't watch for changes or re-read secrets during runtime (source, source).

Your idea of introducing an access_token_path config key that reads the token from disk on each use is feasible and fits with how Flipt handles public key authentication (where keys are re-read as needed). This targeted approach would avoid the complexity and potential side effects of general-purpose config reloads, which aren't currently supported and could have broader implications (source).

No existing mechanism or discussion was found for dynamic credential reloading, so your proposal would be a new feature. If you move forward with an implementation, it would align well with established patterns in the codebase.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[markphelps]

Hey @nresare great suggestions!

I think it would be great if we could support short lived tokens. Instead of adding a new access_token_path, could we simply have the existing access_token get re-read before making each request? this would be backward compatible and a no-op if reading the value from the config file, but would also support your use case where the access token changes if using the ${secret:file:xxx} syntax.

As far as supporting hot reloading config, this is something ive wanted to implement for a long time! I think I last tried in flipt v1 and you're right there were some non-obvious implications so I abandoned it. It may be doable now though in v2 and is something I'd like to add eventually.

[nresare]

Great that we are both in agreement that this is worth addressing! I will propose some code in the next few days

[pratik0907]

@nresare Any luck here?