semaphore

semaphore copied to clipboard

background

usually you have at least 4 groups of persons accessing a tool like that:

1. global admins (full access to everything, everywhere)
2. project admins (full access to a project - only)
3. project users (specific action permissions in a project, e.g ability to click the build button but not modding an inventory etc)
4. readonly users (no action permissions, never)

what I currently see in semaphore is 1. and partly 2 with some kind of non-admin access which basically is not what I would expect when thinking of a "non-admin" user.

Semaphore already has the ability to choose team members for a project which is great and should "just" ;) be extended to a more specific role / group based system. I have not looked into LDAP yet but when implementing that it should match LDAP groups/netgroups in order to make use these here, too (e.g. LDAP group "semaphore_projectadmin_abc" will become a project admin of project "abc" in semaphore).

Permissions

global admin permissions

• like the current admin user
• all permissions of a project admin but for every project (see next topic)

project admin permissions

basically this is what an admin and even a non-admin user (when added as a team member) can do already except the user management part, of course.

when a user is added to a project and having project admin rights he should have the permission to:

• add/remove other team members
• set/unset a team member as project admin
• set/unset a team member as project user
  • set/unset a project user permissions: allow edit inventories/repos/..., allow to build/rebuild, ..
• set/unset a team member as readonly user
• full access to everything in that project, i.e. add/remove inventories, tasks, etc and do actions (build,rebuild etc)

project user permissions

• whatever has been set by an admin or project admin (see above)

readonly user permissions

• basically view / show everything where that user is member of - without any ability to modify
• optionally it would be nice to block changes of the own account (password, mail,..) so one can share that account with a wider audience

conclusion

I strongly believe that enterprise users require the above and that prevents them for actually using semaphore or at least offer it to their users. I would really appreciate seeing the above or at least parts of it in semaphore as actually atm I cannot share it with others without these changes.. I would love to contribute but absolute zero experience with Go - while I really love the look & feel & idea of semaphore..

for a first run I would be more then happy if we could have a readonly user permission and a simple project user permission where everything is blocked but actions like build/rebuild are allowed. The rest would be step 2..N then :)

refs:

• https://github.com/ansible-semaphore/semaphore/pull/405
• https://github.com/ansible-semaphore/semaphore/pull/413
• https://github.com/ansible-semaphore/semaphore/issues/368
• https://github.com/ansible-semaphore/semaphore/pull/310

Hi @steadfasterX

Thank you very much for your feedback!

This makes a lot of sense. Currently, we cannot give access to semaphore to developers or analysts because that would give them too much permissions (easy to break something by mistake). The roles mentioned make sense, devs would be project users, analysts readonly users.

As for the LDAP, I would differentiate user role and project assignment. For project assignment, I would suggest adding an external id field to the project. If a user is in a group that matches that id, it is added to the project's team (kind of what exists in bookstack). User role can be in the config, with a mapping of the type "role_name": "ldap_group_name".

Does this PR allow for per-task permissions? i.e. I need to allow a user to run a specific task (but not all tasks) belonging to a project.

One additional note: the implementation also should handle access tokens (see https://github.com/ansible-semaphore/semaphore/issues/1391)