+1 on denying RBAC related operations. I'd suggest documenting them in the class to clarify that.
Yufei On Tue, Mar 3, 2026 at 3:16 PM Madhan Neethiraj <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
