Organization rules for runs start/stop
alessandro-sorint opened this issue · 10 comments
What would you like to be added:
It must be possible for the owner to set an option in
organization scope or project scope that authorize users from the same organization to perform
the actions of start and stop.
Why is this needed:
Currently only the organization owners can perform this actions.
@alessandro-sorint There're not enough details in this FR. Is it correct that only owners can do actions? Or is it a bug that members cannot do it. What's the meaning to be a member if you cannot do any action? Is this related to RBAC issue #13 ?
I think your issue #13 will be useful to manage run actions permissions.
Isn't this issue talking about run actions permissions (start/stop/cancel)?
I think your issue #13 will be useful to manage run actions permissions.
Isn't this issue talking about run actions permissions (start/stop/cancel)?
I see in the issue In future there could be the possibility to define custom roles there will be in the future the possibility to define a custom rule that can/can't do run actions with issue #13?
@alessandro-sorint There're not enough details in this FR. Is it correct that only owners can do actions? Or is it a bug that members cannot do it. What's the meaning to be a member if you cannot do any action? Is this related to RBAC issue #13 ?
I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.
I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.
The purpose of #13 (teams and RBAC) was to cover also such cases.
If it's too much then something simpler could be implemented (and a future implementation of #13 should migrate this simpler logic to its logic).
In such case:
- Is it ok to permit to everyone in the org to start/stop/cancel any run or there should be a filter based on branch, tag, PR (i.e. avoid anyone to stop a production deploy from master)?
- The same thing should be implemented also for tasks approval or we'll end up with users able to start/stop/cancel a run but not to approve tasks.
I think the current default behaviour makes sense: only owners should be able to stop / cancel / restart runs by default.
On the other side it would be nice to have an option (at organization / subgroup / project level) to allow standard (non-owners) members to perform those actions.The purpose of #13 (teams and RBAC) was to cover also such cases. If it's too much then something simpler could be implemented (and a future implementation of #13 should migrate this simpler logic to its logic).
In such case:
- Is it ok to permit to everyone in the org to start/stop/cancel any run or there should be a filter based on branch, tag, PR (i.e. avoid anyone to stop a production deploy from master)?
- The same thing should be implemented also for tasks approval or we'll end up with users able to start/stop/cancel a run but not to approve tasks.
@sgotti I think we can define the table preferences with this fields:
parent Parent
performActionCondition *When
performApproveCondition *When
- evry org/project/projectgroup can define 1 preferences; with when type we can define (branch/tag/ref) and include/exlude conditions.
- we can manage the hierarchy, for example if we define preferences for a org subgroup this will replace the org preferences.
- If preferences is not defined it will considered that the user member can't perform the action/approval.
APIs updates:
POST /orgs
POST /projectgroups
POST /projects
In the the request add this fields:
canPerformAction bool
performActionCondition *When
canPerformApproval bool
performApproveCondition *When
- if canPerformAction or performActionCondition are true the preference will be created.
- If the parent of project/projectgroup is a user the API will ignore this new fields.
In the same PR or another we can add APIs to update preferences.
PUT /projectgroups/{projectgroupref}/preferences
PUT /projects/{projectref}/preferences
the request can contains this fields:
canPerformAction bool
performActionCondition *When
canPerformApproval bool
performApproveCondition *When
@alessandro-sorint How to implement should come after we choosed what to implement, the behavior and the logic.
The logic is this:
- by default only the owner can perform run actions(cancel/stop/restart) and task actions(we have only accept)
- with this changes, the organization owner can add permissions for all the members, with some filter based on branch, tag, PR.
- there will be 2 kinds of permissions: run action permission and task permission.
- this permissions can be defined for organization scope, and in a hierarchical way for subgroups and projects(like secrets/variables).
- only owners can add this permissions and change it.
- the permission can be defined when the user create org/project/projectgroup or update next with dedicated API.
agola-web will change: in the org/project/projectgroup creation page add 1 check-box for run action permission with filters(not mandatory) and 1 check-box for task action permission with filters(not mandatory).
- this permissions can be defined for organization scope, and in a hierarchical way for subgroups and projects(like secrets/variables).
secrets and variables are different. They are types that are inherited from parents.
This is instead a property. If it's going to be inherited this will cause a lot of confusion with other properties (like PassVarsToForkedPR) and the overriding logic isn't clear:
- Projects my have different branches layout and names, so an inherited options doesn't make sense.
- what happens if I change the options filters inside a subgroup?
The cleaner solution will be to just have this config per project like any other config.
That's why teams and rbac roles as in #13 were introduced. You have a team of members that have specific roles on specific projects. The inheritance of the permissions was at the level of the teams hierarchy and not at the level of the org/projectgroups/proejcts hierarchy.