Role-Based Access Control

CodeNOW's role-based access control (RBAC) system grants users appropriate permissions for specific resources. RBAC ensures that development team members can only access information and perform actions required for their job responsibilities. This access control is crucial for software development project security and minimizes 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 through the self-service portal (SSP), CLI, external administration tools, or code repositories. Users execute operations to view, edit, update, access, use, and delete resources within their software development projects.

Each resource has permissions that control which operations users can perform with that resource. Users must obtain the necessary permissions before executing any operation on a resource. CodeNOW's permission model includes 3 roles, 7 resource types, and specific permissions for each resource type that enable particular 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

Users with the owner role have complete access to all CodeNOW features and permissions by default. Only other owners can revoke the owner role. Owners can promote user role members to admin role and admin role members to owner role.

Owners differ from admins because they can perform operations that affect the entire CodeNOW account. The buyer of the CodeNOW subscription typically becomes the first user and receives owner permissions. The following operations are exclusive to users with owner role:

• Request new cluster
• Delete cluster

Admin

Users with admin role have all permissions available to user role members. Additionally, admins can create teams, invite users to the SSP, and assign users to teams. Admins can promote standard users to admin role and downgrade other admin users to user role.

Due to these extensive permissions, the admin role suits users with management responsibilities in software projects (e.g., tech lead, team lead, project manager, product manager, CTO). The following operations are available only to users with admin role and above:

• 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

All invited users receive the user role by default. When invited users accept their invitation, they initially have no permissions on existing resources except access to the SSP platform itself. New users can perform basic SSP operations like creating new applications.

To work with existing resources (such as previously created applications), new users must receive appropriate permissions from admins or resource owners. The user role fits development team members who focus on coding rather than management activities. Users with user role can perform the following operations when granted 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	Grants all other permissions for the resource automatically. Users with admin permissions can perform all operations available to deployer, viewer, and permission's editor roles. Admin users can also delete the associated resource.
permission's editor	C-U-	Allows users to update their own permissions 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. Users with operator permissions on a Postgres managed service can log into pgAdmin to create tables, run queries, and add triggers. They can also edit deployment configurations for database instances (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

CodeNOW's RBAC includes a permission inheritance mechanism that automatically grants permissions in specific contexts to streamline common workflows:

• Users who create a resource automatically receive admin permissions for that resource. This allows them to grant permissions to other users and delete the resource when necessary.
• Component permissions inherit from their parent application by default:
  • When no explicit permissions are set on components, users inherit the same permissions they have on the parent application.
  • When explicit permissions are set on components, only those explicit permissions 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

Users can override inherited permissions individually:

• Users who create the demo app receive admin permissions for demo. These users can later downgrade their permissions to developer and viewer only. Note that users who revoke their permission's editor permission may lose the ability to edit permissions or grant permissions to other users.
• Consider a user granted viewer permissions on the demo app, which contains 3 components (front-end, back-end, API). Since no permissions were previously set on the components, the user inherits viewer permissions on all components of demo. Administrators can then modify permissions for each component individually (e.g., remove viewer permissions on the API component while maintaining permissions on the other components).

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 simplifies workflows where teams work on applications and may need access to any or all application components. Workflows requiring restricted or extended access to specific components remain possible.

Permission composition

Permissions are additive. Users can receive permissions from multiple sources. When this occurs, CodeNOW combines all permission sets through a union operation.

• The previous illustration shows that lacking admin permission from My-team membership does not prevent the user from receiving admin permission from user alexsandman. CodeNOW merges both permission sets into the combined set shown in the top row.

• If a user's admin role is revoked (first set, see illustration below), they retain viewer permissions (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. Users added to teams automatically receive the team's permission set. Using team permissions effectively avoids granting individual user permissions, saves time, and reduces errors.
• Users with permission's editor can promote themselves to admin, significantly expanding their operational capabilities on resources (including deletion rights). Grant this permission carefully.
• Mark any resource type (Cluster, Environment, Application, Service) as favorite by clicking the star next to its name.
• Favorite resources always appear at the top of lists.