I may not be as categorical as Adnan about this being not broadly acceptable (because security is a relative concept, hence why context is important), but a major reason behind the development of credential vending in IRC is for lakehouse administrator to make the catalog the governance layer in terms of data access/permissions, and not to have to duplicate the governance effort at the object storage as well. Your design seems to make the STS layer the main access control layer instead, but you didn't say if you were planning to leverage Polaris access control layer (or if everybody has full access to the catalog, and ultimately final access check is done when trying to access the data).
That said, it doesn't seem there's anything special about the token and the way Polaris processes it for credentials vending, so why leveraging credential vending vs having the iceberg rest client calling directly STS instead? (same question as Adnan) > 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. It may seem over engineered now because it's not a widely adopted pattern, but I can see things are evolving: you can see many systems introducing workload identity federation or OIDC/JWT token exchange capabilities these days, I just noticed that AWS has introduced a new `GetWebIdentityToken` API to generate a JWT token out of IAM credentials, and at work we have been working on something similar to introduce zero-trust/credential less access to remote systems. So I hope I can convince the community to adopt such a pattern at some point... On Fri, Dec 5, 2025 at 1:01 AM Adnan Hemani via dev <[email protected]> wrote: > 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. > > >
