Roles & Permissions management on Qovery - What do you expect?

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?

feel free to comment below :point_down:

2 Likes

it will be good to have a

  • developer access (which is essentially a ReadOnly access of qovery resources)

  • admin/owners access (RW access to everything)

This access should/could be on a cluster level - such that developers can have access to Production Environment if need be.

Our architecture is such that we have different clusters for different environments

2 Likes

+1 We need devs to also have access to prod but limited by what they can do. So cluster level R/W access sounds good to me.

1 Like

Engineers (by cluster):

  • No access
  • Read access
  • “Operations” such as start/stop applications
  • Admin (create applications, delete applications)
  • Owner (create environments, delete environments)

Account Owner

  • Access account settings
  • Access cluster settings

Billing Owner

  • Access Billing
1 Like

thanks for your feedback!

Few questions on my side:

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.

quick update here: we have moved forward with the specs and came up with a first solution.

I’ll try to share some info here this week

2 Likes

Update

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!

1 Like