-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3 credentials API #2
Comments
Thanks for the links, this is all good to know! I didn't know how far MinIO's emulation of the S3 API extended. The current (questionably functioning) code is here. In theory, one could override the service endpoint for STS to point to MinIO, but I wouldn't try it until the S3 implementation works The other main barrier right now is that even with wire-level API compatibility, the bucket names and regions are hard-coded, so outside of testing where folks are building the codebase, some upstream changes would need to be made for a setup like this to work |
Good investigation work. I'm all in for upstream changes, and will support the argumentation, when due. |
The readme mentions short-lived S3 credentials, which are passed to the current client for syncing, and considers how to mobilise Minio for that.
I'm bringing this up, because there are a few ways this could be achieved with Minio and its Secure Token Service (STS), a bit depending on the authentication scheme used for a LogSeq Sync endpoint.
Given the spread of its adoption, it may be safe to assume OIDC here, not having to develop an external identity management plugin for Minio? Or can there be a more generic way to create temporary tokens, which is unified across S3 implementations?
The S3 itself can also store the documents in an encrypted way, and uses an external KMS in conjunction with the Kes.dev keyserver, but that's a totally different subject.
The text was updated successfully, but these errors were encountered: