+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 > > >
