Hello Team, Following up on this thread, I haven’t seen any objections or alternative directions, so I’m checking whether silence is okay to treat as rough consensus.
Unless someone prefers a different shape (e.g. STS URL only in connection properties instead of an optional field on SigV4 auth parameters), I plan to proceed with a small PR following the proposed approach shared earlier. If anyone has concerns or a naming preference (e.g. align with catalog S3 stsEndpoint), please feel free to drop your thoughts and it'd help me get started on working on a PR. Thanks, Arnab On Tue, Nov 3, 2026 at 11:38 PM Arnab Karmakar <[email protected]> wrote: > Hello, > > I’m looking at a small gap in connection credential vending for federated > catalogs > that use SigV4 authentication (SigV4ConnectionCredentialVendor). > > Background > ---------- > When Polaris assumes a customer IAM role via STS for a catalog connection, > we > build the STS client with StsDestination.of(null, signingRegion) which is > region only, no > custom STS endpoint. Catalog storage credential vending already respects > stsEndpoint on AwsStorageConfigurationInfo. > > There is an in-code TODO in SigV4ConnectionCredentialVendor.getStsClient() > to > configure StsDestination from connection auth parameters. That matters for > non-AWS STS endpoints (e.g. MinIO/local testing) and deployments where STS > is > not the public AWS endpoint. > > I did not find an existing GitHub issue specifically for this; related > threads > ([4711] / [5869]) cover service-identity reuse on EKS, not connection STS > URL. > > Proposal (for discussion) > ------------------------- > 1. Add an optional STS endpoint URI to SigV4 connection authentication > parameters (management API + SigV4AuthenticationParametersDpo), > mirroring > the storage config stsEndpoint idea where reasonable. > 2. In SigV4ConnectionCredentialVendor, call > StsClientProvider.stsClient(StsDestination.of(stsEndpointUri, > signingRegion)) > with null endpoint meaning “SDK default” (same as today). > 3. Unit tests in SigV4ConnectionCredentialVendorTest (extend the existing > StsDestination capture tests). > > Questions > --------- > 1. Is an optional stsEndpoint (or equivalent name) on SigV4 connection auth > the right shape, or should it live in connection properties instead? > 2. Any objection to aligning naming/semantics with catalog S3 stsEndpoint? > 3. Worth a PR once we agree, or defer until someone hits this in > production? > > Thanks, > Arnab > > [4711] https://github.com/apache/polaris/issues/4711 > [5869] https://github.com/apache/polaris/pull/5869 >
