Hi everyone, To add one more perspective here, this is not only a security concern but also a major usability and mental-model concern for Polaris users. Here is an example:
- Alice has read + write privileges at the STS/storage layer. - In Polaris, Alice is intentionally granted read-only access to a table. Under the proposed model, because the user JWT is forwarded directly to STS, Alice can simply bypass Polaris and call STS directly. STS then (correctly, from its own viewpoint) grants her write permission, since it has no awareness of Polaris’ table-level authorization. This results in *privilege escalation: *Polaris says “read-only,” but Alice can still perform writes by going around Polaris. Beyond the security implications, this is extremely confusing for admins and users. Polaris presents one authoritative access decision, but the underlying storage enforces another. Users cannot reasonably be expected to understand why they can “write when Polaris says they can’t,”, and why audit logs and enforcement don’t align. *A possible path forward:* one direction we can take, which keeps your use case viable while also preserving Polaris’ governance guarantees, is to introduce an OPA-style authorization module: - Polaris can delegate authZ decisions to a remote system (e.g., OPA, your existing STS-side policy engine, etc). - Credential vending still occurs in Polaris, but only after the delegated AuthZ result has been evaluated. This approach allows deployments like yours to centralize their existing rules in the external system, while also ensuring: - No privilege escalation occurs by bypassing Polaris - Credential vending always honors Polaris’ (or delegated) AuthZ decision - We avoid creating two conflicting interpretations of the same user’s permissions This feels like a direction that could satisfy both RJ’s on-prem scenario and the broader community’s expectations around governance semantics. Happy to continue iterating on how such a module would be wired in, but conceptually it gives us a clean separation: AuthZ may be delegated, but enforcement remains consistent and predictable through Polaris. Yufei On Fri, Dec 5, 2025 at 9:18 AM Dmitri Bourlatchkov <[email protected]> wrote: > Hi All, > > I guess my comment in GH regarding Polaris-owned tokens was not precise > enough. Apologies for the confusion and I'll try to clarify below. > > As far as I understand, in RJ's use case, Polaris is actually expected to > pass the user's auth token from Polaris API to STS. Arguably, it is a very > specific use case and may be applicable only to some very specific on-prem > environments (please correct me if I misinterpret that), but I believe it > is fine to support. > > In that use case Polaris acts as a Resource server from the OAuth2 > perspective and no extra auth tokens are necessary. > > Outside of RJ's use case (and PR), I do not really object to supporting > OAuth2 token exchange in Polaris. It could be a valuable feature, but from > my POV it is a totally separate feature (not related to [3170]) > > [3170] https://github.com/apache/polaris/pull/3170 > > Cheers, > Dmitri. > > On Thu, Dec 4, 2025 at 2:22 PM 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. > > >
