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 that a problem?
The user had to give access to the project but also specify access to each pipeline belonging to that project. That wasn't a big deal for small projects, but as complexity increases, it becomes really cumbersome to scale and maintain. Another issue was that we were not able to create flexible complex custom user roles.How did we overcome it?
To solve the problem, we had to replace what we had with a new technology that we developed using REGO OPA (open policy agent). It provided us with scalability and opened the door for cool features we have already introduced and others that are planned for the future. One of those features is the ability to use globing. This eliminates the need to specify each resource or action and allows you to simply write policy like organization:**, which grants access to perform all actions under all resources.
How does it look now?
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.
Roles & Policies - the future
Our goal is to achieve a fully customizable and scalable solution that will enable enterprise customers to handle access to their resources. For example, as an admin user, I would like to give access to Project B and all its child entities by using globing and scoped permissions, avoiding the need to add permissions for each action on the entity manually.
One possible way of achieving this would be by the user creating a role that contains permissions to perform all actions on a specific project:
Action: `organization:<org_canonical>:project:*`
Resource: `organization:<org_canonical>:project:<project_canonical>`
That's just one example, but by moving to an OPA-based permissions system, we've ensured that there is a bright future for Roles & Policies. If you'd like to try it yourself, sign up for Cycloid's trial version, or check out the docs for more information.
Join 3,075 other DevOps enthusiasts by signing up for the quarterly Cycloid newsletter
Read More
Announcing InfraPolicies - and a surprise!
We've taken our first steps into a new year and it is a new year from which we are expecting a lot....What are InfraPolicies?
InfraPolicies (infrastructure policies) are an implementation of Policy as Code. They provide...The Cycloid European harmonization project - a long name for a cool concept
One of the things you accept when you’re a freelancer is that, along with the freedom and ability...