Hi R.J., Thanks for answering these questions.
> If anything if a user going directly to the STS they’d get MORE permissions, which is totally fine and completely reasonable. This is not the security model that Polaris currently uses. And while in your use case this statement is acceptable to you, this is *not* broadly acceptable. To restate the above statement IOW: it is completely acceptable for users to skirt around Polaris authorization results and I completely disagree that Polaris should publicly support a feature that enables such behavior. I understand if Polaris' authorization is not important to your use case, but that is definitely not broadly the case. On the topic of auditing: if a user can simply bypass Polaris and talk to "STS" to start accessing data, I am assuming that your auditing mechanisms do not rely on Polaris' logs being all-encompassing of users' accesses of data. Given that is true, is it fair to say in your use case, Polaris is not much of a governance tool as much as it is just a simplistic metastore? On a slightly tangential note, I would like to know more as to why you need credential vending in Polaris if your users have the ability to mint their own credentials from STS? Is what you need able to be achieved by making a slight modification to the Iceberg client instead? Can you explain why Polaris is the right place for this change? > it will enable Polaris to support on-prem S3 use cases like [3], making it more widely available for everyone I agree that we should aim to support more use cases - but in a secure way that works in a broadly acceptable manner with Polaris' core functionalities (such as authorization and access control). I'm definitely happy to brainstorm how to make this design more secure and broadly usable - either here or on a different thread. Best, Adnan Hemani On Thu, Dec 4, 2025 at 11:22 AM Arsenault, Reginald P. via dev < [email protected]> wrote: > UNCLASSIFIED / NON CLASSIFIÉ > > Hi Laurent, Thanks for your questions! > > > I'm a big fan of those token exchange scenarios which avoid to create > long lived secrets to interact between systems, and rely instead of setting > trust mechanisms between them. > > We are too, which is why can’t go with the standard > access-key-id/access-key-secret setup that a regular AWS S3 system uses. By > passing along the short lived JWT token of the user to the STS, we can get > a new, short-lived, access-key-id/access-key-secret for our on-prem S3 > buckets with every request. Having one generic service account doing all > the operations on the S3 for all our users is a security risk for us. > > > > My main question is that if the authorization token sent to polaris is > passed as-is to the STS server, what happens if the client directly sends > the token to the STS system directly? > > For our on-prem S3/STS setup we have no issue with users accessing STS > System directly. It is normal for users to be able to access the buckets. > The STS checks the permissions users have on the buckets they’re > requesting, so there is no way for a user to gain more privileges to > potentially read/write a bucket they don’t get access to through polaris, > by going directly to the STS. If anything if a user going directly to the > STS they’d get MORE permissions, which is totally fine and completely > reasonable. > > > > You probably have thought of that scenario already so you may have some > contingency system in place or maybe it's not a actual issue in your > deployment situation? > > We heavily audit what the users are doing. Polaris will log “this user is > requesting credentials for this table”, the STS logs “this user is > requesting credentials for this bucket” and our on-prem S3 logs “this user > did <thing> to this bucket.” There is no concern from us over someone > potentially skirting privileges. > > > > One idea I had to prevent user to bypass Polaris authorization system > would be for Polaris itself to issue its own JWT tokens, and when accessing > storage, Polaris would do an internal exchange where claims from the > inbound token (received by Polaris) would be copied over to the outbound > token (sent to STS), after proper validation of course. Is it a scenario > you have considered by any chance? > > From what I gather, Polaris has no intentions on being in the business of > issuing JWT tokens [1]. Again, for our on-prem S3 system, we have no issue > with users going around Polaris to access the STS and S3, this is by > design. There is no guarantee that this feature will work for AWS/Minio > [2], it will enable Polaris to support on-prem S3 use cases like [3], > making it more widely available for everyone. > > [1] https://github.com/apache/polaris/pull/3170#issuecomment-3606973902 > [2] https://github.com/apache/polaris/pull/3170#issuecomment-3608346092 > [3] https://github.com/apache/polaris/issues/3038 > > Thank you for your feedback and please let me know if there’s any more > questions! > > Thanks, > R.J. >
