Hi folks,
Just wanted to surface a new API spec update proposal related to Catalog
Federation:
https://github.com/apache/polaris/pull/1506
This adds support for AWS SigV4 authentication, enabling Polaris to
federate to external Iceberg REST catalogs hosted behind services like AWS
Glue, S3Tables
Hi Dmitri,
Thanks for the thoughtful questions!
1. Does this assume the use of STS?
Yes, the current spec changes assume the use of STS. Polaris acts as a service
provider and assumes IAM roles provided by users to access AWS resources like
Glue Catalogs. This model avoids long-lived credentia
> Maybe our approaches are just different. As for me, making backend changes
first, adding API later is more "natural" :)
I definitely have the opposite approach. I’m very used to defining the
contract first, before a working backend implementation is complete, as
that usually allows dependent tea
But even in the original code, there is a test asserting that federated
principals can't be created.
Yeah, I saw that, but this was actually the thing that felt awkward to me
in the PR.
I'd prefer to avoid making API changes that do not have an execution option
in runtime (i.e. not possible to c
Hi Rulin,
Thanks for the informative description in the PR!
It looks like the authentication method relies on STS. As such it is a
sub-case of SigV4, I believe, because SigV4 can be used with plain
key/secret credentials without assuming a role.
If that is so, could you clarify that in the descr
Hello all,
Following up from today's community sync where we were discussing 1.0
blockers, I just wanted to finalize discussion on
https://github.com/apache/polaris/issues/761 to check if everyone's aligned
on the current state of things.
My understanding is that the originally reported issues re
