Re: [I] Feature request: explicit “no vended credentials / no SAS” mode for IAM‑only setups (esp. Azure) [polaris]

["tsukubatexas (via GitHub)" <gi...@apache.org>]

tsukubatexas commented on issue #5050:
URL: https://github.com/apache/polaris/issues/5050#issuecomment-5175635667

   +1. I think this is more than a policy preference on Azure.
   
   The SAS Polaris vends today is a bearer token. Polaris knows which principal it issued the token to, but anyone holding the string can use it afterwards.
   
   Azure’s user-bound user delegation SAS is meant to close that gap, but it is still in public preview. It also requires sduoid and a separate Entra token on every storage request. As far as I can tell, Polaris and the current Iceberg ADLS clients do not support this end to end.
   
   Auditing has the same issue. SAS-authenticated storage requests do not carry the caller’s identity. Short TTLs and narrow path scopes reduce exposure, but they do not tell you who used the credential.
   
   For that reason, client-managed storage credentials seem like a valid production mode. The client authenticates directly to ADLS with its own Entra identity.
   
   Polaris is still useful in that setup. Azure RBAC protects files, but it does not provide an Iceberg catalog, commit coordination, or table semantics. Polaris still handles catalog permissions, commits and conflicts, schema and snapshot changes, discovery, and the common REST API. The tradeoff is that direct reads are governed by ADLS rather than Polaris.
   
   I would make this server-enforced rather than dependent on a client header, and configurable per catalog or warehouse. allowSharedKeyAccess=false does not block user delegation SAS, so no-vending must be enforced by the issuer.
   
   The storage logs will identify the identity used by the engine, which may be a workload identity rather than an individual user.


-- 
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: issues-unsubscribe@polaris.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org