Hi Jiajia,

Forward one of my discussion thread,
https://lists.apache.org/thread/jgwhzmvvdfr1mc7nfdrtp7btrmt9wdqx. In
general, forwarding the remote's storage credentials breaks the Polaris
security model. We should avoid that if possible.

Best,
Yufei

On Tue, Aug 18, 2026 at 11:51 PM Jiajia Li <[email protected]>
wrote:

>  Hi all,
>  Raising this from PR #5309, at @vigneshio's suggestion. The PR also
> changes the management API — roleArn is no longer required on
> SigV4AuthenticationParameters, plus new accessKeyId and secretAccessKey
> fields — so comments on that are welcome too.
>  A federated catalog mints storage credentials from its own
> storageConfigInfo. When the remote catalog owns the storage there is no
> local configuration describing it, and every route fails: vending is
> refused, or validateTableLocations rejects the remote's locations, or
> allowedLocations is rejected at create time over the
>  URI scheme. The client can't work around it either when the remote only
> honours credentials it issued.
>  I have an opt-in per-catalog flag that forwards the remote's credentials
> instead, read off the loaded table's FileIO via SupportsStorageCredentials.
> It refuses principals not authorized for write delegation, since forwarded
> credentials are scoped to the identity Polaris federates with and can't be
> narrowed to the caller.
>  Verified end to end: a stock Iceberg client with no storage credentials
> of its own read a table through Polaris.
>  The question is the trust model. On this path Polaris stops being the
> location policy point — validateTableLocations is skipped, because it
> compares against storage this deployment configured rather than what's
> being handed out. As @vigneshio put it, "the remote scoped the creds" is
> only as strong as our trust in that
>  remote. Per-catalog opt-in is the best answer I have; if there's a
> meaningful location check to keep here, I'd rather have it.
>  If the list would rather Polaris not take this on, that's a useful answer
> too — the alternative is engines talking to these catalogs directly and
> skipping federation.
>  Thanks,
>  Jiajia
>  Thanks,
>  Jiajia
>

Reply via email to