Use role-based access control

You can manage the permissions of your team members using role-based access control (RBAC). These roles define the resources that your team members can view and edit in the Northflank UI and via the API.

RBAC roles control both UI and API access. API tokens are generated from RBAC roles and inherit their permissions.

Roles can be given specific permissions based on CRUD operations for the different Northflank resources such as projects, services, jobs, pipelines and addons. Roles can also be restricted to certain projects, and be given permissions to manage aspects of the team itself.

You can use an organisation to create and manage roles across teams, and to manage organisation permissions.

Owner

When you create a team you are given the role of owner which grants all permissions across the entire team account. The owner cannot be removed from the team, you must transfer the owner role to another user before leaving the team.

Admin

The default admin role grants a user full permissions across the team to create, read, update, and delete resources and modify team settings. You should check and modify the permissions granted by the admin role when you create your team.

Default

When you invite a user to a team they are automatically assigned the default role which permits limited access to create, read, and update resources, but not to delete them, and only access to view team settings. You should check and modify the permissions granted by the default role when you create your team.

Permissions are marked with indicators that show their access level and capabilities:

Permissions can have multiple indicators. For example, a permission with both UI and ⚠️ is UI-only and is a sensitive permission.

The team owner and any role with permissions, such as the admin role, can create and modify roles in the team's account settings.

You can select members to be assigned to the role immediately, or grant the role to members later.

Project restrictions limit a role’s permissions to specific projects.

You can use exclusion rules to remove access to specific projects rather than granting access to specific projects. This switches from an "in" to "notIn" rule. Enable Use as exclusion rule when configuring project restrictions.

Roles can be assigned to team members by editing the role in the team's account settings and selecting members from the drop-down list. Roles can be removed from members by deleting them from the list.

You can also add and remove roles from a member from the members page in the team's account settings and opening the role selector for that member. You can add and remove roles from invited users that have not yet been added to the team here as well.

You can manage user roles on an organisational level to ensure compliance with your security policies.

Directory groups

If you have enabled directory sync, you can select directory groups to associate with the role. Users in the directory groups will be assigned the role, and the role will be removed from users if they are removed from the directory group.

Organisation permissions

You can grant roles permissions to create and manage teams, and to manage organisational settings.

Team and project restrictions

Restricting the role to specific teams will allow organisation users with the role to only view and interact with the teams their roles grant them permission for, with the corresponding team permissions for those roles.

You can also further restrict roles to specific projects within teams, by expanding the entry for selected teams.

Team permissions

You can configure the permissions that the role grants users to manage team configuration and resources, such as team members, domains, and cloud provider integrations.

Project permissions

You can configure the project-level permissions that users with this role have, which will apply in the teams that the role has access to. This allows you to manage project permissions on the organisational level, rather than through individual team roles.