I also find this confusing. Some combinations, such as (ALLOW_EXTERNAL=true, ALLOW_FEDERATED=false) and (ALLOW_EXTERNAL=false, ALLOW_FEDERATED=true), are hard to reason about and it is not clear what use cases they are meant to support.
I'm supportive of taking a step back, clarifying the intended semantics, and potentially consolidating the flags if there is no strong reason to keep them separate. Yufei On Fri, Feb 6, 2026 at 12:09 PM Michael Collado <[email protected]> wrote: > The intent for external catalogs was to expose tables that are managed by > external systems (e.g., AWS Glue or Snowflake-managed Iceberg), but still > allow Polaris to enforce the RBAC. A Polaris admin can create a catalog, > configure the right AWS IAM role, S3 bucket, etc. and expose the > externally-managed Iceberg table to a user without having to expose raw S3 > credentials to that end-user. The end user accesses the table just like any > other Iceberg table through the Polaris APIs, including the credential > vending. > > There were some concerns way early on that always allowing credential > vending for these externally managed systems could potentially allow > someone to circumvent the table-overlapping checks, thus get credentials > that were overly broad, so the ALLOW_EXTERNAL_CATALOG_CREDENTIAL_VENDING > configuration flag was added. Since that controls the feature for the > entire realm, the catalog flag polaris.config.enable.credential.vending was > added so that admin could individually enable the feature for specific > catalogs while not enabling it for the entire realm. > > TBH, I'm not sure about the ALLOW_FEDERATED_CATALOGS_CREDENTIAL_VENDING > flag, but I imagine it's the same. In terms of consolidating, it seems ok > to me, but I'd let Dennis comment on the feasibility of that. > > Mike > > On Fri, Feb 6, 2026 at 11:12 AM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi All, > > > > I have a tangential question: Is it even possible to configure Apache > > Polaris to perform credential vending for Federated or External catalogs > in > > a realistic deployment (i.e. not in-memory)? > > > > I do not mean it as a tricky question :) just trying to understand the > > scope of this problem... So if anyone has answers / pointers, please > share. > > > > For example, for remote Iceberg REST Catalogs I was only able to find > this > > provider of connection credentials: UnsafeInMemorySecretsManager... > perhaps > > I missed something. > > > > Thanks, > > Dmitri. > > > > On Thu, Feb 5, 2026 at 11:21 AM Alexandre Dutra <[email protected]> > wrote: > > > > > Hi all, > > > > > > I noticed today that we have two very similar feature flags: > > > > > > - ALLOW_FEDERATED_CATALOGS_CREDENTIAL_VENDING > > > - ALLOW_EXTERNAL_CATALOG_CREDENTIAL_VENDING > > > > > > Each flag is only used in one location each: [1] [2]. > > > > > > Additionally, the second feature flag uses an ambiguous catalog > > > property name: "polaris.config.enable.credential.vending". It > > > misleadingly suggests it works for internal catalogs as well. > > > > > > I therefore propose two improvements: > > > > > > 1) Would it be acceptable to merge these two seemingly redundant > > > feature flags? Or could someone explain why we need both? > > > > > > 2) If not, should we rename the above property to e.g. > > > "polaris.config.allow-external-catalogs-credential-vending" for > > > greater clarity (and deprecate the old one)? > > > > > > Thanks, > > > Alex > > > > > > [1]: > > > > > > https://github.com/apache/polaris/blob/a2418c8711dca10a22ebfaef20a3b5cec2057fa5/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogHandler.java#L1305-L1317 > > > > > > [2]: > > > > > > https://github.com/apache/polaris/blob/a2418c8711dca10a22ebfaef20a3b5cec2057fa5/runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/IcebergCatalogHandler.java#L854 > > > > > >
