Hi Rajesh, Your federation use case makes sense to me.
Do BU catalogs need to take the end user's identity into account when making decisions about the access scope of vended credentials? If yes, this will probably require the central catalog to propagate the user's identity to the BU catalog on all API calls. This current does not happen. BU catalogs are accessed by the central catalog under a "service account". All of this looks doable to me. Do you have the capacity to contribute this feature? Thanks, Dmitri. On Tue, Jun 30, 2026 at 2:07 PM Rajesh Bulleddula < [email protected]> wrote: > Regarding vended credential pass-through ... > > In our environment, each Business Unit (BU) owns and manages its own object > storage. That includes: > > - > > Its own S3 buckets/prefixes > - > > The IAM roles used for credential vending > - > > Trust policies > - > > Storage access policies and governance > > Accordingly, each BU Polaris catalog has permission to assume only its own > storage access role and can mint appropriately scoped vended credentials > for its own data. > > From our perspective, the central enterprise catalog is responsible for > providing a unified discovery and access endpoint. Clients interact only > with the central catalog, which performs authentication and RBAC before > forwarding requests to the appropriate child BU catalog. > > In this model, the central catalog doesn't need direct access to every BU's > object storage. Instead, the child BU catalog which already owns the > storage integration, returns both the Iceberg metadata and vended > credentials scoped to the operation (read/write). > > If the central catalog is required to mint credentials itself, it would > need permission to assume roles for every BU's storage. In large > organizations, this significantly broadens the trust boundary. Many > organizations have security controls and organizational policies that > discourage or prohibit granting a central service principal cross-account > assume-role access into every BU-managed storage account. > > From our perspective, credential pass-through preserves clear ownership > boundaries: > > - > > The central catalog remains responsible for authentication, > authorization, and request routing. > - > > Each BU child catalog remains responsible for storage authorization and > credential vending for the storage it owns. > > The motivation is primarily around security boundaries and operational > ownership. This aligns well with our intended federation model, where each > child BU catalog is the authority for its own storage while the central > catalog provides a single entry point for consumers. > > > On Tue, Jun 30, 2026 at 12:42 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Rajesh, > > > > The current situation regarding vended credentials in federated catalogs > > has been explained in the linked GG discussion, I believe :) > > > > Re: future direction, you're part of the community too :) > > > > I wonder whether vended credential pass-through is something that is > > beneficial to your use cases... just trying to understand the situation > > better. > > > > Why would you want the "BU" catalog to control credential vending? > > > > Thanks, > > Dmitri, > > > > On Tue, Jun 30, 2026 at 11:37 AM Rajesh Bulleddula < > > [email protected]> wrote: > > > > > Following the discussion on GitHub, starting a dev thread on > credential > > > vending behavior in Apache Polaris catalog federation. > > > > > > https://github.com/apache/polaris/discussions/4929 > > > > > > I am evaluating catalog federation behavior in a data lakehouse setup > > using > > > Apache Iceberg with Apache Polaris. > > > > > > Architecture: > > > > > > - One central enterprise catalog > > > - Multiple BU (Business Unit) level child catalogs federated into > the > > > central catalog > > > > > > Expected flow (based on my understanding): > > > > > > - Client queries an Iceberg table through the central catalog > > > - Central catalog forwards the request to the appropriate BU catalog > > > after RBAC validation > > > - BU catalog returns table metadata and vended credentials > > > - Central catalog returns the BU catalog’s metadata and the same > > vended > > > credentials back to the client > > > > > > Actual behavior observed: > > > > > > - BU catalog does return metadata + vended credentials > > > - Central catalog drops/ignores the BU-provided vended credentials > > > - Central catalog generates new vended credentials and sends that to > > the > > > client instead > > > > > > Question: > > > > > > What is the intended credential vending model for catalog federation? > > > > > > - Should the central catalog propagate the vended credentials returned > by > > > the child catalog to the client (credential pass-through)? > > > > > > Or > > > > > > - Should the central catalog always generate and return its own vended > > > credentials, regardless of whether the child catalog has already vended > > > credentials? > > > > > > I'm interested in understanding the intended design philosophy for > > > federation and whether supporting vended credential pass-through is > > > something the community believes should be part of Polaris. > > > > > > -- > > > Thanks & Regards, > > > Rajesh Bulleddula > > > > > > > > -- > Thanks & Regards, > Rajesh Bulleddula >
