Nikola, a front end developer here at Cycloid, tells us what led to our recent shake up of Roles & Policies, why what we had could be improved, and how we went about improving it.

Until recently, our Roles and Policies system used a one-to-one relation. What does it mean? It means that the user was able to assign only 1 policy for 1 entity without any link or hierarchy between those entities.

Why was the one-to-one approach a problem?

In practice, the one-to-one model created three major headaches:
• You had to grant access to the project and then repeat the process for every pipeline inside it.
• The manual repetition became unmanageable as the number of pipelines grew.
• There was no way to compose flexible, composite roles for complex organisations.

How did we overcome this limitation?

To solve the problem, we replaced our old model with an engine powered by Open Policy Agent (OPA) and written in Rego.
OPA is an open-source, general-purpose policy engine that brings unified, context-aware enforcement to modern stacks. Its declarative language, Rego, lets us express permissions as code and evaluate them against JSON inputs, completely decoupling policy from application logic.
That separation immediately gave us the scalability we needed and opened the door to new features—such as flexible globbing patterns—that we have already introduced and others we have on the roadmap.

How does the new model work?

Now an organization can create highly flexible complex custom roles and even achieve role grouping by creating various roles and assigning them to a team. If we need to be more specific, the role can be created using system-defined actions and resources or/and with manually created actions. From a technical point of view, we now have clear ground and solid foundations for developing all the features we’ve planned for Roles & Policies – permissions scoping, enhanced globing and even greater flexibility.