Role-Based Access Control (RBAC) is designed to support enterprises consisting of multiple teams working on different projects, with different sets of system resources.

RBAC allows system administrators (users with the predefined Administrator role) to precisely control, for all users, which system resources the user can edit (create, modify, and delete); view; or not access at all.

RBAC includes the functionality of users, groups, roles, permission sets, and application scopes.

RBAC concepts

RBAC is based on a few fundamental concepts. These concepts and their interrelationships are depicted in this diagram and explained in the text that follows.

Top-level view

  • Each user is assigned one or more roles.
  • The permission set(s) associated with the role(s) determine the types of system resources the user is allowed to edit or view.
  • The application scope(s) associated with the role(s) determine the specific resources the user is allowed to edit or view.


User login and authentication are required for all Aqua functionality, whether performed in the UI (console), by using the REST APIs, or by using the command line (e.g., for the Scanner). For a detailed explanation about users and their types, see Users.


You can create groups to manage users. For further information, see Groups.


A role is a combination of one permission set and one or more application scopes.

Each user can be assigned one or more roles. In the diagram above, User_A has a single role (Role_1), User_B has two (Role_2 and Role_3), and User_C also has two (Role_3 and Role_4).

Users with multiple roles receive the combined privileges of all the roles. See Effects of RBAC.

Permission sets

As shown in the above diagram, each role must be associated with a single permission set. A permission set defines, for all users assigned to the role, whether specific types of Aqua resources can be accessed in Edit mode, in View Only mode, or not at all.

In addition, a permission set defines whether these users can access these types of resources from both the UI and APIs or only from the APIs. Access to command-line execution is determined by certain resource types.

See Permission Set Operations for managing permission set(s) in the Account Management page.


Approximately 25 types of resources are predefined in Aqua, to provide system administrators with highly granular control. The resources are grouped into categories: Policies, Assets, Compliance, and System.

Edit mode, View Only mode, and Not Set

Edit mode allows the creation, modification, and deletion of resources. View Only mode allows only displaying information about the resources.

The UI designation Not Set means that users do not have any kind of visibility to the related types of resources. Such resources will not even appear in the UI and, where possible, related menu items will be hidden.

Note that Edit mode is not available for types of resources that only display information (e.g., Risk Explorer, Containers, Audit Events, and Incidents).


The Policies category includes five types of resources. A permission set can therefore be defined to allow certain users to do the following:

  • Create Assurance Policies
  • View (but not create) Image Profiles and Runtime Policies
  • Not even view Firewall Policies or Response Policies

Multiple roles

Users with multiple roles receive the combined privileges of all permission sets associated with those roles. See Effects of RBAC.

Application scopes

In conjunction with permission sets, an application scope defines the specific system resources that can be accessed (viewed or edited) by users with the associated role(s).

An application scope consists of zero or more specifiers for resources in these categories: Artifacts (of applications), Workloads (containers), and Infrastructure (elements). Each of the categories is subdivided into more granular types. For example:

  • Images (under Artifacts)
  • Kubernetes (under Workloads)
  • Hosts (under Infrastructure)

The specifiers define the subset of resources that can be accessed (depending on the user's permission set(s)). The specification is expressed in terms of predefined attributes, in a manner that is similar to the definition of policy scopes.


An application scope can include all image registries whose name includes nginx, and all hosts (VMs) whose Aqua Enforcer group is group_10.

Multiple roles

Users with multiple roles receive the combined privileges of all application scopes associated with those roles. See Effects of RBAC.

The Global application scope

The predefined Global application scope includes all types of artifacts, workloads, and infrastructure elements.