Securing Client Tiered Storage Access

[leekeiabstraction]

Hey all,

Following up on Slack conversation, I've written up a short doc to drive discussion on how we can improve the token vending of Fluss.

The primary motivations are:

1. Securing access: clients can be compromised and if they are, attackers will be able to perform all actions they are authorised to. The improvements that can be made here are two fold. First, we can downscope to least-privileged i.e. read actions on allowed buckets only. Second, we can annotate the specific session so that it is trace-able to the client. This allows users to distinguish API calls made by specific clients in their logs and also deny permission to compromised sessions via RBAC.
2. Refactoring: The interfaces and classes for credentials and token vending are overloaded and can be confusing for developer. This is a good opportunity to refactor that.

Would love your thoughts here before I proceed to prototyping

https://docs.google.com/document/d/1y8EWYwqXiiDyo2A9USFqgyqjBVm56dMz4VJPYVJ8dME/edit?usp=sharing

[wuchong]

Hi @leekeiabstraction,

Thanks for starting this discussion. However, as an Apache Software Foundation (ASF) project, formal technical discussions should take place on the dev@ mailing list. As the ASF saying goes: "If it didn't happen on the mailing list, it didn't happen."

You can subscribe to the dev@ mailing list here:
https://fluss.apache.org/community/welcome/#mailing-lists