Hi all, We now have an interface `UserSecretsManager` for safe storage of secrets (thanks Dennis!).
With that interface we just have one implementation named `UnsafeInMemorySecretsManager`, which is pretty much what the name says. For posterity: it does not persist secrets but only keeps those in memory. This means, all secrets a user thinks are stored, are effectively lost when the single Polaris instance is stopped. Or very clear: `UnsafeInMemorySecretsManager` is NOT for production use. Even clearer: we have no `UserSecretsManager` implementation that can be used by our users, meaning that our users cannot use for example "IMPLICIT authentication". I think this topic deserves some more attention and volunteers for implementations against actual secret managers (hyperscalers and Vault). Honestly, I mostly missed the addition of the `UserSecretsManager` interface and I think we can improve it. The interface requires an entity (it's ID). I don't think that this tight relationship is necessary in the `UserSecretsManager` interface. I think we should also allow users to directly provide a secret, which I don't see being implemented (or even possible?) today. Regular rotation of secrets is a requirement. A secret for S3 for example consists of the "access key ID" and the "secret key" - the actual secret is therefore a tuple of both values. For that it's necessary to have a composite object stored and retrieved atomically in secret managers. Given that there is no production implementation, it is fine to change it. Thoughts on these topics? Robert
