Hi Yufei, Our deployment follows the pattern where federation between catalogs uses a service principal.
One point I would like to clarify is around the scope of the vended credentials. Based on my testing (and the decoded inline session policies I posted earlier), the credentials appear to be scoped to the requested operation. for example, read operations receive read-only S3 permissions. Please let me know if I am misunderstanding that behavior. The main challenge for us is organizational security boundaries. If the parent catalog is responsible for minting credentials, it needs AssumeRole access to every BU-managed storage account. In our environment, that's not feasible because each BU owns and governs its own storage, IAM roles, and trust policies. Our model is that the parent catalog is the single authentication/RBAC enforcement point, while the child catalogs own the storage integration and credential vending. It is somewhat analogous to how Snowflake provides a single authorization layer for users while accessing external or linked resources using service identities behind the scenes. The user interacts with a single control plane, while the backend connections use a different identity. I completely agree that trusted end user identity propagation to child catalogs would be the ideal long term solution for supporting credential pass-through securely. On Tue, Jun 30, 2026 at 2:12 PM Yufei Gu <[email protected]> wrote: > Hi Rajesh, > > Copied my response from the Github discussion. I think the key question is > what the trust boundary is in a federated deployment. > > Today, Polaris intentionally does not pass through vended credentials from > a federated catalog. Instead, the central catalog re-issues credentials. > This avoids relying on authorization decisions made by another catalog, > which may have a different view of identities, roles, or permissions. > > Even if both catalogs recognize the same principal, they may not enforce > the same authorization policy. For example, a user could have read only > access in the central catalog but read and write access in the federated > catalog. Passing through the remote catalog's credentials would effectively > bypass the authorization decision made by the central catalog. > > Another common deployment pattern is that federation between catalogs uses > a service principal. In that case, blindly forwarding credentials minted by > the remote catalog could unintentionally expose privileges associated with > that service principal. > > For your deployment, where the central catalog is the single authorization > point, I think it makes more sense for the central catalog to own > credential vending as well. Configuring the storage configuration on the > central catalog for federated catalogs keeps both authorization and > credential issuance in one place and avoids the complexity and security > concerns around credential passthrough. > > If we ever wanted to support credential passthrough, I think it would > require more than simply forwarding credentials. We would first need a > trusted identity propagation mechanism so the remote catalog can authorize > the original user rather than a service principal. We'd also need clear > guarantees that both catalogs enforce compatible authorization semantics. > Without those guarantees, passthrough could easily lead to privilege > escalation. > > > Yufei > > > On Tue, Jun 30, 2026 at 9:42 AM 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
