(note: I did not review the PR) On-prem systems usually have different security perimeters than cloud systems.
While vending long-term credentials by default is too risky, I agree, why would Polaris restrict that in controlled environments where the admin user explicitly wants to enable that (e.g. via a deployment time config option for the credentials max duration)? Thanks, 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 >
