adnanhemani commented on PR #3170:
URL: https://github.com/apache/polaris/pull/3170#issuecomment-3609340565

   > Propagating the user's access token to AWS STS using 
AssumeRoleWithWebIdentity is the standard pattern recommended by AWS itself for 
federated OIDC access.
   
   This is only the standard pattern recommended by AWS for federated OIDC 
access - _if you do not have a governance system in between_. If you feel 
that's wrong, please feel free to drop links to the AWS documentation here that 
support your claim.
   
   > Are you serious about allowing clients to talk to STS directly? THAT, 
indeed, would be a giant security loophole.
   
   (Also mentioned in Laurent's email to the Dev ML regarding this approach) 
Isn't this possible today with how the code is written? If it isn't, what stops 
it? Is it a network policy? And as a result, are we betting the whole of 
Polaris' security posture on such a network policy? Is that truly wise?
   
   Let's compare this to the `AssumeRole` path we have today. In our best 
practices, are IAM roles allowed to be assumed by the clients directly? That is 
clearly not the model that Polaris has today - so why are we breaking that 
security model for this feature?
   
   > Nonetheless, I do not see why Polaris as an OSS project should not open 
this use case for deployments what may benefit from it. The feature is well 
isolated under a catalog property, there is no impact to other use cases.
   
   Not sure I agree, we are enabling a use case here that does not align with 
our current security best practices. And to be clear, this is not as a result 
of there not being a better way of doing this, but rather because this is the 
fastest way of achieving this goal. Trampling security best practices for 
velocity is not something that we have a track record of within this project.
   
   I agree that this use case is a valid one - and that we should be supporting 
it. But I highly disagree in the way that this implementation does so. Rather 
than bending the security model that we have today (which generally can be 
stated like: Polaris user who is unprivileged with regards to storage 
credentials, authenticates and authorizes with Polaris in order to gain storage 
credentials) to fit this use case, we should be tailoring the implementation of 
this use case to fit the security model.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to