Role-Based Access Control (RBAC)

Note

For more information about managing users, see User Management. For more information about creating and editing API Clients see How to Use the API.

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:

_images/rbac-groups-list-1.png

For more details, see The Groups Page.

Note

RBAC is a Fugue paid plan feature.

Groups, Policies, Users

Note

If an admin creates a new environment, they need to assign the environment to a group so users or API Clients in that group can access it. See How to Edit Groups.

Three key concepts in RBAC are groups, policies, and users/API Clients.

A group represents a set of environments that users or API Clients can access. Each group is associated with a single policy, which defines the actions that users or API Clients can take in Fugue. Each user or API Client belongs to one or more groups and inherits the policies of each group.

You can view RBAC groups on the Groups page, users on the Users page, API Clients on the API Clients page.

By default, each tenant starts with one group and one user – the Admin group and account owner. The user who created the tenant is the account owner.

How Access is Restricted

Users and API Clients can only access the environments their groups explicitly allow them to access. If a user or an API Client isn’t granted access to an environment, they can’t see it, take action on it, or configure tenant-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.

The GET /environments endpoint only returns accessible environments.

See this note for information about how permissions are handled when a user or an API Client belongs to multiple groups.

Types of Policies

Fugue supports the following policies:

The Admin group has the Admin policy, which cannot be changed. Any other group may be given any policy except Admin. The Admin policy is a Fugue out-of-box policy. To learn more about each policy, see Policy Permissions.

Organization Report Viewer

An Organization Report Viewer grants users access to the tenant and organization-level reports in the root tenant. This policy only displays in the root tenant for an organization. Refer to Organizations for more information.

The Organization Report Viewer policy is useful for non-admin users who want to view root tenant and organization-level reports.

See Policy Permissions for a detailed list of Organization Report Viewer permissions.

See also our note about belonging to multiple groups.

IaC Scanner Policy

The IaC Scanner policy grants a user or API Client 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 except kicking off a scan. (The exception is if they also belong to a group that grants other permissions. See our note here.)

One use case is to use the IaC Scanner policy for kicking off a scan and uploading the results for Fugue Repository environments using regula run --sync --upload.

An IaC Scanner policy grants a user or an API Client:

  • Read-only access to a group’s environments

  • Write permissions to kick off a scan

  • Upload those results to the Fugue Saas (using regula run --sync --upload)

  • Read-only access to view rules, families, and reports

See Policy Permissions for a detailed list of IaC Scanner permissions.

See also our note about belonging to multiple groups.

Read Only Policy

A Read Only policy grants a user or API Client 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 or API Clients 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 tenant-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.

See also our note about belonging to multiple groups.

Auditor Policy

An Auditor policy grants all the same permissions as a Read Only policy, but also allows the user or API Client to run scans and configure notifications.

The Auditor policy is ideal for compliance analysts or API Clients who don’t necessarily need write access to environments.

See Policy Permissions for a detailed list of Auditor permissions.

See also our note about belonging to multiple groups.

Editor Policy

An Editor policy grants all the same permissions as an Auditor policy, but also allows a user or API Client to configure environment settings such as scanned resource types, drift detection, baseline enforcement, etc.

The Editor policy is ideal for users or API Clients who need to edit environments, but not create or delete them.

See Policy Permissions for a detailed list of Editor permissions.

See also our note about belonging to multiple groups.

Contributor Policy

A Contributor grants all the same permissions as an Editor policy, but also allows users or API Clients to create environments, configure custom rules, and manage rule waivers.

The Contributor policy is useful for non-admin users or API Clients who require more privileges, such as for managing rules and waivers.

See Policy Permissions for a detailed list of Contributor permissions.

See also our note about belonging to multiple groups.

Manager Policy

A Manager grants all the same permissions as a Contributor policy, but also allows users or API Clients to delete environments.

The Manager policy is useful for non-admin users or API Clients who require more privileges, such as deleting environments.

See Policy Permissions for a detailed list of Manager permissions.

See also our note about belonging to multiple groups.

Admin Policy

An Admin policy grants a user or API Client read and write access to all environments and all tenant 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 or API Clients 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.

RBAC Policy Permissions

Fugue supports assigning of RBAC Policies to groups, which can be assigned to users or API Clients.

UI Policy Permissions

Note

Scroll to the right to view the entire table.

Feature

Organization Report Viewer

IAC Scanner

Read

Auditor

Editor

Contributor

Manager

Admin

Environments

View Environments

X

X

X

X

X

X

X

Create Environments

X

X

X

Edit Environments

X

X

X

X

Delete Environments

X

X

Run Scans on an Environment

X

X

X

X

X

X

Reporting

View, Download, and Export Tenant Reports

X

X

X

X

X

X

X

X

Enable/Disable Compliance Report Emails

X

X

X

X

View, Download, and Export Organization-level Reports

X

X

Rules

View Rules Page

X

X

X

X

X

X

X

Create, Edit, and Delete Rules

X

X

X

Enable/Disable Rules

X

X

View Waivers

X

X

X

X

X

X

X

Create, Edit, Delete a Rule Waiver (One Environment)

X

X

X

Create, Edit, Delete a Rule Waiver (All Environments)

X

Create, Edit, and Delete Custom Rule Families

X

Families

View Families

X

X

X

X

X

X

X

Create, Edit, and Delete Families

X

Notifications

View Notifications

X

X

X

X

X

Create, Edit, and Delete Notifications

X

X

X

X

X

API Client, Group, and User Management

View Users/Groups/API Clients Pages

X

Create and Delete API Clients

X

Generate and Revoke API Client Secrets

X

Create, Edit, and Delete Groups

X

Create, Edit, and Delete Users

X

API Policy Permissions

Note

Scroll to the right to view the entire table.

Feature

Org Report Viewer

IAC Scanner

Read

Auditor

Editor

Contributor

Manager

Admin

Environments

GET /environments

X

X

X

X

X

X

X

GET /environments/:environment_id

X

X

X

X

X

X

X

POST /environments

X

X

X

PATCH /environments

X

X

X

X

DELETE /environments

X

X

Scans

GET /scans

X

X

X

X

X

X

X

GET /scans/:scan_id

X

X

X

X

X

X

X

GET /scans/:scan_id/compliance_by_rules

X

X

X

X

X

X

X

GET /scans/:scan_id/compliance_by_resource_types

X

X

X

X

X

X

X

POST /scans

X

X

X

X

X

X

Custom Rules

GET /rules

X

X

X

X

X

X

X

GET /rules/active

X

X

X

X

X

X

X

GET /rules/:rule_id

X

X

X

X

X

X

X

POST /rules

X

X

X

POST /rules/test

X

X

X

PATCH /rules/:rule_id

X

X

X

DELETE /rules/:rule_id

X

X

X

GET /rules/test/input

X

Families

GET /families

X

X

X

X

X

X

X

GET /families/:family_id

X

X

X

X

X

X

X

POST /families

X

PATCH /families/:family_id

X

DELETE /families/:family_id

X

Notifications

GET /notifications

X

X

X

X

X

POST /notifications

X

X

X

X

X

PUT /notifications/:notification_id

X

X

X

X

X

Delete /notifications/:notification_id

X

X

X

X

X

Waivers

GET /rule_waivers

X

X

X

X

X

GET /rule_waivers/:rule_waiver_id

X

X

X

X

X

POST /rule_waivers

X

X

X

PATCH /rule_waivers/:rule_waiver_id

X

X

X

DELETE /rule_waivers/:rule_waiver_id

X

X

X

Audit Log

GET /audit_log/events

X

Events

GET /events

X

X

User, Group, and Invite Management

GET /users

X

GET /users/:user_id

X

GET /groups

X

POST /groups/:group_ids

X

PATCH /users/:user_ids

X

GET /invites

X

GET /invites/:invite_id

X

POST /invites

X

Permissions for Users in Multiple Groups

When a user or an API Client is in more than one group, the permissions are combined in this way:

Environments:

  • The user or API Client 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 or API Client can access it at the most permissive level granted.

Tenant settings:

  • A user or an API Client has access to tenant-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 or an API Client 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 tenant-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:

The Groups Page

The Groups page lists the name, policy, and environment(s) associated with each group:

_images/rbac-groups-list-diagram-1.png

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

_images/rbac-hover-group-env.png

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.

_images/group-sort-name.png

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

_images/group-sort-policy.png

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:

_images/row-dropdown.png

How to Create a Group

There are two steps to creating a group:

  1. Define the group name and policy.

  2. Select environments the group can access.

Step 1: Definition

  1. Navigate to Settings > Groups.

  2. Click the Create New Group button.

  3. Enter a name for your group.

  4. In the Policy drop-down, select the policy to be associated with the group.

_images/create-group-name.png

Step 2: Environments

  1. Select the environments this group can access. You can select all environments (current or future) or you can search for specific environments by environment name, environment ID, or cloud provider. Multiple search terms are supported – just use the Tab key after each term. Use Enter to search.

  2. Click Create Group.

Note

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.

_images/rbac_environment_groups.png

How to Assign Existing Users to Groups

  1. Navigate to Settings > Users.

_images/rbac-user-list-1.png

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

_images/user-ellipsis-edit.png

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

_images/rbac-edit-user-groups.png

4. Click Update User.

How to Invite and Assign New Users to Groups

  1. Navigate to Settings > Users.

  2. Click the Invite New User button.

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

_images/rbac-invite-new-users.png

4. Click Send Invitation Email.

See User Management for more information on inviting and managing users.

How to Create an API Client and Assign it to Groups

  1. In the API Clients page (accessible from the Settings link at the top right of the UI), create a new API Client and give it a name.

2. Select the group(s) you want the API Client to belong to. For more information, refer to How to Create a Group.

_images/api_client_secret_create_rbac.png

3. Click Create API Client.

4. Copy the Client ID and Client Secret and store it securely.

_images/APIClientSecret.png

5. Use your preferred API tool to pass the Client ID and Secret in the Authorization HTTP header using Basic Auth.

_images/APIPostmanAuth.png

6. Send an API request to the appropriate endpoint including any required parameters.

_images/APIExampleRequest.png

How to Edit Existing Groups

  1. Navigate to Settings > Groups.

  2. In the group row, select the ellipsis icon ... and choose Edit Group.

_images/group-ellipsis-edit.png

3. Select the environments this group can access.

_images/rbac-select-envs.png

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

  1. Navigate to Settings > Groups.

  2. In the group row, select the ellipsis icon ... and choose Delete Group.

_images/group-ellipsis-delete.png

3. Select Delete Group.

_images/rbac-delete-group.png

Note

A group cannot be deleted if one or more users or API Clients belong to it. You must first move each user or API Client to a different group. Otherwise, you’ll see an “Unable to Delete Group” error:

Unable to Delete Group

Please reassign {user or API Client name} to a different group to delete this group. Go to Users Go to API Clients

More About User Management

For more information about managing users, see User Management.