Access control

OpsNexus denies by default. A person can only open a page or call an API endpoint when one of their roles grants at least the level that page needs. Access is managed in two places:

• Settings → Access control holds people, organization roles and teams. It has three tabs: Users, Roles & permissions and Teams & groups.
• Settings → Projects holds project membership. Inside a project, a project role decides what someone can do with that project's pipelines, agents, secrets and other work.

#How permissions work

#Modules and levels

Every permission is a pair: a module and a level. A role maps each module to one level.

Levels are ordered. full includes modify, and modify includes read.

#Module reference

These are the modules a role can grant, with the label shown in the permission matrix.

#Organization roles and project roles

The modules split into two groups:

• Project modules: pipelines, integrations, agents, secrets, artifacts, cloud, marketplace, monitoring, notifications, domains and security. Their data lives in a project. Inside a project, your level for these modules comes from your project role, not from your organization role.
• Organization modules: dashboards, access_control, settings, backup and audit. Your level always comes from your organization role.

Your organization role still matters for project modules in one case: items shared with every project (shared credentials, variables, agents, notification channels and plugins) belong to the organization. Changing them needs the level in your organization role.

#Combining roles

A person can hold several roles at once: their own role, plus the role of each team or group they belong to. For each module, OpsNexus uses the highest level from any of these roles. The same rule applies to project memberships: direct and team memberships add up, and each module gets the highest level any of them grants.

#Organization admins and super admins

• Super admin is a flag on a user account, not a role. The first admin created at install time is a super admin. Super admins have full access to every module and are the only users who can manage platform backups.
• Organization admin means a super admin, or anyone whose roles give full on Users, roles & teams. Organization admins are admins of every project, and can delete projects.

#Built-in roles

Every organization starts with five built-in roles. You can't delete them. You can change the permissions and description of every built-in role except Organization Admin, which always has full access.

Remember that project modules follow the project role inside a project. The organization role values above apply to organization modules and to shared items.

#Users

#Add a user

You need Read & modify on Users, roles & teams.

1. Open Settings → Access control and stay on the Users tab.
2. Select Add user.
3. Fill in Email, Username (letters, numbers, dots, dashes) and Full name.
4. Pick a Role, or leave No role.
5. Choose how they sign in under Signs in with: Password, Google SSO or Microsoft SSO.
6. For Password, set an Initial password. It must meet the organization's password policy.
7. Optionally fill in the Profile fields. The user can change them later under Settings → My profile.
8. Select Add user.

Emails are unique across the whole platform. Usernames are unique within the organization. OpsNexus doesn't send invitation emails, so share the sign-in details with the person yourself. SSO users must be added here before they can sign in. See Password, MFA & SSO.

#The users table

The tiles at the top count users, active users, users with MFA enabled and locked-out users. The table shows each person's role, projects, sign-in method, MFA state, last login and status. Use the search box to filter by name, email or username.

From a row you can:

• Change the role with the role drop-down.
• Projects: see and set the person's project access.
• Profile: edit their name, job title and other profile fields.
• Unlock: clear a lockout after too many failed sign-ins.
• Deactivate or Activate the account.
• Delete the user (needs Full access on Users, roles & teams).

#Deactivate or delete a user

Deactivate blocks sign-in and signs the person out of every session at once. Their account and history stay, and you can activate them again later.

Delete removes access immediately. The account is soft-deleted, so the audit history that names them is kept.

You can't deactivate or delete your own account.

#Roles & permissions

The Roles & permissions tab lists roles on the left and the permission matrix of the selected role on the right. Each row is a module, and each column is a level.

To create a custom role:

1. Type a name in New role name and select Add. The new role starts with No access on every module.
2. Select a level for each module.
3. Select Save permissions.

Changes apply on each user's next request. Creating, editing and deleting roles needs Full access on Users, roles & teams. Every change is written to the audit log as role.permission.update with a before and after value per module.

You can't delete a role while users are assigned to it. Move them to another role first.

#Custom actions

A module set to Custom uses the role's list of fine-grained actions, written as module:action, for example pipelines:trigger. A module with at least one custom action counts as Read only for page access. The permission matrix sets levels only. Custom action lists are part of the role in the API (PUT /api/roles/{id}, field custom_actions).

#Teams & groups

A team or group gives all its members a role in one place. Members get the team's role in addition to their own.

To create one:

1. Open the Teams & groups tab and select Add team or group.
2. Enter a Name and choose a Type: Team or Group. Both work the same way.
3. Pick a Role for members, or No extra role.
4. Tick the Members.
5. Select Save.

Deleting a team removes it, and its members keep their accounts. Teams can also be added to projects as a whole (see below).

#Project access

Projects keep work apart inside the organization. Each project has its own pipelines, builds, integrations, private agents and private secrets. People only see the projects they are members of, directly or through a team.

#Project roles

A project member with a custom role where every module is No access can't open the project.

#Add someone to a project

1. Open Settings → Projects and select Members on the project.
2. Pick a person or a team, and a Role.
3. Add them.

You can also set a person's project access from Access control → Users → Projects. That dialog shows their direct role in each project, any roles they get through a team, and the effective result. Changing it needs Read & modify on Users, roles & teams.

People without any project see a message asking them to contact an organization admin.

#Related pages

• Password, MFA & SSO
• Secrets & variables
• Audit logs
• Concepts