We have started working on the roles & permission management feature and wanted to hear from you about how you would like to manage the permissions of your organisation.
As of now, we have started going through a simple structure where only owners/admin users can access the organisation settings and the production resources (clusters/environments) while developer/viewer users can only access dev/staging/preview resources.
We would like to start with something simple covering the majority of the use cases and that could be extended in the future and cover additional needs.
Is this solution enough to cover most of the use cases within your company?
Is there any additional need you would like us to cover?
So you think that developers will never need to create&manage an environment by themself on a development cluster?
Do you think that this granularity level is really necessary? At least for a first version we wanted to give all those permissions on non-production clusters/env to the engineers.
having different permissions based on the cluster type (prod vs dev) is definitively something we had in mind but it seems you want to go further and instead have the permissions attached to a cluster and not to a cluster type. Would it be enough to have a separation just by cluster type? So it would mean that an “Admin” user would be able to manage production resources while a “developer” user would be able to manage only non-production resources without having to associate a cluster.
do you think that access “by project” is necessary? (i.e. you want to give access to project A but not project B)
What about cluster management (add/delete/edit etc…)? shall those actions be restricted only to admins or you would like some of the engineers to be able to manage the non-production clusters by themselves?
@a_carrano In our case we only have 1 project (might be more in the future) but 3 clusters (development, staging and production).
Regarding roles and rights, we want to prevent deleting something on production by accident for example. But still allow other users doing recurring operations whil other should not do anything. We used Cloud66 in the past, they had a really good right/role management.
However, I understand you are building a first version, it’s just important I think that the first version would not prevent you from developing into a more fine-grained solution later.
We have finalized our specs and we will go in the following direction:
We will have a list of basic roles with predefined and immutable permissions across orga settings, clusters and projects: Owner + Admin (like today), DevOps, Billing Manager, Viewer
If that’s not enough and you want to customize the access to the clusters/projects, as an admin you will be able create custom roles and specify:
– the access level on each cluster (read, deploy/create environments on it, admin)
– the access level on each project & environment type (project admin, manage creation/deploy/settings of each env type within the project)
we will probably start next sprint with the implementation, I’ll keep you updated!
