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
