Yeah excellent point, and that definitely highlights the need for a more
comprehensive design for non-AWS S3-compat storage.
Using the removal of roleArn as an "incidental" fix for a fuzzy subset of
scenarios is probably not how we want to get entrenched for the first
introduction of those features, especially when we didn't even make it
clear in the github issue or the committed code how we expect optional
roleArn to interact with session-token exchange.
IMO the ability to "assumeRole(null /* roleArn */, sessionPolicy)" should
itself be treated as idiosyncratic to specific storage providers and paired
with some explicit expression of intent both for Polaris internally as well
as for the user.
>From what I can tell, "null assumeRole" in MinIO is more analogous to
"getSessionPolicy" from AWS, though I'm not too familiar with MinIO so we
should invite some expert opinions on this.
Right now there are several different concerns rolled up into the single
"getSubscopedCredential" in Polaris:
A. Indirection between root "service identities" (owned by the Polaris
service owner) and per-Catalog storage-actor identities (owned by the
Catalog administrative user)
-This indirection *in itself* is an important element of the Polaris
security model, where service identities do *not* generally have latent
direct storage-access permissions, but instead hold "actAs" or "assumeRole"
types of permissions
B. Applying a "subscoping policy" that restricts the blast radius of any
storage credentials that may be used, both in terms of "path prefix" and in
"duration"
-It's intentional to make Polaris "internal" FileIO go through the same
subscoping flow as much as possible, so that even when it's Polaris
writing/reading metadata files, the blast radius matches what would be
vended out to a sufficiently privileged principal
C. Applying "configuration overrides" related to endpoints, region, etc.
These crept into getSubscopedCredentials due to being "convenient", but are
substantially a different action than credential-minting, though are
closely related because of needing to determine STS endpoints from the
config
I guess we probably want to refactor so that (C) will *always* happen
correctly, so we'd need to split out some kind of "getDynamicConfig" that
is separate from injecting the *credentials* into the config map.
It sounds like we have potential use cases for any mix of (A) and (B).
- Single-tenant use cases may not need "indirection" but may still want
subscoping both for internal blast-radius management and for
credential-vending
- Other single-tenant use cases might be okay with neither
identity-indirection nor subscoping
- I think we've had some discussion about whether to ever allow
credential-vending without subscoping (i.e. vending long-lived credentials)
On Thu, Aug 21, 2025 at 3:53 AM Alexandre Dutra <adu...@apache.org> wrote:
> Hi,
>
> We just had an issue created by a user that was attempting to do use
> case #2 in Dennis' categorization ("Using DefaultCredentialsProvider
> directly without subscoping to access non-AWS s3-compat storage"):
>
> https://github.com/apache/polaris/issues/2398
>
> This uncovered some interesting findings (at least for me), which
> leads me to think that setting
> SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION=true is actually not enough,
> and even not recommended in that case. When credentials subscoping is
> disabled, the table config returned to the client not only omits S3
> credentials, which is expected, but also omits some otherwise very
> important S3 settings, such as: s3.endpoint, s3.path-style-access or
> client.region, *even if these were properly configured at the catalog
> level*. As a result, the client is unable to access the MinIO storage
> properly.
>
> For me, use case #2 is just not achievable right now in Polaris.
> Enabling credentials subscoping solves the issue of course, but also
> creates a somewhat artificial link between credentials vending and
> "generic" storage configuration.
>
> Thanks,
> Alex
>
> On Thu, Aug 21, 2025 at 6:18 AM Dennis Huo <huoi...@gmail.com> wrote:
> >
> > Reposting my comment from the github issue here for further discussion:
> >
> > It seems like there are three distinct "new" use cases:
> >
> > 1. Using DefaultCredentialsProvider directly without subscoping to access
> > storage when running on AWS and using AWS S3
> > 2. Using DefaultCredentialsProvider directly without subscoping to access
> > non-AWS s3-compat storage
> > 3. Using DefaultCredentialsProvider directly with subscoping to access
> > non-AWS s3-compat storage
> >
> >
> > These are all different from the "normal" flow:
> >
> > 4. Using DefaultCredentialsProvider as the super-root to assumeRole on a
> > provided role with subscoping to access storage on S3
> >
> > For (1) and (2), setting SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION=true is
> > explicitly intended for that use case, though looking at the code it
> seems
> > we still need to remove "validate" checks for roleARN, otherwise
> > parsing-validation fails at createCatalog time.
> >
> > We should verify that a "dummy" syntactically valid roleArn such as
> > "arn:aws:iam::123456789012:role/my-role" already works for the stated use
> > case even without https://github.com/apache/polaris/pull/2329 making
> > roleArn optional if the following is set in application.properties:
> >
> > polaris.features."SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION"=true
> >
> > Looking at MinIO that's certainly very interesting that
> > AssumeRoleWithWebIdentity makes roleArn optional -- it's not 100% clear
> > whether the provide Policy is still applied to the returned token. I'm
> also
> > not 100% clear on how we map the stsClient to point at WebIdentity vs
> > CustomToken flows for MinIO - for example AssumeRoleWithCustomToken still
> > requires roleArn:
> >
> https://docs.min.io/enterprise/aistor-object-store/developers/security-token-service/assumerolewithcustomtoken/
> >
> > But assuming the subscoping does work, then (3) is a substantially new
> flow
> > where the assumeRole indirection is applied, but yet the identity is the
> > service-wide default credentials provider where
> > SKIP_CREDENTIAL_SUBSCOPING_INDIRECTION=false is used despite being no
> > roleArn provided. This new use case would need a separate
> > FeatureConfiguration to avoid multi-tenant deployments from
> "accidentally"
> > exposing the service identity through vended credentials.
> >
> > On Tue, Aug 12, 2025 at 9:43 AM Dmitri Bourlatchkov <di...@apache.org>
> > wrote:
> >
> > > Making roleArn optional in the REST API is backward compatible and
> allows
> > > for better UX with non-AWS S3-compatible storage.
> > >
> > > This change looks good to me.
> > >
> > > Cheers,
> > > Dmitri.
> > >
> > > On Tue, Aug 12, 2025 at 5:46 AM Robert Stupp <sn...@snazy.de> wrote:
> > >
> > > > Hi all,
> > > >
> > > > Description of the PR: Having the role-arn parameter required for a
> > > catalog
> > > > is redundant in many and requires the generation of an extra role in
> > > cases
> > > > when IRSI (for AWS) is being used. Other S3 implementations (Minio,
> Ceph,
> > > > many of the appliances) also do not all require a role-ARN.
> > > >
> > > > See issue [1] and PR [2] to fix the issue.
> > > >
> > > > Robert
> > > >
> > > > [1] https://github.com/apache/polaris/issues/2325
> > > > [2] https://github.com/apache/polaris/pull/2329
> > > >
> > >
>
