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 >
