Thanks for chiming in, Dmitri and Dennis. Here is the PR to address it: https://github.com/apache/polaris/pull/4284.
Yufei On Thu, Apr 23, 2026 at 2:13 PM Dennis Huo <[email protected]> wrote: > +1, the `stsUnavailable` came later as a more general/cleaner expression of > the behavior, so I agree with updating the docs to steer away from the old > flag. > > On Wed, Apr 22, 2026 at 7:52 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > +1 to all three action items. > > > > I quite agree that the SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION flag is > > probably not very useful for end users. > > > > The stsUnavailable flag is certainly preferable as an alternative > > to SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION for S3 storage. > > > > GCS and Azure do not have similar flags, though, AFAIK, but adding them > > should not be hard if there's user demand. > > > > Cheers, > > Dmitri. > > > > On Wed, Apr 22, 2026 at 6:32 PM Yufei Gu <[email protected]> wrote: > > > > > Hi folks, > > > > > > I'd like to propose narrowing the scope of > > > SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION. When introduced in PR #208 [1], > > the > > > description covered two intended use cases: > > > 1. Integration tests use fake S3 paths (no real STS), which covers > the > > > dominant use case. We use the flag across many of our own integration > > tests > > > (RestCatalogMinIOSpecialIT, ApplicationIntegrationTest, NoSqlCatalogIT, > > and > > > others). > > > 2. Single-tenant server deployments that don't need > credential-vending > > > and rely on server-default environment variables or credential files > for > > > all storage access. This will also likely fall into the use case 1. > > > > > > Case #2 is the source of my concern. It raises two problems: > > > > > > - Weak security posture. The flag returns whatever ambient > credentials > > > the Polaris server has (pod IAM role, env vars) to any client going > > > through > > > it. There's no defense-in-depth: a buggy or compromised client > > inherits > > > the > > > full Polaris pod's permissions. That's only defensible for > > > narrowly-scoped > > > single-tenant setups, and the current doc doesn't convey that > > > narrowness. > > > - User confusion. The flag name reads like "skip all credential > > > vending," which sounds like the right answer for S3-compatible > storage > > > that > > > lacks STS. Pure Storage recently published a public walkthrough for > > > Polaris > > > on FlashBlade [2] that explicitly calls out the pitfall: operators > > reach > > > for this flag, receive an empty configuration, and silently route to > > AWS > > > instead of their intended destination. The correct flag for that > > > case is *stsUnavailable: > > > true* on the catalog's storage config. > > > > > > I'd like to propose we: > > > 1. Update the flag description and site docs to state this is a > > > *test/dev-only* flag, and steer S3-compatible production traffic to > > > stsUnavailable: true. > > > 2. Optionally emit a WARN log on startup if the flag is enabled > > outside a > > > test profile. > > > 3. Leave the runtime behavior unchanged so we don't break anyone > > > currently depending on case #2. > > > > > > Happy to get feedback on it. > > > > > > [1] https://github.com/apache/polaris/pull/208 > > > [2] > > > > > > > > > https://blog.purestorage.com/purely-technical/using-apache-polaris-with-flashblade/ > > > > > > Yufei > > > > > >
