Role-Based Access Control

CodeNOW's role-based access control (RBAC) allows granting users with the appropriate permissions on the relevant resources. With RBAC, development teams ensure that team members can only access information and perform the actions that their job requires. As such, RBAC is an important aspect of the security of software development projects and is essential to minimizing business risks.

For step-by-step instructions to create/manage teams, invite users, edit roles, and manage permissions, see Users and Teams. The following content provides the necessary concepts to understand and use the RBAC model:

1. Permission model
   1. Example
   2. Roles
      1. Owner
      2. Admin
      3. User
   3. Resource types and permissions
   4. Permission sources
   5. Permission inheritance
   6. Permission composition
2. What permissions do I need to perform this operation?
3. Tips

Permission model

Development teams using CodeNOW perform operations via the self-service portal (SSP), CLI, external administration tools, or code repositories. Users perform operations to view, edit, update, access, use, and delete resources of the software development project. Each resource has permissions that determine which operations it can participate in. Before executing an operation, users must acquire the relevant permissions on the resources that participate in the operation. CodeNOW's permission model defines 3 roles, 7 resource types, and a set of permissions for each resource type that enable specific operations.

Example

Paula is one of three back-end developers working together on a set of APIs. The corresponding back-end CodeNOW application consists of two components:

Note: In what follows, operations are in bold; resources are in italic.

Paula will only work on one of the two API components of the application. To perform her duty, Paula needs to: see and clone the code repository of the API component; push changes to the code repository, build the API component; create/use a deployment environment; edit/create application packages; edit/create deployment configurations; and deploy the API component. To execute those operations, Paula needs adequate permissions for the SSP, the application, the application component, and the deployment environment.

To get permission to use the SSP, Paula must be a registered CodeNOW user. To become a registered user, Paula needs to be invited by another user with admin or owner role.

Paula then joins the back-end-team team and benefits automatically from the team's permissions on resources:

Paula however will only work on the search-api component of the back-end application. The previous permissions give Paula the right to view, build, and deploy any component of the back-end application. To limit Paula's permissions to operations on search-api, her permissions on the other component of the application can be set to viewer only:

With this set of permissions, Paula can view but cannot build nor deploy the inventory-api component:

Related links:

• Create a team
• Grant permissions to a team
• Invite new users
• Add users to a team
• What permissions do I need to perform this operation?

Roles

CodeNOW users have one (and only one) of the following roles (ordered by descending power): owner, admin, user.

Owner

Owners (i.e., users with the owner role) can do any and everything: there are no permissions that they do not have granted by default. The owner role can only be revoked by other owners. Owners can promote users with the user role to the admin role, and users with the admin role to the owner role. Owners differentiate from admins in that they can perform operations that impact the CodeNOW account itself. In fact, the buyer of the CodeNOW subscription is often the first provisioned user and is granted owner permissions. Here are a few operations that only users with owner role can complete:

• Request new cluster
• Delete cluster

Admin

Admins can do anything that users with user role can do. Additionally, admins can create teams, invite users to the SSP, and assign them to teams. Admins can promote standard users to the admin role. Alternatively, they can downgrade other admin users to the standard user role. Given its great power, the admin role is a good fit for users with management responsibilities over the software project (e.g., tech lead, team lead, project manager, product manager, CTO). Here are a few operations (in bold in what follows) that only users with admin role — and above — can complete:

• Set up teams
  • Create teams
  • Invite users
  • Edit user role
• Check on the team's work:
  • See user activity log
  • See application activity log
• Add artifact repositories

User

By default, all invited users have the user role. When an invited user accepts the invitation and becomes a subscribed user, that user has no initial permissions on any resource besides the SSP. The new user can thus use the SSP for specific operations (e.g., create a new application). However, for any operations using pre-existing resources (e.g., previously created applications), the new user will need to be granted the appropriate permissions by another user (e.g., a user with admin role; a user with user role and admin permissions on the requested resource). The user role is generally a good fit for members of the development team that do not participate in management activities. Here are a few operations (in bold in what follows) that users with user role may perform when granted the necessary permissions:

• Code applications
  • Create a new application
  • Create a new environment
  • Create a new application component
  • Commit changes to a branch in a remote repository
  • Create a merge request
• Deploy applications
  • Build an application
  • Create deployment configurations
  • Deploy an application

Resource types and permissions

Every resource type has a set of permissions that describes the type of operations they enable:

Resource type		Permissions
Cluster	admin	permission's editor		developer		viewer
Environment	admin	permission's editor	deployer			viewer
Application	admin	permission's editor	deployer	developer	documentation writer	viewer
Managed services	admin	permission's editor		operator		viewer
Application component	admin	permission's editor		developer	documentation writer	viewer
Libraries	admin	permission's editor		developer		viewer
External services	admin	permission's editor		operator		viewer

Those permissions enable CRUD operations on the associated resource types:

Permission		Description
admin	CRUD	Implicity grants all the other permissions for the resource. E.g., a user who has admin permissions on an environment can perform the same operations as if he explicitly had deployer, viewer, or permission's editor permissions. Additionally, admin users can delete the associated resource type.
permission's editor	C-U-	Allows a user to update his own permission set and grant permissions to other users.
developer	C-U-	Allows performing operations that affect resources involved in the development of applications (e.g., application packages, components, libraries).
deployer	C-U-	Allows performing operations that affect resources involved in the deployment of applications (e.g., deployment configurations, domain, deployment environment).
documentation writer	CRUD	Allows CRUD operations related to the documentation of application components.
viewer	-R--	Grants access to information related to a resource.
operator	-RU-	Allows operations on managed services. For instance, a user with operator permissions on a Postgres managed service may log in pgAdmin and create new tables, run queries, add triggers, and more. He can also edit the deployment configuration for the database instance (e.g., storage size, number of nodes).

To see the complete list of permissions that an operation requires, see What permissions do I need to perform this operation?

Permission sources

Permissions are granted by permission sources (e.g., team, role, user):

• Users who are members of teams are granted the same permissions as the team.
• Users with admin and owner role can grant permissions to some users on any resource.
• Users with admin or permission's editor permission on a resource may grant permissions on that resource to some users.

Users may also inherit permissions (see Permission inheritance) in some cases.

The following illustration showcases a user who received admin permission on the demo-notification-net application from user alexsandman. The user also has developer and viewer permissions as a member of the team My-team. Each set of permissions is listed with its source:

Permission inheritance

To streamline common workflows, CodeNOW's RBAC features a permission inheritance mechanism that automatically grants permissions in some limited contexts:

• Users creating a resource type will generally have admin permissions automatically assigned to the newly created resource. That means they can grant permissions on that resource to other users. It also means they can delete that resource when need be.
• Permissions of users on components default to the parent application's permissions:
  • In the absence of explicitly set permissions on components, users inherit the same permissions on the components as set on the parent application.
  • In the presence of explicitly set permissions on components, those and only those apply to the components.

The user devcity-bruno has no permissions on any application.

As admin, let's give him...

viewer, developer, deployer permissions on vue-js-scaffolder-test.

Done!

Now, logging in as devcity-bruno...

we see the expected permissions on the application.

The application has three components.

The first component inherits the application permissions.

Note that there are no deployer permissions because those do not apply to components.

The same applies to the second component...

and to the third component.

As admin, let's explicitly remove all permissions on the third component.

Note the new row with zero permissions set (all permissions disabled).

Logging in as devcity-bruno, the third component is no longer visible...

devcity-bruno no longer has viewer permissions!

As admin, let's update the permissions of devcity-bruno on the application.

The first component inherits the permissions from the application.

The second component inherits the permissions from the application.

The third component does not inherit the newly set permissions on the application.

The third component keeps its previously set permissions.

As admin, let's grant viewer permissions to devcity-bruno on the third component.

Logging in as devcity-bruno, the third component is now visible!

Once again, devcity-bruno only has the permissions on the component...

that have been explicitly set on it (viewer).

In other words, in the absence of explicit permissions on components,

users inherit permissions from the parent application.

In the presence of explicit permissions on components, only those apply on the components.

1 / 27

Permission inheritance between application and components

Inherited permissions can be individually overridden:

• The user who created the demo app gets admin permissions for demo. That user can downgrade after the fact his permissions to developer and viewer only. Beware that a user who revokes his permission's editor permission may no longer be able to edit his permissions or grant permissions to other users.
• Let's consider a user who is granted viewer permissions on the demo app which consists of 3 components (front-end, back-end, API). Given that he had no permissions previously set on any of the 3 components, the user has viewer permissions on every component of demo. Then, permissions can be edited after the fact for each component (e.g., viewer permissions can be removed on the API component for specific users, while keeping the other two components' permissions intact).

devcity-bruno was automatically granted viewer and developer permissions on this component.

Let's revoke the developer permission on the component.

Let's revoke the developer permission on the component.

Let's revoke the developer permission on the component.

Let's revoke the developer permission on the component.

The permission group for the component is now updated.

devcity-bruno now only has viewer permissions on the component.

He can not build the component without developer permissions.

1 / 8

Automatically granted permissions can be overridden individually

The default inheritance mechanism makes easy workflows where the team working on an application may be called to work on any/all of the application components. On the other hand, workflows where specific components have restricted (or extended) access remains possible.

Permission composition

Permissions are additive. Users may be granted a set of permissions by several sources. In such a case, what is the resulting set of permissions? Permissions set are combined through a set union operation.

• From the previous illustration, we can see that the absence of admin permission granted through membership of My-team does not impede the user from receiving admin permission through the user alexsandman. The two sets of permissions are merged into the set displayed in the top row.

• Alternatively, if the following user sees his admin role revoked (first set, see illustration below), he will remain a viewer (second set):

What permissions do I need to perform this operation?

The following table details the minimum permissions necessary to perform an operation. Keep in mind however that, as explained above, the admin permission on a resource type allows performing operations enabled by all the other permissions on the resource type. Similarly, users with the admin role can do anything that users with the user role can do.

Use the input filter below to narrow down operations or permissions. Click on any column to sort its contents.

×

10 per page20 per page30 per page50 per page

98 records

Operation	Min. Role	Cluster	Environment	Application	Component	Service	Library
See Applications	User			Viewer
See Libraries	User						Viewer
See Managed Services	User					Viewer
See Builds Overview	User			Viewer
See Deployments Overview	User			Viewer
See Documentation	User			Viewer
See Logging - Discover	User	Viewer
See Tracing - Search	User	Viewer
See Service Mesh - Overview	User	Viewer
See Service Mesh - Graph	User	Viewer

Tips

• Create and assign permissions to teams. Every user added to the team team member will automatically be granted the permission set of the team he belongs to. Good usage of team permissions avoids granting permissions one by one to users, saves time, and is less prone to errors.
• Beware that users with permission's editor can promote themselves to admin, thus considerably extending the set of operations they can perform on the resource (e.g., delete the resource). Grant the permission wisely.
• Every resource type (Cluster, Environment, Application, Service) can be set as favorite by clicking on the star next to its name.
• favorite resources always appear on top