Congrats folks!
Rulin
Hi folks,
I'd like to initiate a discussion on the expected behavior when updating
catalog properties, specifically around the handling of storage
configuration fields that are automatically provided by the Polaris service.
*Background*
When a catalog is created, certain storage configuration pro
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
ng plain key/secret
> credentials?
>
> When STS is in use, where is Polaris expected to get credentials for STS
> requests?
>
> Thanks,
> Dmitri.
>
> On Thu, May 1, 2025 at 5:37 PM Rulin Xing wrote:
>
> > Hi folks,
> >
> > Just wanted to surface a new
is bigger than just naming, I think).
>
> I do not question that the STS / assume role path offers better security
> guarantees. My point is that it may still be valuable for OSS users to have
> simpler connection options.
>
> Thanks,
> Dmitri.
>
> On Thu, May 1, 2025
+1 (non-binding)
Best,
Rulin
Hi folks,
As Polaris expands its support for external services, such as federated
catalogs and cloud storage, it needs to securely access systems like AWS
S3, AWS Glue, Azure Storage, and others. This external access requires
Polaris to handle credentials correctly, whether they’re long-lived
cred
Hi folks,
I just opened a PR to add I*nitial SigV4 Auth Support for Catalog
Federation* in Polaris.
This is part of the work to support credential management for external
service access using a clean and pluggable design. It's based on the
proposal I posted before Apache Polaris Creds Management
