> ## Documentation Index
> Fetch the complete documentation index at: https://docs.vessl.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Access control

VESSL's Role-Based Access Control (RBAC) system allows you to manage user permissions for various resources, referred to as a **target**. This guide explains how to configure and manage access rights for your team.

### Key Terms

* **Target**: A resource within VESSL to which you can assign permissions. Key targets include **Project**, **Workspace**, **Service**, **Pipeline**, **Storage**, and **Volume**. Permissions for **Run** are managed through their parent **Project**.
* **Permission**: A specific action a user is allowed to perform on a Target, such as `Read`, `Write`, or `Manage`.
* **User Group**: A collection of users. Permissions assigned to a group are inherited by all its members, simplifying access management.

## Overview

<Tip>Take a quick tour to learn how to manage access control and user groups using the demo below.</Tip>

<div style={{ marginBottom: '180px', position: 'relative', paddingTop: '230px' }}>
  <iframe src="https://demo.arcade.software/aWKLIuQpiOqNstQKI3dM?embed&embed_mobile=tab&embed_desktop=inline&show_copy_link=true" frameBorder="0" loading="lazy" webkitAllowFullScreen="" mozAllowFullScreen="" title="Manage Access Control and User Groups in Organization Settings" style={{ position: 'absolute', top: '0px', left: '0px', width: '100%', height: '400px', colorScheme: 'light' }} />
</div>

Access to any **Target** is granted only to users with explicit permissions. You can manage these permissions on the **Access control** page for each **Target**. For example, to manage who can access a specific **Project**, you would go to that **Project**'s **Access control** page.

The user interface dynamically displays actions based on your permissions. If you only have `Read` access to a fine-tuning **Project**, you will not see the link to the **Settings** page, as it requires `Manage` permissions.

### User Groups

Permissions can be assigned to individual users or [**User Groups**](./user-groups). A user can belong to multiple groups, and a group can contain multiple users. When a permission is granted to a **User Group**, all users within that group inherit that permission.

Every **Organization** includes a default, VESSL-managed user group:

* **everyone**: This group automatically includes all users in the **Organization**. You cannot delete or edit this group.

### Default Permissions

When a new **Target** is created, the following permissions are automatically assigned:

* The creator is granted `Manage` permission.
* The **everyone** group is granted `Read` permission.
  * **Exception**: This permission is not added if you create a **Project** and check the **private project** option.

***

## Permissions per Target

Below is a list of available permissions for each **Target**.

### Organization

* **Manage**: Similar to the former "admin" role, this grants full permissions for all **targets** within the **organization**.
  * **Exception**: Cannot remove other users with `Manage` permissions from the **organization**. This action is reserved for the **organization owner**.
* **Create project**: Allows creating **projects** within the **organization**.
* **Create workspace**: Allows creating **workspaces** within the **organization**.
* **Create service**: Allows creating **services** within the **organization**.
* **Create pipeline**: Allows creating **pipelines** within the **organization**.
* **Create storage**: Allows creating **storages** within the **organization**.

### Project

* **Read**: View the **projects** and its **runs**. This does not include SSH or Jupyter access information.
* **Manage Runs**: Includes `Read` permissions, plus the ability to create, manage, stop, and delete **runs** within the **project**, including SSH and shell access.
* **Manage**: Includes `Manage Runs` permissions, plus the ability to edit the **project**'s metadata, manage access control, and delete the **project**.

### Workspace

* **Read**: View the **workspaces** and its information. This does not include SSH or Jupyter access information.
* **Edit**: Includes `Read` permissions, plus the ability to edit, start, and stop the **workspace**.
* **Manage**: Includes `Edit` permissions, plus the ability to delete or terminate the **workspace** and manage its access control.

### Service

* **Read**: View the **servics** and its **revisions**.
* **Execute**: Includes `Read` permissions, plus the ability to create, edit, run, and delete **revisions**, and edit endpoint settings.
* **Manage**: Includes `Execute` permissions, plus the ability to edit or delete the **service** and manage its access control.

### Pipeline

* **Read**: View the **Pipeline**, its **executions**, **revisions**, and **triggers**. This does not include webhook trigger endpoints.
* **Execute**: Includes `Read` permissions, plus the ability to run and stop the **pipeline**, manage **triggers** (create, edit, delete), and view webhook trigger endpoints.
* **Edit**: Includes `Execute` permissions, plus the ability to edit the **pipeline**, create, edit, and archive **revisions**, and star the **pipeline** (stars are shared across the **organization**).
* **Manage**: Includes `Edit` permissions, plus the ability to delete the **pipeline** and manage its access control.

### Storage

* **Read**: View the **storages** and its metadata (does not include the list of **volumes**).
* **Create volume**: Includes `Read` permissions, plus the ability to create **volumes** within the **Storage**.
* **Manage**: Includes `Create volume` permissions, plus the ability to edit or delete the **storage** and manage its access control.

### Volume

* **Read**: View the **volumes**, its information, and its files.
* **Write**: Includes `Read` permissions, plus the ability to write files to the **volume**.
* **Manage**: Includes `Write` permissions, plus the ability to edit or delete the **volume** and manage its access control.

***

## Important Concepts

### Organization Owner

Each **Organization** has a single **Organization owner**. This is the only user who can remove other members with `Manage` permissions from the **Organization**.

### Assume Subject

**Pipelines** and **services** have an "Assume Subject" feature to handle potential permission conflicts. For example, a **pipeline** might be created by a user with permission to read a certain **volume**, but executed by a user who lacks that permission.

* Only users with `Manage` permission can edit the "Assume Subject".
* You can only set the "Assume Subject" to yourself or a **user group** you belong to.
* When a **pipeline** or **service** runs, it inherits the permissions of the "Assume Subject". For it to successfully read a **volume**, the "Assume Subject" must have the required `Read` permission.