Hi Dmitri, Thank you for the confirmation on custom authorizers denying operations related to CATALOG_ROLE and PRINCIPAL_ROLE.
> The question about the "root" user still stands. Ranger authorizer can be configured to designate a superuser; allowing all accesses by this user. I hope this can help address any concern about authorizing access from "root" user. Thanks, Madhan On 3/3/26, 10:29 AM, "Dmitri Bourlatchkov" <[email protected] <mailto:[email protected]>> wrote: Hi Madhan, +1 to denying CATALOG_ROLE and PRINCIPAL_ROLE operations if they are not "natural" to a custom Authorizer. It is definitely possible to make a fully-functional Polaris with a non-default Authorizer implementation that will not depend on the default Polaris RBAC model concerning catalog/principal roles. The question about the "root" user still stands. AFAIK, it may currently be necessary to "bootstrap" the root user and perhaps local Polaris Principal "Entities", even if actual authorization and authentication are external. I'm a bit fuzzy on this aspect ATM, but I'm sure we can figure it out. Basically, IIRC, Principal Entities are required for Authentication to work properly. Authorization does not have to rely on local pricipal entities. I hope the in-progress Authorizer SPI refactoring (driven by Sung) will soon remove that requirement and add clarity to this question. Cheers, Dmitri. On Mon, Mar 2, 2026 at 5:19 PM Madhan Neethiraj <[email protected] <mailto:[email protected]>> wrote: > Hi Sung, > > Thank you for the response. I agree on authorizer implementations choosing > to deny operations on PRINCIPAL_ROLE and CATALOG_ROLE. CLI commands like > "principal-roles create", "catalog-roles create", "catalog-roles list" (and > equivalent APIs) will fail when the configured authorizer doesn't support > these operations. It will be good to get confirmation that Polaris itself > is not dependent on these operations being available, for example for root > user. > > Thank you for the RFC to refactor the authorization SPI. I will review and > provide my feedback shortly. > > Thanks, > Madhan > > > On 3/1/26, 7:44 PM, "Sung Yun" <[email protected] <mailto:[email protected]> > <mailto: > [email protected] <mailto:[email protected]>>> wrote: > > > Hi Madhan, > > > Great question. This is exactly the boundary we’re trying to make explicit > in the current authorization refactor work. > > > Short answer: for external PDP-backed authorizers (Ranger/OPA/etc.), my > thought is that PRINCIPAL_ROLE / CATALOG_ROLE admin flows should be treated > as Polaris-native RBAC admin operations and denied by default, rather than > requiring each external authorizer to implement Polaris RBAC semantics. > > > Concretely, to answer your questions: > > > 1) Should an implementation ignore such operations by failing them? This > might be okay if Polaris core doesn’t have any dependency on these > operations. > - IMHO fail/deny is the expected behavior for Polaris-native RBAC admin > operations with external authorizers. There is currently work in progress > to update the OpaPolarisAuthorizer to align with this expectation. > 2) If implementations are expected to authorize these operations, are they > expected to manage the resulting metadata updates as well (like > create/drop/list of principal roles/catalog roles/grants/revokes) as well? > Or would Polaris maintain the metadata updates? If Polaris maintains the > metadata, are all implementations expected to honor the grants/revokes > stored in this metadata? > - I think the external authorizers should deny these operations, and just > ignore existing metadata. There is currently work in progress to update the > OpaPolarisAuthorizer to align with this expectation, which may be of > interest to you. > > > We’re documenting and implementing this direction in: > > > - RFC: > https://docs.google.com/document/d/1OaiQG_C4-yUe0ihaDBxtw_mEcOOzUBnWPazzVbjQi5U/edit?tab=t.0#heading=h.dyow25dt9w1 > > <https://docs.google.com/document/d/1OaiQG_C4-yUe0ihaDBxtw_mEcOOzUBnWPazzVbjQi5U/edit?tab=t.0#heading=h.dyow25dt9w1> > < > https://docs.google.com/document/d/1OaiQG_C4-yUe0ihaDBxtw_mEcOOzUBnWPazzVbjQi5U/edit?tab=t.0#heading=h.dyow25dt9w1 > > <https://docs.google.com/document/d/1OaiQG_C4-yUe0ihaDBxtw_mEcOOzUBnWPazzVbjQi5U/edit?tab=t.0#heading=h.dyow25dt9w1> > > > - Parent tracking issue : https://github.com/apache/polaris/issues/3779 > <https://github.com/apache/polaris/issues/3779> < > https://github.com/apache/polaris/issues/3779> > <https://github.com/apache/polaris/issues/3779>> > > > That work introduces clearer intent-based SPI behavior and makes it > explicit that different PolarisAuthorizer implementations can avoid native > RBAC dependencies in the Polaris call paths. > > > Cheers, > Sung > > > On 2026/03/02 03:28:06 Madhan Neethiraj wrote: > > Hello, > > > > > > > > As suggested in PR #274, all authorizer implementations are expected to > handle all operations in PolarisAuthorizableOperation. However, entity > types PRINCIPAL_ROLE and CATALOG_ROLE are used to manage grants – which > seems specific to Polaris’s default authorization. An authorizer > implementation, like Apache Ranger, will manage grants in its own policy > model, hence may not require/support grants managed via PRINCIPAL_ROLE and > CATALOG_ROLE. > > > > > > > > Given this, I am looking for guidance on how an authorizer > implementation should handle such operations. > > > > > > > > 1) Should an implementation ignore such operations by failing them? This > might be okay if Polaris core doesn’t have any dependency on these > operations. > > > > > > > > 2) If implementations are expected to authorize these operations, are > they expected to manage the resulting metadata updates as well (like > create/drop/list of principal roles/catalog roles/grants/revokes) as well? > Or would Polaris maintain the metadata updates? If Polaris maintains the > metadata, are all implementations expected to honor the grants/revokes > stored in this metadata? > > > > > > > > Thanks, > > > > Madhan > > > > > > > > > > > > > > > > > > > > >
