Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update permissions.md #1275

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
+569 −0
Open

Update permissions.md #1275

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
fe3857a
Rbac docs first draft.
VeljkoMaksimovic Sep 13, 2022
ddae4a0
Finished draft version for rbac
VeljkoMaksimovic Sep 24, 2022
a7756fd
Remove redundant comments
VeljkoMaksimovic Sep 26, 2022
66c0aa9
Update permissions.md
Charismatron Nov 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
37 changes: 37 additions & 0 deletions docs/security/custom-roles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,37 @@
---
Description: Custom roles for Semaphore platform.
---

# Custom Roles

If your organization needs more roles where permissions would be assigned with
higher granularity, you can define custom roles.

### Creating a new role

When defining a custom role, you need to give it a unique name (that does not clash
with any of the default roles) and select which [permissions](/security/permissions/) will
its users have. Role inheritance is also allowed, so you can create a new role
**Sys Admin** that will have all the same permissions as **Developer**, for example,
plus access to Self hosted agents (`organization.self_hosted.create`). Permissions
for the Sys Admin role are determined "dynamically", so if you later modify the Developer role
and add/remove some permissions from it, the Sys Admin role will reflect those
changes.

**TODO** Picture of UI for creating new role, when the ui gets made

### Organization role to project role mapping

If there is any role within the organization that needs to have access to all of the
projects, you can define an "*org-role to project-role mapping*" for it. If you want your
Sys Admins to have Admin level access to all of the projects, you can say that the Sys Admin role
maps to the project Admin role.

!!! warning "Note"
Custom roles are currently only available on our [enterprise plan](pricing).

!!! info "Default Roles"
As an organization that has Custom Roles enabled, you will still have access to the default roles as well.

Do you need Custom roles in order to use Semaphore? Contact us via this [form](/contact)

180 changes: 180 additions & 0 deletions docs/security/default-roles.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,180 @@
Default roles are available to all Semaphore users, regardless of the plan they are on.

If you or your organization need more roles with different permissions, there is an option
to create your own [custom roles](/security/custom-roles).

### Organization roles
<table style="background-color: rgb(255, 255, 255);">
<thead>
<tr>
<td>
Role name
</td>
<td>
Permissions
</td>
<td>
Notes
</td>
</tr>
</thead>
<tbody>
<tr>
<td>
**Guest**
</td>
<td>
<ul>
<li>Does not have any permissions within the organization, and can't see any information.</li>
</ul>
</td>
<td>
This role is intended for users that need access to some projects, but should not see
any information regarding the organization.
</td>
</tr>
<tr>
<td>
**Member**
</td>
<td>
<ul>
<li>Can create new projects.</li>
<li>Can view existing notifications.</li>
</ul>
</td>
<td>
</td>
</tr>
<tr>
<td>
**Admin**
</td>
<td>
<ul>
<li>Can do everything a member can.</li>
<li>Can view, manage, and modify everything within the organization
(people, secrets, pre-flight checks,
notifications, etc), except general settings and financial information.</li>
</ul>
</td>
<td>
Each of the organization's Admins is also Admin within every project owned by the given organization automatically.
</td>
</tr>
<tr>
<td>
**Owner**
</td>
<td>
<ul>
<li>Can do everything within the organization, including changing general
settings and deleting it.</li>
</ul>
</td>
<td>
By default, this role is assigned to the user that creates the organization.
<br/>
Each of the organization's Owners is also Admin within every project owned by the given organization.
</td>
</tr>
<tr>
<td>
**Accountant**
</td>
<td>
<ul>
<li>Manages billing</li>
</ul>
</td>
<td>
This role cant access any part of the Semaphore except for pages regarding
spending and financial information.
</td>
</tr>
</tbody>
</table>

### Project roles
<table style="background-color: rgb(255, 255, 255);">
<thead>
<tr>
<td>
Role name
</td>
<td>
Permissions
</td>
<td>
Notes
</td>
</tr>
</thead>
<tbody>
<tr>
<td>
**Reader**
</td>
<td>
<ul>
<li>Can view project activity, workflows, and jobs executed within those workflows.</li>
</ul>
</td>
<td>
Intended for someone who should monitor what is being done, but isn't a developer and shouldn't
modify anything. Perhaps an Engineering Project Manager.
</td>
</tr>
<tr>
<td>
**Contributor**
</td>
<td>
<ul>
<li>Can manually run, modify and stop workflows/jobs.</li>
<li>Can view project-level secrets and organization-wide secrets scoped for the given project.</li>
<li>Can attach to running jobs or debug jobs and projects.</li>
<li>Can view schedulers, project insights, and repository info.</li>
<li>Can manually run schedulers.</li>
<li>Can view, modify and delete artifacts for that project.</li>
</ul>
</td>
<td>
For developers who are currently working on the project, but aren't responsible for maintaining it
and setting up/modifying the environment in which the project exists.
</td>
</tr>
<tr>
<td>
**Maintainer**
</td>
<td>
<ul>
<li>Can do everything a contributor can.</li>
<li>Can view and manage people within the project.</li>
<li>Can view modify and manage project-level secrets, schedulers and,
project-level pre-flight checks.</li>
<li>Can view and manage project settings.</li>
</ul>
</td>
<td>
Usually developers who own the project.
</td>
</tr>
<tr>
<td>
**Admin**
</td>
<td>
<ul>
<li>Can do everything within the project, including deleting it.</li>
</ul>
</td>
<td>
By default, this role is assigned to the user that created the project, and
this user is a primary repository token holder.
</td>
</tr>
</tbody>
</table>

Loading