Hi Rajesh, A code PR is not required up front. In many cases it is best to discuss the design first and then make code changes.
You may want to start with an issue plus an outline of proposed changes and a summary of your rationale for them (which is partly discussed in this thread). Some people put that in google docs and share links. Alternatively, you can just post a "[PROPOSAL] ..." email thread to the dev ML. Another option is to put the proposal in .md files [1] similar to [4010]. I do not think there is a strong requirement for where to place the text. >From my personal POV, email or .md files in a PR work best [1], but please feel free to use any method that is convenient for you. We have a Community Sync meeting on July 23 [2]. If you wish, you're welcome to join and add an agenda item for your proposal. [1] https://lists.apache.org/thread/yto2wp982t43h1mqjwnslswhws5z47cy [2] https://polaris.apache.org/community/meetings/ [4010] https://github.com/apache/polaris/pull/4010 Cheers, Dmitri. On Mon, Jul 20, 2026 at 11:17 PM Rajesh Bulleddula < [email protected]> wrote: > Nevermind, found the guidelines. > > https://github.com/apache/polaris/blob/main/CONTRIBUTING.md > > Will create an enhancement issue first. > > On Mon, Jul 20, 2026 at 11:08 PM Rajesh Bulleddula < > [email protected]> wrote: > > > Hi Dmitri, > > > > Thank you! For the next steps, should I first create an enhancement issue > > and then submit a PR for the dev community to review? Additionally, are > > there any specific guidelines I should be aware of before I begin the POC > > implementation? > > > > Regards, > > Rajesh Bulleddula > > > > > > On Thu, Jul 9, 2026 at 10:14 PM Dmitri Bourlatchkov <[email protected]> > > wrote: > > > >> Hi Rajesh, > >> > >> Thanks for the use case description. I think it is quite reasonable. > >> > >> I suppose the next step would be to develop a POC implementation for a > >> more > >> concrete review and to assess the impact on other use cases. Ideally, I > >> think, the new feature should probably be under a config flag, enabled > by > >> the Polaris admin only when explicitly intended. > >> > >> Looking forward to your contribution :) > >> > >> Cheers, > >> Dmitri. > >> > >> On Wed, Jul 1, 2026 at 3:36 PM Rajesh Bulleddula < > >> [email protected]> wrote: > >> > >> > Hi Dmitri, > >> > > >> > Ideally, yes, we would want the child BU catalog to take the end > user's > >> > identity into account when determining the scope of the vended > >> credentials. > >> > Also, identity propagation would address the concern Yufei raised > >> earlier > >> > about unintentionally exposing the privileges associated with the > >> > federation service account. But as you said, that would require the > >> > central catalog to propagate the authenticated user's identity to the > >> child > >> > BU catalog on federated API calls which doesn't happen today. > >> > > >> > That said, I don't think identity propagation is a prerequisite for > >> > credential pass-through, atleast for our usecases. > >> > > >> > Even with the current model, where the central catalog communicates > with > >> > the child catalog using a service account: > >> > > >> > > >> > - The parent catalog remains responsible for authenticating the > user > >> and > >> > enforcing RBAC. > >> > - Once authorized, the child catalog can mint vended credentials > for > >> its > >> > own storage scoped to user operation and return them to the parent > >> > and back to > >> > client. > >> > > >> > This still preserves the desired ownership boundary, where each child > BU > >> > catalog remains the authority for credential vending over the storage > it > >> > owns, without requiring the central catalog to have AssumeRole > >> permissions > >> > into every BU-managed storage account. > >> > > >> > About contributing to the feature, I will let you know in a couple > days. > >> > > >> > On Tue, Jun 30, 2026 at 3:30 PM Dmitri Bourlatchkov <[email protected] > > > >> > wrote: > >> > > >> > > 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 > >> > > > > >> > > > >> > > >> > > >> > -- > >> > Thanks & Regards, > >> > Rajesh Bulleddula > >> > > >> > > > > > > -- > > Thanks & Regards, > > Rajesh Bulleddula > > 281-853-4723 > > > > > -- > Thanks & Regards, > Rajesh Bulleddula > 281-853-4723 >
