13. Permissions
Overview
Security Policies Scheme is organized by 2 principal tools: groups (user groups and system roles) and Access Control List defined for each CP's object.
Note: About groups and system roles you can read more here.
Object's Access Control List specifies who can work with the object and what he can do with it. It is defined as a pair of attributes:
- a User or User Group ID
- Permissions
The permission settings are divided into the following options which can be combined for the object:
- Read
- Write
- Execute
Below is a mapping of the objects' possible actions to permissions which demonstrates what actions will be allowed or denied to a user or user group.
Note: according to Security Policies Scheme WRITE permission is not enough to add/delete any Cloud Pipeline object. A specific *_MANAGER role is required also (about roles see here).
| Object | User Action | Permission |
|---|---|---|
| Folder | View folder | Read |
| List folder contents | ||
| Create object (e.g folder, pipeline, etc.) | Write | |
| Delete folder | ||
| Rename folder | ||
| Change parent | ||
| Upload metadata | ||
| Pipeline *Permissions for a pipeline version are inherited from the pipeline |
View pipeline | Read |
| List pipeline attributes | ||
| Delete a pipeline | Write | |
| Edit pipeline attributes | ||
| Change parent | ||
| Run a pipeline | Execute | |
| DataStorage *Permissions for files in data storage are inherited from the data storage |
View datastorage | Read |
| List datastorage contents | ||
| Delete a datastorage | Write | |
| Edit datastorage attributes/contents | ||
| Change parent | ||
| Pipeline run | View runs | Inherited from a run pipeline |
| View run logs | ||
| Launch a pipeline | ||
| Stop a run | ||
| Rerun | ||
| Tool run | View runs | Admin and Owner only |
| View run logs | ||
| Launch a pipeline | ||
| Stop a run | ||
| Rerun | ||
| Cluster node | View a cluster | Inherited from a currently assigned run |
| View node details | ||
| Terminate a node | ||
| Docker Registry | View registry | Read |
| Add registry | Write | |
| Delete registry | ||
| Edit registry attributes | ||
| Run a child tool | Execute | |
| Tool group | View tool group | Read |
| Create tool group | Write | |
| Edit tool group | ||
| Delete tool group | ||
| Run a child tool | Execute | |
| Tool | View enabled tool | Read |
| View disabled tools list | ||
| Edit tool attributes | Write | |
| Run tool without a pipeline | Execute | |
| Instance management | Admin and Owner only | |
| Run configuration | View run configuration | Read |
| Delete a run configuration | Write | |
| Edit run configuration attributes | ||
| Change parent | ||
| Run a run configuration | Execute |
Note: also you can manage permissions on the Cloud Pipeline objects via CLI. See 14.7. View and manage Permissions via CLI.
Owner property
Each object has an additional "Owner" property. The owner of the object can manage its Access Control List. Owner property is assigned to a user that created an object.
How to change an owner
The Owner of an object can be changed easily for:
- Folders;
- Pipelines and pipelines versions;
- Data storages;
- Run configurations;
- Docker registries, Tool Groups and Tools.
Note: you shall have Owner or Admin role.
To change an owner of an object:
- Select an object.
- Click "Gear" icon in the top-right corner of the screen.
- Navigate to Permissions tab.
Note: To edit permissions:- for a Folder - click the "Gear" icon → Edit folder
- for a Docker registry - click the "Gear" icon → Registry → Edit.
- for a Tool group - click the "Gear" icon → Group → Edit
- for a Tool - click the "Gear" icon → Permissions.
- Click owner's name. Now you can edit it:
- Start to enter a desired username and system will suggest you the existing users.
Click the desired username. - Click "Apply" control and the changes will be saved.
Also you can change an owner of an object via pipe CLI - see here.
Admin role
Admin property can be given by assigning ROLE_ADMIN to a user (about roles see here). The user gets Read/Write/Execute/Owner permissions to all objects in the system.
Initially, a user with ROLE_ADMIN shall be an authenticated domain account (SAML/OAuth/OpenID) defined during a system deployment (in some properties file or database).
Permission settings
The permissions could be granted to a user in one of the following ways:
- the system has a "default" system role or user group. This type of system roles or groups assigned by default once a user is created;
- assigned user groups or system role where every member has the same permissions for specific objects;
- granted permissions for specific user.
The priority of permissions granted for specific object explicitly is higher than the group or role permissions, e.g. if a basic user is included into the group that doesn't have an access to some folder but he has permissions explicitly defined for himself that allow him to work with that folder, he will have an access to it.
To assign object's permissions to a user or user group you shall move to the object's page and click the "Gear" icon in the top-right corner of the screen and select "Permissions" tab.
Note: To edit permissions:
- for a Folder - click the "Gear" icon → Edit folder
- for a Docker registry - click the "Gear" icon → Registry → Edit.
- for a Tool group - click the "Gear" icon → Group → Edit
- for a Tool - click the "Gear" icon → Permissions.
You can explicitly define permissions for the object for a particular user or group of users (users within the same Group) in the "Permission" form by clicking on its name in the "Groups and users" list.
Note: if you couldn't find the desired user or user group, you can add it via "Add a user" and "Add a user group" controls (see the picture below, 1).
The additional section for a particular user or user group suggests you tick the desired grants. Here you can allow or deny specific permission options (see the picture above, 2).
Note: if you don't tick any possible variant, it will be inherited from the parent object (e.g. a pipeline in a folder inherits permissions from it) (see the picture above, 3).
Example 1: according to the picture above, a user will get WRITE and EXECUTE permissions for an object, and the READ permission will be inherited from the parent object.
Example 2: on the picture below we see Permission form of a run configuration. We grant a user READ and EXECUTE permissions, but deny WRITE permission. So the user is able to see the run configuration and run it, but he can not edit its parameters:
