Hi All, PR [5884] seems to be in a good shape. As far as I can tell, all existing points have been addressed.
If there are no objections, I propose merging it on Oct 30. Thanks, Dmitri. [5884] https://github.com/apache/polaris/pull/5884 On Tue, Oct 27, 2026 at 5:46 PM Dmitri Bourlatchkov < [email protected]> wrote: > Hi JB, Ayush, > > Good points re: DefaultAccessDelegationModeResolver! > > Vignesh contributed PR [5884] to implement the new properties. This PR > adjusts the logic in DefaultAccessDelegationModeResolver too. Kudos to > Vugnesh! > > As far as I can tell, after [5884] if a client requests > "vended-credentials" but the server is configured > with skipCredentialDownscoping = true (for example), then the client will > receive a clear error message indicating that credential vending is not > available. > > This is related to the Iceberg API clarification vote [1]. If that spec > change passes in Iceberg, Polaris will be able to support "none" as a > vending mode for a better client config experience, IMHO. > > In any case, please review [5884]. I think it still makes sense in Polaris > even without the Iceberg spec change. > > In Polaris code the main use case may be in tests, but some users may want > to consider the new options for workload identity-based deployments too. > > [1] https://lists.apache.org/thread/hc2764vozz7ygx5fjj64104hotrof0lk > > [5884] https://github.com/apache/polaris/pull/5884 > > Cheers, > Dmitri. > > On Sun, Oct 25, 2026 at 5:53 AM Jean-Baptiste Onofré <[email protected]> > wrote: > >> Hi all, >> >> +1 on the catalog-level AzureStorageConfigInfo.skipSasTokenGeneration and >> GcpStorageConfigInfo.skipCredentialDownscoping properties. A typed, well >> defined setting is a better home for "don't vend" than the >> SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION flag, which only applies at the >> realm level. It also matches what stsUnavailable already does for S3. >> >> I agree with Ayush on the access delegation mode. >> >> I think it would be great to clarify two points before working on the >> implementation PR: >> - If a catalog opts out of vending and the client asks only for >> vend-credentials, we should reject the request up front with a clear >> error. >> Failing later inside the vending path is harder to diagnose imho. This >> should apply to all three providers, so the S3 stsUnavailable case behaves >> the same way. If changing the S3 behavior is out of the scope for the PR, >> we can track as a follow-up, but we need consistency here imho. >> - Both properties should default to false, so existing catalogs keep >> vending credentials. They should be optional in the Management API, so >> this >> is a backward compatible addition. We should also document them next to >> stsUnavailable (in site/content/in-dev/unreleased/), and say there that >> they are meant for non-cloud or emulator deployments. >> >> Happy to review the PRs ;) >> >> Regards >> JB >> >> On Fri, Oct 23, 2026 at 8:15 PM Dmitri Bourlatchkov <[email protected]> >> wrote: >> >> > Hi All, >> > >> > As discovered during the review of PR 5756 [1], now >> > that SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION is not recommended for >> > mainstream use [3], deployments (e.g. tests) using non-cloud options for >> > ADLS and GS (GCS) storage need a mechanism for opting out of minting >> > session tokens and resolving to local (server and/or client) credentials >> > for storage access. >> > >> > I propose adding the following properties at the Management API level >> [1]. >> > >> > * AzureStorageConfigInfo.skipSasTokenGeneration >> > >> > * GcpStorageConfigInfo.skipCredentialDownscoping >> > >> > Both names relate to the corresponding native APIs in each technology. >> > >> > Setting these properties will effectively disable credential vending. >> This >> > is similar to stsUnavailable in AwsStorageConfigInfo. >> > >> > The main purpose of the new properties is establishing a catalog-level >> opt >> > in/out mechanism and providing well-defined user-level settings. >> > >> > PolarisStorageIntegration implementations still retain value without >> > credential vending because they potentially define non-credential >> > properties in StorageAccessConfig. The latter case currently applies >> only >> > to S3, but downstream customizations may utilize it too. >> > >> > [1] https://github.com/apache/polaris/pull/5756#discussion_r4362688654 >> > >> > [2] >> > >> > >> https://github.com/apache/polaris/blob/5fafc67a832a8900fefb399abc00549d864470d6/spec/polaris-management-service.yml#L21 >> > >> > [3] https://lists.apache.org/thread/1trcnbm04zzqztpxkzrzs1pvrlyd49bg >> > >> > Thoughts? >> > >> > Thanks, >> > Dmitri. >> > >> > > > -- > Dmitri Bourlatchkov > Senior Staff Software Engineer, Dremio > Dremio.com > <https://www.dremio.com/?utm_medium=email&utm_source=signature&utm_term=na&utm_content=email-signature&utm_campaign=email-signature> > / > Follow Us on LinkedIn <https://www.linkedin.com/company/dremio> / Get > Started <https://www.dremio.com/get-started/> > > > The Agentic Lakehouse > The only lakehouse built for agents, managed by agents > > >
