Hi Yufei, The use cases you highlighted seem very reasonable to me. Looking forward to additional information from Michael.
In the end, I believe this can be achieved by granting the admin principal both the catalog_admin role and the "list principals" role individually. In a broader scope, this is a matter of separation of duties. An actor who can grant access to a catalog (catalog_admin) to a particular principal role does not necessarily have to be able to see all roles in the realm. Cheers, Dmitri. On Wed, Mar 25, 2026 at 6:14 PM Yufei Gu <[email protected]> wrote: > Hi Dmitri, I think the concern about introducing a global principal role > for listing all principal roles is valid. > > That said, today a catalog admin can already grant catalog roles to any > principal role by specifying the role name [1]. From that perspective, > allowing admins to list principal roles does not seem like a significant > security risk. > > I’d suggest double checking the concrete use cases before deciding. In an > offline discussion with Prashant, one valid case is that the UI needs to > surface a list of principal roles for granting. It would be great to have > Michael weigh in on additional use cases. > > To me, having a clear and compelling use case is the key decision point for > moving this forward. > > 1. > > https://polaris.apache.org/in-dev/unreleased/command-line-interface/#grant-1 > > Yufei > > > On Wed, Mar 25, 2026 at 2:55 PM Dmitri Bourlatchkov <[email protected]> > wrote: > > > Hi Yufei, > > > > Do you think it's okay to _automatically_ add the new role to all > > Principals that get the "catalog admin" role? > > > > I'm sure it can work fine in some specific deployments, but I have doubts > > about doing this automatically across all deployments. > > > > From my perspective, this seems like an overreach because each > > catalog_admin role is local to its catalog, but the new role is global to > > the realm and gives access to principal roles that are scoped under the > > realm. > > > > Automatically exposing realm data to catalog-specific admins seems to > > contradict the principle of separating catalog roles from principal > roles. > > > > WDYT? > > > > As far as I can tell, Michael opened the related issue as a convenience > > improvement. Perhaps we could find another solution that solves the > > convenience problem without wide automatic grants. > > > > Thanks, > > Dmitri. > > > > On Tue, Mar 24, 2026 at 8:32 PM Yufei Gu <[email protected]> wrote: > > > > > Thanks for working on this. I did one pass. Left some comments. One > > > important thing missing in the PR is how it supports the existing > realm. > > > The new role (`catalog_role_manager`) is created only during bootstrap, > > and > > > re-bootstrap is rejected for existing realms. The runtime silently > skips > > > the feature when the role is missing, so upgraded deployments will > never > > > get it. We need a migration path that creates the role on startup if > > > absent, without requiring a full realm purge. > > > > > > Yufei > > > > > > > > > On Mon, Mar 23, 2026 at 10:19 AM Dmitri Bourlatchkov <[email protected] > > > > > wrote: > > > > > > > Linking old dev thread for reference: > > > > https://lists.apache.org/thread/ws0blghsv8jl9rbwpgfgcbzjs7d38242 > > > > > > > > On 2026/03/23 17:17:51 Dmitri Bourlatchkov wrote: > > > > > Hi All, > > > > > > > > > > Vignesh opened PR [3852] on Feb 20. > > > > > > > > > > This PR affects Polaris' internal RBAC. > > > > > > > > > > I personally do not have enough context in the internal RBAC use > case > > > to > > > > be > > > > > able to reason about possible adverse effects. > > > > > > > > > > Michael, Dennis: Please review this PR, if possible. > > > > > > > > > > From my side, I do not see any reason against merging this PR. > > > > > > > > > > I propose giving it a few more days in review and then merging. > > > > > > > > > > [3852] https://github.com/apache/polaris/pull/3852 > > > > > > > > > > Thanks, > > > > > Dmitri. > > > > > > > > > > > > > > >
