Hi Dmitri, +1, and the catalog-level granularity is worth having — the existing flag is realm-only.
One thing to settle first. If I am reading it right, these properties would naturally land in DefaultAccessDelegationModeResolver.isCredentialVendingAvailable, which today checks stsUnavailable for AWS and returns true for everything else. When that returns false and the client requests both modes, the resolver degrades to REMOTE_SIGNING, which then fails fast at loadTable because remote signing is not implemented — the same path S3 takes with stsUnavailable. That already pushes clients toward "omit the header, use local credentials". Worth confirming that is the intended outcome for ADLS/GS too, and also what happens when only vended-credentials is requested: that path returns the mode without consulting isCredentialVendingAvailable at all, so it fails later in vending, whereas the external-catalog flags throw up front. -Ayush On Fri, 23 Oct 2026 at 23:46, 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.
