Aqua Security’s Role-Based Access Control (RBAC) is how you grant specific permissions to users and groups, ensuring they can only access and manage what they’re authorized for.
Let’s see it in action. Imagine you have a team of developers who only need to scan container images for vulnerabilities, but shouldn’t be able to deploy them or manage Aqua’s policies. Here’s how you’d set that up:
First, you’d create a new Role in Aqua. Let’s call it ImageScanner.
Navigate to Settings -> Access Control -> Roles. Click Add Role.
Under Role Name, enter ImageScanner.
Now, you need to define the permissions for this role. In the Permissions section, you’ll see a list of capabilities. For our ImageScanner role, we’d grant the following:
- Images:
View ImagesScan Images
- Vulnerabilities:
View VulnerabilitiesView Vulnerability Details
Crucially, you would not grant permissions like Manage Policies, Deploy Images, or Manage Users.
Once the role is created, you can assign it to users or groups. If you have an Active Directory or LDAP integration configured, you can assign this role to a specific AD group, say aqua-scanners. When users from that AD group log into Aqua, they will automatically inherit the ImageScanner role and its associated permissions.
If you’re managing users directly within Aqua, you’d go to Settings -> Access Control -> Users, select the user, and under Roles, add ImageScanner.
This granular control is the core of Aqua’s RBAC. It allows you to enforce the principle of least privilege, significantly reducing the risk of accidental misconfigurations or malicious actions. You can create roles for auditors, security analysts, DevOps engineers, and even specific project teams, each with precisely tailored access.
The system models permissions as a hierarchy. A Tenant Admin role has the broadest access, capable of managing all aspects of Aqua, including users, roles, and policies. More specialized roles inherit subsets of these permissions. When you grant a permission, you’re essentially saying "this role can perform this action on this resource type." The Resource Types are things like Images, Vulnerabilities, Policies, Audit Logs, Users, etc.
The most surprising thing about RBAC in Aqua is that when you grant a permission at a higher scope (like Global), it implicitly grants that permission at all lower scopes (like Projects) unless explicitly overridden by a more restrictive role assignment. This means a Global permission is very powerful, and you should be judicious when assigning roles with global access.
Understanding the scope of permissions is key. A role assigned at the Global level applies across your entire Aqua environment. However, you can also scope roles to specific Projects. For example, a Developer role might have Scan Images permission at the Global level, but only Deploy Images permission for a specific Project named frontend-app. This allows for very fine-grained control tailored to organizational structures and responsibilities.
The next concept you’ll likely encounter is integrating Aqua’s RBAC with external identity providers like Active Directory or Okta for centralized user management.