Hi I agree with Michael.
I think we can “easily” do a fist step on that by implementing an authorizer loading from /Quarkus config source for instance. Regards JB Le mer. 24 sept. 2025 à 15:39, Michael Collado <[email protected]> a écrit : > My guess is that people who want a declarative privilege mapping want the > configuration file to be the source of truth, rather than something that > feeds a script at startup. I do think such a script is useful for > bootstrapping, but as organizations change, the application of the policy > needs to change with it. > > It would be interesting to experiment with custom PolarisAuthorizers to > try and implement different policy-engines as plugins. I expect the API > will need some updating, but would imagine a major overhaul is necessary. > > Mike > > > On Sep 23, 2025, at 5:08 PM, Yufei Gu <[email protected]> wrote: > > > > Hi Graeme, > > > > Could you share a bit more about your use case? We’ve been discussing > > pre‑setting catalog roles, grants, namespaces, policies whenever a new > > catalog is created. Does that match what you’re trying to do? > > > > If so, a quick approach is to run a script that executes the required > steps > > via the Polaris CLI in sequence. > > > > Long term, we could allow a template for catalog creation. > > > > > > Yufei > > > > > >> On Tue, Sep 23, 2025 at 9:16 AM Jean-Baptiste Onofré <[email protected]> > >> wrote: > >> > >> For context, I implemented something that looks like that (if I > >> understood correctly) in Apache ActiveMQ: > >> > >> <authorizationPlugin> > >> <map> > >> <authorizationMap> > >> <authorizationEntries> > >> <authorizationEntry queue="TEST.Q" read="users" > >> write="users" admin="users" /> > >> <authorizationEntry topic="ActiveMQ.Advisory.>" read="*" > >> write="*" admin="*"/> > >> </authorizationEntries> > >> <tempDestinationAuthorizationEntry> > >> <tempDestinationAuthorizationEntry read="admin" > >> write="admin" admin="admin"/> > >> </tempDestinationAuthorizationEntry> > >> </authorizationMap> > >> </map> > >> </authorizationPlugin> > >> > >> see > https://activemq.apache.org/components/classic/documentation/security > >> > >> So, here, you have the permission (read, write, admin) mapped to roles > >> (admin, users, everyone e.g. *). > >> > >> In Polaris, instead of queue/topic, it would be entities, and we can > >> do the same sort of "mapping". > >> > >> Just my $0.01 > >> > >> Regards > >> JB > >> > >>> On Tue, Sep 23, 2025 at 5:06 PM Jean-Baptiste Onofré <[email protected]> > >>> wrote: > >>> > >>> Hi Graeme > >>> > >>> So, you proposal is to declare the roles mapping to action in a > >>> configuration file. Something like this (pseudo config): > >>> > >>> Entity FOO > >>> Role1: read > >>> Role2: write > >>> > >>> Entity BAR > >>> Role1: admin > >>> Role3: write > >>> > >>> So, the roles are still coming possibly from "external" providers, but > >>> the "mapping" role/permission would be declarative. Is it what you > >>> mean ? > >>> > >>> Regards > >>> JB > >>> > >>> On Tue, Sep 23, 2025 at 4:29 PM Graeme Hendrickson > >>> <[email protected]> wrote: > >>>> > >>>> Hi folks, > >>>> > >>>> One of the things that’s been a little painful for us operating > >> Polaris is configuring new catalogs or ensuring that a catalog has the > >> roles and grants configured that we expect. Has there been any interest > or > >> thought put into an idempotent “apply” action for principal roles, > catalog > >> roles, and privilege grants based on some sort of configuration file? If > >> not, is that something that’s interesting to this group? > >>>> > >>>> Cheers, > >>>> Graeme > >> >
