Looking a bit more into the PR, I think it is primarily about avoiding an
STS call rather than about "raw" credentials.

I think the STS requirement can, indeed, be a blocker for some custom S3
implementations.

If we want to support those, we could allow the admin user to configure a
separate set of credentials for vending to clients with rotation. Those
credentials would be distinct from the credentials Polaris users for itself.

Obviously, proper secret rotation will require more work than what's in the
linked PR.

Cheers,
Dmitri.

On Fri, Dec 6, 2024 at 6:16 PM Michael Collado <collado.m...@gmail.com>
wrote:

> Hey folks
>
> Someone pinged about https://github.com/apache/polaris/pull/389 yesterday
> and I thought it was worth bringing up for discussion.
>
> On-prem s3 compat sounds like a super useful feature and I'm fully on board
> with supporting it, but I think we need to make a decision about whether we
> support vending long-lived storage credentials in the REST endpoint. I
> think we generally favor compatibility and extensibility, but I am of the
> opinion that we should disallow obvious security risks, such as vending
> long-lived credentials. The blast radius of accidentally vending
> short-lived tokens is fairly contained, whereas the consequences of vending
> long-lived credentials can be unbounded.
>
> I think this is one of those areas where the project/community should be
> opinionated and say we should not sacrifice security for the sake of
> compatibility with specific environments. If some environments promote less
> secure credential handling by disallow session token generation, then we
> should simply not support those environments.
>
> What are your thoughts on that issue? Is that a suitable design tenet we
> can add to our project documentation? Or am I just being stubborn?
>
> Mike
>

Reply via email to