Role-Based Access Control

What you’ll learn#

  • What Role-Based Access Control is
  • How Role-Based Access Control works

What is Role-Based Access Control#

Role-Based Access Control (RBAC) system allows you to orchestrate areas of responsibility for your team and ensure security of the work process.

RBAC is based on the three main concepts: account Roles, Resources and Permissions to resources.

Roles#

Every account has an assigned role (Owner, Admin or User), which defines an initial set of permissions and other available functionality for this account.

hierarchy
  • Owner: It is the first account added to your CodeNOW and can be deleted only by another Owner. It can invite any type of account.
  • Admin: Receives all available permissions to any resource by default. It can invite other Admins and Users.
  • User: User doesn't have any initial permissions. This account can not invite other users.
note

The Owner/Admin roles are default source of permission for an account.

Resources#

In CodeNOW, you create and manage different resources, such as application components, domains, deployment configurations, etc.

Applications, Components, Environments and Managed Services are resources with adjustable access through Permissions.

Multi-permission resources#

Deployed Applications and Deploy Configurations are multi-permission resources. It means that for full access they require permissions on other resources besides Deployer permissions on the application.

  • Deployed application section requires that a user have permission (e.g. Viewer) on the Environment, where the application was deployed to see that deployed application in the list.
  • To create your Deploy Configuration, you have to have access to an Environment you want to deploy an application on and all Managed Services you want to engage in your configuration.

Permissions#

Resources have sets of available permissions which grant access to certain features of the resource. Those permissions could be created for individual user or for a team.

permissions in UI
  • Admin: You are granted this permission automatically when you create a new resource. Alternatively, it can be granted to you by another user. It gives you full control of the resource.
  • Deployer: Gives the ability to create, edit, or delete deployment configuration and then use it in your deployment. You also need to have permissions on the environment you will use. This is an essential part of Multi-permission resources for application deployment.
  • Developer: Gives an ability to access and edit the Git repository.
  • Documentation Writer: Gives you the ability to create, edit, and delete documentation in Documentation Dashboard.
  • Permission Editor: Gives you the ability to create, edit and delete permissions.
  • Viewer: Gives you the read-only access. A viewer will not be able to edit any file or configuration.
  • Operator: Reveals credentials (connectionString, login, password...) for admin access to a service.
Table of available permissions for different resources
PermissionApplicationComponentEnvironmentServices
Admin✔️✔️✔️✔️
Deployer✔️✔️
Developer✔️✔️
Documentation Writer✔️✔️
Permission Editor✔️✔️✔️✔️
Viewer✔️✔️✔️✔️
Operator✔️

note

A component of an application inherits the permissions from that application.

Source of permissions#

Every permission set has its own source (e.g. your account role, team etc). Permissions sources are independent. As shown on the picture below, if a user looses its Admin role (1st set) it will become just a viewer (2nd set).

set replacement example

Permission override#

Another important principle of the RBAC system is permission override - which is based on union operation, not exclusion or intersection. New permission sets only expand the user's privileges, hence missing (grey) permissions in a new set will not be taken away from the user.

union principle

What's Next?#

There are other manuals you could be interested in: