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).
Storage reader role
Read-only access to all data storages can be given by assigning ROLE_STORAGE_READER to a user. The user gets READ permission to every data storage in the Platform - even if the storage permission settings deny READ to that user or to their groups - and so is able to browse storages, download their data (via GUI or pipe CLI), view storage attributes and tags, and view the storage permission settings.
The role grants nothing but READ:
- WRITE, EXECUTE and OWNER permissions are still resolved from the storage permission settings - so if the user was granted WRITE to some storage, they keep it
- listing of object versions is not covered by the role - it still requires the OWNER permission to the storage
- archived objects are not covered by the role either - they still require the OWNER permission to the storage or one of the ROLE_STORAGE_ARCHIVE_MANAGER/ROLE_STORAGE_ARCHIVE_READER roles (see Storage lifecycle). As these roles take effect wherever the user has READ, a user having both ROLE_STORAGE_READER and ROLE_STORAGE_ARCHIVE_READER is able to view archived objects of every storage
- the global search results are not extended by the role - they still include only the storages the user has READ permission to by the storage permission settings
- the
mountcommand inside a run is not allowed by the role - it is still available only for the users with the ROLE_ADMIN or ROLE_STORAGE_ADMIN role - the runs, launched by the user, mount all the storages of the Platform - as for the users with the ROLE_STORAGE_ADMIN role - but in a read-only mode. A storage is mounted with the write access only if the user was granted WRITE to it and nothing else makes it read-only (e.g. a read-only mode of the storage quota or a sensitive run)
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:
Permissions granted to a user
The "Permissions" form shows all users and groups granted permissions to a single object. The opposite view - permissions granted to a single user on all objects of a type - is available via the API method GET /permissions/user?userId=<user ID>&aclClass=<object type>. Supported object types are DATA_STORAGE and PIPELINE.
For each object, the method returns the object and the permission entries that concern the user - the ones set for the user itself, for one of the user's groups or for one of the user's roles. Each entry combines the permissions set on the object with the ones set on its parent folders: the permissions not set on the object are taken from the closest parent folder they are set on. So an entry may differ from the one shown in the "Permissions" form of the object, and an object may be returned only because of the permissions set on its parent folder. Each entry keeps both the allowed and the denied permissions. Objects without such entries are not included.
The method is available to admins, to the users with the ROLE_USER_ADMIN or ROLE_USER_READER role, and to the users that have READ permission to the specified user. Admins get the objects of all the Platform, other users - only the objects they have READ permission to themselves.
Note: the method returns only the permissions set in the permission settings of the objects. It does not show the access the user gets by ownership or by a role that gives access regardless of the permission settings (e.g. ROLE_ADMIN, ROLE_STORAGE_ADMIN, ROLE_STORAGE_READER), nor the access limited by a storage quota or by the mount status of an NFS storage. So, a user may have access to an object that is missing in the result, or less access than the returned entries grant.
More about Cloud Pipeline API see here.