May 16, 2025
RBAC AuthZ Interface Idea-exchange
Invited Alec Henninger Kliban, Dennis Brian Bouterse Grant Gainey
Attachments RBAC AuthZ Interface Idea-exchange

# Summary

Brian Bouterse introduced Alec Henninger to discuss externalizing Pulp's RBAC, addressing challenges with the current system for large enterprise users and aiming for integration with Red Hat's unified RBAC service on console. Alec Henninger provided insights into pluggable interfaces, authorization query techniques, and using SpiceDB as a potential solution, emphasizing the strategic importance of externalizing access management. The participants, including Brian Bouterse, Grant Gainey, and Dennis Kliban, explored concrete next steps focused on experimenting with SpiceDB and defining a pluggable interface for Pulp to interact with external authorization systems.

# Details
Introduction of Alec Henninger Brian Bouterse introduced Alec Henninger, who works on console with a focus on identity and access management, including the management fabric. Alec has extensive experience in this domain at Red Hat and is currently working on a re-imagined access control experience for console.

Pulp Project Overview and Current RBAC Brian Bouterse provided a refresher on the Pulp project, highlighting its strong and business-centric upstream with commercialization outside and inclusion in Red Hat products. Brian explained that Pulp currently has an RBAC system that works well if users, groups, and permissions are kept within the Pulp database.

Challenges with Existing RBAC Brian Bouterse noted that enterprise users with large installations have provided feedback that their users and groups reside outside of Pulp, making replication impractical. The initial idea of using Django Kerberos faced the issue that permissions could only be attached after users logged in.

Console's Authorization Model Brian Bouterse explained that the services team operates the console installation of Pulp and uses a different authentication and authorization method. Authentication happens at the gateway, and authorization is performed using custom middleware and tables based on org IDs. This current system lacks fine-grained control.

Seeking Advice on Pluggable Interface Brian Bouterse stated the goal is to find a pluggable interface that allows users, groups, and roles to be external to Pulp. Alec Henninger agreed this is the right approach, emphasizing the strategic importance of externalizing access management to keep up with industry evolution.

Customer Issues with Replication Alec Henninger inquired about the specific issues customers face when trying to replicate their identity management into Pulp. Brian Bouterse clarified that this is primarily a concern for upstream users, as Pulp's RBAC isn't heavily productized, with most products using their own front-end RBAC and communicating with Pulp via administrative accounts.

Integration Challenges and Management Fabric Brian Bouterse and Grant Gainey elaborated on how products like Satellite and Quay use a single administrative user to interact with Pulp, while Ansible uses Pulp's API in a simplistic way but faces challenges with multiple RBAC systems. Alec Henninger noted that a pluggable system would improve integration stories, a goal of the management fabric to unify access control across Red Hat products.

Core Questions for Access Control Alec Henninger suggested that access control can be largely defined by two core questions: Can a subject perform an action on a resource? and What resources can a subject act upon? These questions can integrate with most access control systems, with a third administrative question about what subjects can act on a resource being less relevant to the application itself.

Techniques for Serving Authorization Queries Alec Henninger outlined two main techniques for serving authorization queries: prefiltering and postfiltering. He also discussed different models for providing data to authorization systems, including replicating preemptively and replicating on demand.

Pulp's Goals for Externalized RBAC Brian Bouterse detailed three main goals: enabling Pulp to use Red Hat's unified RBAC service on console, maintaining a simple built-in option for upstream users, and allowing enterprise upstream users with external systems to achieve fine-grained RBAC with Pulp.

Console's RBAC Configuration Brian Bouterse shared links to the console API specification and a repository defining roles for projects like content sources, illustrating how roles are currently managed externally for console applications that use Pulp. The goal is for Pulp to be used directly on console.redhat.com with a similar model.

Pluggability as a Solution Alec Henninger suggested that a pluggable interface would allow for a default RBAC implementation while also enabling integration with external systems like console's RBAC. Brian Bouterse agreed with this approach.

Exploring Concrete Implementations Brian Bouterse expressed interest in understanding how Pulp could interact with external authorization systems at request time and noted that shipping data out of Pulp upon object creation seems more tangible. He inquired about using SpiceDB as an example of an external system.

SpiceDB and Synchronization Alec Henninger explained that SpiceDB stores relationships between users and resources, but Pulp would be responsible for updating these relationships. This synchronization process needs to consider consistency requirements.

Next Steps and Experiments Brian Bouterse proposed exploratory next steps, including experimenting with SpiceDB and the console RBAC model. Alec Henninger suggested that a SpiceDB experiment would be very similar to what is being done in console, as their platform is based on SpiceDB.

Defining Roles in SpiceDB Brian Bouterse questioned how roles would be defined in SpiceDB in the context of console's RBAC configuration. Alec Henninger explained that roles are modeled as data in console to allow for custom roles, involving traversing a graph of relationships from a resource to a user via role bindings.

Domain Level Authorization in Pulp Dennis Kliban explained that currently in Pulp, access to a domain grants access to all repositories within it, with super admin privileges at the domain level, which is a problem they aim to solve. Alec Henninger noted that fine-grained control is possible by informing the external system about relationships at a more granular level than the domain.

Graph Traversal for Authorization Alec Henninger described how authorization systems like SpiceDB traverse a graph of relationships to determine if a user has the necessary permissions. Role bindings can be placed anywhere in the graph to grant permissions at different levels, including specific repositories or organizations.

Modeling Roles and Permissions in SpiceDB Alec Henninger illustrated how roles can be bound to users or groups, with the possibility of nested groups. He also explained how roles as data and custom roles can be supported, allowing for compatibility with existing console RBAC.

Discussion of Next Steps and Options Brian Bouterse initiated a discussion about the next steps, suggesting options like experimenting with SpiceDB or console RBAC, either independently or with guidance from Alec. Grant Gainey proposed defining a pluggable interface in Pulp that external authorization systems would implement.

Proposed Pluggable Interface Grant Gainey detailed the envisioned pluggable interface with functions to check subject permissions on resources. He suggested an initial implementation that wraps Pulp's existing internal RBAC as a starting point before integrating with external systems like SpiceDB or console.

Focus on External Implementation First Brian Bouterse agreed with the pluggable interface concept but suggested focusing on implementing an external solution like SpiceDB first, without immediately trying to wrap the current Pulp RBAC. Alec Henninger seconded this, recommending a direct SpiceDB experiment to prove the interface concept.

Incorporating the "Remote" Object in the Model Brian Bouterse introduced the "remote" object as a key component in Pulp's workflow (syncing content to a repository) and requested it be included in the SpiceDB schema example. Remotes contain secure credentials, and validating read permissions on these is important.

Relationship Between Repository and Remote Dennis Kliban clarified that a repository can have zero or one assigned remotes, while a remote can be used by many repositories. Alec Henninger suggested modeling this relationship in the SpiceDB schema.

Permissions for Sync and Upload The discussion extended to specific permissions beyond "view," such as "sync" and "upload" for repositories and remotes. Alec Henninger noted that roles can be modeled as distinct entities or through broader admin-type roles.

Concrete Next Steps with SpiceDB Brian Bouterse felt the discussion provided concrete next steps for the Pulp developer community. Dennis Kliban inquired about the very first step for a simple proof of concept. Brian Bouterse suggested starting a SpiceDB container, loading the schema, and then having Pulp push tuple data.

Implementing Tuple Updates Dennis Kliban proposed using post-creation or post-save hooks on Pulp models to call out to SpiceDB. Alec Henninger recommended using SpiceDB directly for the initial proof of concept due to its better developer experience compared to console's internal system.

Pluggability of Post Hooks Brian Bouterse reiterated that the post-hook call should be pluggable. Grant Gainey agreed to focus the initial proof of concept on direct SpiceDB calls to understand the tuple structure and integration points before designing the pluggable interface.

Using SpiceDB Playground for Initial Exploration Alec Henninger suggested using the SpiceDB playground as an immediate step to understand how tuples and checks work. He offered to demonstrate this with concrete examples.

Verbalizing a SpiceDB Check Brian Bouterse requested a verbal explanation of how a SpiceDB check would work.

Zanzibar Syntax and Tuples Alec Henninger explained the Zanzibar syntax, which involves a resource, a relation, and a user forming a triple or tpple. This structure, written into Spice DB, describes relationships such as "user Brian is an admin for repository one". The order is typically resource to user, reflecting how the graph is often traversed.

Resource Relations and Graph Traversal Alec Henninger clarified that while the base is a relation, there can be levels of interaction. They demonstrated how a user's access to a repository could be indirect, granted through a domain relationship. A query asking if Grant Gainey can view a repository would return true due to Grant Gainey's membership in a domain that has the 'view repositories' relation, without exposing the underlying domain relationship. Brian Bouterse agreed this abstraction is valuable as it focuses on the application's concern of user access without needing to know the reasons why.

Meeting Conclusion and Next Steps Brian Bouterse concluded the valuable session and requested Alec Henninger to share everything they had written. Brian Bouterse planned to share notes with the developer group before their review call. While there was no immediate need for Alec Henninger to rejoin on video, Brian Bouterse indicated they would reach out asynchronously and potentially for occasional video calls.

Collaboration and Mutual Benefit Alec Henninger encouraged the team to involve them, highlighting that their participation is mutually beneficial. Alec Henninger explained their challenge in creating a universal interface across upstream projects and how the team's input on what works for them is valuable feedback that can be applied elsewhere. Grant Gainey and Dennis Kliban acknowledged this as the nature of open source, where collaboration and shared benefits drive participation and improvement for all involved.

# SpiceDB playground link

https://play.authzed.com/s/v_sT7q-3CqVP/relationships