Granular Role-Based Access Controls Per Field
Overview
Avi Vantage provides Role Based Access Control (RBAC) to provide granular access to control, manage and monitor applications within Avi Vantage.
Starting from Avi Vantage version 20.1.2, labels are used as filters to enforce access control over individual objects. This model allows providing read or write access to a given resource. To know more on how RBAC is applied per object, refer to the Granular RBAC article.
Starting with Avi Vantage 20.1.5, RBAC can be implemented at a field-level. This article covers the use of sub-resources to implement RBAC per field.
Granular RBAC per-Field
Using Granular RBAC per Field, users can be allowed to update an object but restrict the updates to a specific set of fields.
For example, allow users to:
- Enable/ disable GSLB service groups, but restrict updating any other fields in the GSLB object
- Enable/ disable a virtual service, but restrict updating any other virtual service configuration
- Add/ remove/ update the pool servers, but restrict updating any other pool configuration
Sub-resources
To implement per-field RBAC, sub-resources for the existing resources are introduced. These sub-resources are associated with a specific field, feature, or a set of fields within the object. When a sub-resource is configured on a resource with write access, it will allow update to the object only if those sub-resources are the only fields updated. Read will be allowed for the full object, but delete, and create will not be allowed from that permission. Sub-resources can be combined to allow users to configure multiple fields/features in an object.
To define access for sub-resources, the flags allow edit to only [subresource(s)] and allow edit of entire object except for [subresource(s)] are introduced.
For example, to configure a role with sub-resources,
[admin:10]: > configure role Pool-Enabled-Role
[admin:10]: role> privileges
New object being created
[admin:10]: role:privileges> type write_access
[admin:10]: role:privileges> resource permission_pool
[admin:10]: role:privileges> subresource
[admin:10]: role:privileges:subresource> subresources subresource_pool_enabled
[admin:10]: role:privileges:subresource> save
[admin:10]: role:privileges> save
[admin:10]: role> save
The pool is configured as shown below:
+--------------------------+-------------------------------------------+
| Field | Value |
+--------------------------+-------------------------------------------+
| uuid | role-c5d28445-995c-44b8-9677-610bb20cb2e7 |
| name | Pool-Enabled-Role |
| privileges[1] | |
| type | WRITE_ACCESS |
| resource | PERMISSION_POOL |
| subresource | |
| exclude_subresources | False |
| subresources[1] | SUBRESOURCE_POOL_ENABLED |
| tenant_ref | admin |
+--------------------------+-------------------------------------------+
Sub-resources enabled the user to do execute a specific function within the object.
All available sub-resources are listed below:
| Sub-reource | Function |
|---|---|
| SUBRESOURCE_POOL_ENABLED | Add/ update/ disable pool servers |
| SUBRESOURCE_POOL_SERVERS | Add/ update/ remove pool servers |
| SUBRESOURCE_POOL_SERVER_ENABLED | Enable/ disable pool servers |
| SUBRESOURCE_VIRTUALSERVICE_ENABLED | Enable/disable virtual servers |
| SUBRESOURCE_GSLBSERVICE_ENABLED | Enable/disable GSLB service objects |
| SUBRESOURCE_GSLBSERVICE_GROUPS | Update GSLBservice groups |
| SUBRESOURCE_GSLBSERVICE_GROUPS_ENABLED | Enable/ disable GSLBservice groups |
| SUBRESOURCE_GSLBSERVICE_GROUP_MEMBERS | Update GSLBservice group members |
| SUBRESOURCE_GSLBSERVICE_GROUP_MEMBER_ENABLED | Enable/ disable GSLBservice group members |
Document Revision History
| Date | Change Summary |
|---|---|
| April 15, 2020 | Published the article for Granualar RBAC Per Field (Version 20.1.5) |