Apologies for the late reply. Thanks Dmitri for raising this, and Vignesh for working onit. As Ayush and JB mentioned, we could use the header to achieve the same result. Do we want to introduce another spec change, or am I missing some use cases?
Yufei On Thu, Oct 29, 2026 at 2:05 PM Dmitri Bourlatchkov <[email protected]> wrote: > 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 > > > > > > >
