Role-Based Access Control (RBAC)¶
Note
For more information about managing users, see User Management.
RBAC Overview¶
Role-based access control (RBAC) allows administrators to restrict read and write access to key parts of Fugue, such as:
Viewing or configuring environments
Accessing compliance, drift, enforcement, or baseline data
Accessing the visualizer
Managing users, groups, custom rules, and API clients
Managing notifications
Running scans
And more
RBAC promotes the principle of least privilege. It’s a security best practice to only give admin access to users who need it, and to limit other users from having unnecessary access to environments and actions.
You can manage RBAC from the Groups page:

For more details, see The Groups Page.
Note
RBAC is a Fugue Team and Fugue Enterprise feature.
Groups, Policies, Users¶
Note
If an admin creates a new environment, they need to assign the environment to a group so users in that group can access it. See How to Edit Groups.
Three key concepts in RBAC are groups, policies, and users.
A group represents a set of environments that users can access. Each group is associated with a single policy, which defines the actions that users can take in Fugue. Each user belongs to one or more groups and inherits the policies of each group.
You can view RBAC groups on the Groups page and users on the Users page.
By default, each organization starts with one group and one user – the Admin group and account owner. The user who created the organization is the account owner.
Users in the Admin group can create other groups, invite users, and assign/reassign users to groups on an individual basis.
How Access is Restricted¶
Users can only access the environments their groups explicitly allow them to access. If a user isn’t granted access to an environment, they can’t see it, take action on it, or configure organization-level settings for it.
For example, Editors can’t view or edit notifications associated with environments they don’t have access to. Likewise, Contributors can only waive rule results in environments they can see.
The Environment Overview page only displays accessible environments, and users will see an error message if they attempt to access an environment via direct URL.
Types of Policies¶
Currently, Fugue supports five policies. In order from least privileged to most privileged:
The Admin group has the Admin policy, which cannot be changed. Any other group may be given any policy. To learn more about each policy, see Policy Permissions.
Read Only Policy¶
A Read Only policy grants a user read-only access to a group’s environments. Users cannot view environments the group doesn’t grant access to, and they can’t perform write actions on any environment. (The exception is if they also belong to a group that grants other permissions. See our note here.)
For example, Alice Admin creates a group called Staging
. The group is associated with the Read Only policy and enables access to two environments, Web Us-east-1
and Web Us-west-2
. Alice assigns the user Bob to Staging
, which allows Bob to view only those two environments. Bob cannot edit environment settings, enable/disable enforcement, manage users, and so on; he can only view the environments.
The Read Only policy is most useful for users who only need to view compliance data and don’t need to scan or perform write actions on environments.
Users with a Read Only policy can configure one-time and scheduled emails for organization-level reports on the Reports page, but only for the environments they can access.
See Policy Permissions for a detailed list of Read Only permissions.
Auditor Policy¶
An Auditor policy grants all the same permissions as a Read Only policy, but also allows the user to run scans and configure notifications.
The Auditor policy is ideal for compliance analysts who don’t necessarily need write access to environments.
See Policy Permissions for a detailed list of Auditor permissions.
Editor Policy¶
An Editor policy grants all the same permissions as an Auditor policy, but also allows a user to configure environment settings such as scanned resource types, drift detection, baseline enforcement, etc.
The Editor policy is ideal for users who need to edit environments, but not create or delete them.
See Policy Permissions for a detailed list of Editor permissions.
Contributor Policy¶
A Contributor grants all the same permissions as an Editor policy, but also allows users to create environments, configure custom rules, and manage rule waivers.
The Contributor policy is useful for non-admin users who require more privileges, such as for managing rules and waivers.
See Policy Permissions for a detailed list of Contributor permissions.
Admin Policy¶
An Admin policy grants a user read and write access to all environments and all organization settings. It’s associated with the Admin group, the default group in Fugue. No other group can use the Admin policy.
Administrators can create groups and grant permissions to that group determine the actions, pages, and environments that users can view, access, or edit within Fugue.
The Admin policy cannot be modified, but users in the Admin group can be moved to another group – except the account owner, who cannot be reassigned. To change the account owner, contact support@fugue.co.
See Policy Permissions for a detailed list of Admin permissions.
Policy Permissions¶
Feature |
Read |
Auditor |
Editor |
Contributor |
Admin |
---|---|---|---|---|---|
Environment-Level Settings |
|||||
Configure environment settings |
X |
X |
X |
||
Enable/disable drift and/or enforcement |
X |
X |
X |
||
Run scans (UI, API) or change scan interval (API only) |
X |
X |
X |
X |
|
Create environments |
X |
X |
|||
Delete environments |
X |
||||
Organization-Level Settings |
|||||
Configure notifications |
X |
X |
X |
X |
|
Export data |
X |
X |
X |
X |
X |
View and configure reports |
X |
X |
X |
X |
X |
Create/update/delete custom rules |
X |
X |
|||
Create/update/delete users with respective groups |
X |
||||
Configure API clients |
X |
||||
Configure rule waivers |
X |
X |
|||
Enable and disable rules |
X |
Permissions for Users in Multiple Groups¶
When a user is in more than one group, the permissions are combined in this way:
Environments:
The user is given access to all environments in a group according to the policy of that group.
If an environment is in multiple groups, the user can access it at the most permissive level granted.
Organizational settings:
A user has access to organization-level settings according to the most permissive level granted.
For example, suppose you have two groups:
The Read Only Group has the Read Only policy and allows access to Environment A and Environment B.
The Contributor Group has the Contributor policy and allows access to Environment B and Environment C.
A user in both groups has the following access:
Read Only access to Environment A
Contributor access to Environment B (because the highest level of permission takes effect)
Contributor access to Environment C
Contributor access to organization-level settings (e.g., the Custom Rules page)
As a general rule of thumb, the highest level of permissions granted takes effect.
Getting Started with RBAC¶
The admin should create one or more groups with non-Admin policies to limit what actions users can take and what environment(s) they can view within Fugue.
Here are the basics of RBAC with Fugue:
Create a group to enable access to one or more environments.
Assign existing users or new users to a group.
Optionally, edit a group by changing the environments associated with it.
Delete a group if needed.
Note
The Fugue API does not currently support RBAC or user management.
The Groups Page¶
The Groups page lists the name, policy, and environment(s) associated with each group:

You can hover over the i
symbol next to the number of environments in a group to see the environment names:

You can also select the ellipsis ...
to edit a group.
You can sort the table by group name or policy, in alphabetical or reverse alphabetical order. By default, groups are sorted by name in alphabetical order.
The active sorted category shows a single arrow. Select the arrow to reverse the direction.

The inactive category shows a double arrow. Select the double arrow to make it active.

If you have more than 10 groups, you’ll see a dropdown menu below the table of groups. You can choose to show 10, 20, 50, or 100 rows per page:

How to Create a Group¶
There are two steps to creating a group:
Step 1: Definition¶
Navigate to Organization > Groups.
Click the Create New Group button.
Enter a name for your group.
In the Policy drop-down, select the policy to be associated with the group.

Step 2: Environments¶
Select the environments this group can access. You can search by environment name, environment ID, or cloud provider. Multiple search terms are supported – just use the
Tab
key after each term. UseEnter
to search.Click Create Group.
Note
If you create new environments, you will need to update this group to include those environments if you want this group to access them.
Additionally, if you do not create any groups, all users will belong to the Admin group and they will have global access to everything within Fugue.

How to Assign Existing Users to Groups¶
Navigate to Organization > Users.

2. In the user row, select the ellipsis icon ...
and choose Edit User.

3. Select the group(s) you want the user to belong to.

4. Click Update User.
How to Invite and Assign New Users to Groups¶
Navigate to Organization > Users.
Click the Invite New User button.
Select the group(s) you want the user to belong to.

4. Click Send Invitation Email.
See User Management for more information on inviting and managing users.
How to Edit Existing Groups¶
Navigate to Organization > Groups.
In the group row, select the ellipsis icon
...
and choose Edit Group.

3. Select the environments this group can access.

4. Click Update Group.
Note
If you create new environments, you will need to update this group to include those environments if you want this group to access them.
How to Delete Groups¶
Navigate to Organization > Groups.
In the group row, select the ellipsis icon
...
and choose Delete Group.

3. Select Delete Group.

Note
A group cannot be deleted if one or more users belong to it. You must first move each user to a different group. Otherwise, you’ll see an “Unable to Delete Group” error:
Unable to Delete Group
Please reassign {user name} to a different group to delete this group. Go to Users
More About User Management¶
For more information about managing users, see User Management.