Granular Role-Based Access Controls Using Labels

Overview

Modern applications are no longer monoliths but constitute many micro services. Users need more control over their applications including how they are deployed, how frequently they are accessed and who has access to parts of the applications.

Avi Vantage provides Role Based Access Control (RBAC) to provide granular access to control, manage and monitor applications within Avi Vantage.

A scenario where the application owners can change frequently requires the control to be passed between different users. Avi Vantage already provides such an isolation via tenants and roles.

In Avi Vantage version 18.2.x, access control is granted over types of objects (for example, user 1 has write access for all objects of type virtual service, pool, etc.) but not over individual objects of a given type like having only read access on object db-service-app of type virtual service.

Starting with Avi Vantage version 20.1.5, RBAC can be implemented at a field-level. Refer to the Granular RBAC Per Field article to know more.

Granular Role Based Access Controls per App

To avoid any functional disruption caused by moving an application from one tenant to another and to enhance the existing role framework, starting from Avi Vantage version 20.1.2, labels are used as filters to enforce access control over individual objects.
Labels are applied to individual objects to support access control in a decentralized manner.

RBAC

The bubbles in the image represent different Avi objects labelled red, blue, green, or yellow.

The user permissions for an Avi object at an application level are as follows:

User (Local)

  • Has the following permissions:
    • Write access to the virtual service (for the app labelled green)
    • Read access to the pool in the app prod (labelled yellow)
  • Does not have access to all apps labelled red and blue

User (Remote)

  • Has the following permissions:
    • Write access to the app labelled blue
    • Read access to the pool in the app prod (labelled yellow)
  • Does not have access to the apps labelled green and red.

Labels and Filters

In Avi, labels were inherently used to classify or group a collection of objects. The roles framework is extended to filter based on object labels as follows:

  1. Match one or more labels in the desired objects
  2. Role privileges apply to the objects that satisfy the filter specifications

Note: The labels framework is applicable only until Avi Vantage version 20.1.4. If you use Avi Vantage version 20.1.5, skip to the Extended Granular RBAC section.

Match Criteria

The following are the match criteria used to provide or restrict access to users roles:

Match Criteria Description Example
EQUALS If the object matches with the key and label of any of the key and value defined in the role or filter, the specified condition is true. 

          [{
            “match_criteria”: “EQUALS”,
            ”match_label”: {“key”: “app”, “values”: [“green”]},
            “enabled”: “true”,
            “name”: “green-app-read-only-profile-access-rule”
          }]

Here, the read only profile access for the green app is enabled only if the `key` = `app`, and `value` = `green`.
If there are multiple values defined in the object, when any of the values match with that of the role or filter, the specified condition is true.
DOES_NOT_EQUAL If none of the key(s) and value(s) match with that of the object’s, then the specified condition is true. 

        [{
           ”match_criteria”: “DOES_NOT_EQUAL”,
             “match_label”: {“key”: “department”, “values”: [“eng-dev”, “eng-test”]},
           “enabled”: “true”,
           “name”: “department-access-rule”
        }]

Here, the access is provided to all the departments except eng-dev and eng-test.
If there are multiple values defined in the object, none of the values should match with that of the role or filter, for the specified condition to be true.
GLOB_MATCH GLOB_MATCH allows you to filter values that:
- Begin with the specified criteria - (value*)
- End with the specified criteria
- (*value)
- Contains the criteria (*value*)
Note: Only alphanumeric characters and special characters are allowed.
 

{
     “name”: “demo-role”,
     ”privileges”: [{“type”: “WRITE_ACCESS”, “resource”: “PERMISSION_VIRTUALSERVICE”}],
     “filters”:  [{
           “match_criteria”: “GLOB_MATCH”,
             ”match_label”: {“key”: “app”, “values”: [“Blue* ”]},
           “enabled”: “true”,
           “name”: “demo-access-rule”
        }, {

Here, the demo access is enabled for all apps that begin with Blue. For example: Blueprint, Bluebells, Bluestone, etc. But does not include True blue or Robin Blue.
If there are multiple values defined in the object, when any of the values match with that of the role or filter, the specified condition is true.
GLOB_DOES_NOT_MATCH GLOB_DOES_NOT_MATCH allows you to filter values that do not: - Begin with the specified criteria - (value*)
- End with the specified criteria
- (*value)
- Contains the criteria (*value*)
Note: Only alphanumeric characters and special characters are allowed.
 

{
     “name”: “demo-role”,
     ”privileges”: [{“type”: “WRITE_ACCESS”, “resource”: “PERMISSION_VIRTUALSERVICE”}],
     “filters”:  [{
           “match_criteria”: “GLOB_Does_Not_MATCH”,
             ”match_label”: {“key”: “app”, “values”: [“*Blue ”]},
           “enabled”: “true”,
           “name”: “demo-access-rule”
        }, {

Here, the demo access is enabled for True Blue, Robin Blue but does not include Blueprint, Bluebells or Bluestone.
If there are multiple values defined in the object, none of the values should match with that of the role or filter, for the specified condition to be true.

Implementing Labels and Filters

A privilege comes with a resource and a permission.
A role can be granted the following permission types:

  • No Access
  • Read Access
  • Write Access

To understand the implementation of role-based access to apps via labels, consider the following example:

The virtual service VS-1 has the app Blue and the pool Pool-1 has the app Green.

A system-admin needs write access to both the apps, Blue and Green.

Note: The labels framework is applicable only until Avi Vantage version 20.1.4. If you use Avi Vantage version 20.1.5, skip to the Extended Granular RBAC section.

To provide role-based access via labels,

  1. Configure the virtual service and pool
  2. Add Filters to the role
  3. Associate the role with a user account
  4. Create the virtual service and pool

By default, the roles can be viewed as shown below:


[admin]: > show role
+----------------------+-------------------------------------------+
| Name                 | UUID                                      |
+----------------------+-------------------------------------------+
| Application-Admin    | role-55ea20aa-5629-45df-9300-70edc9551b7c |
| Tenant-Admin         | role-6191a95c-934e-4850-92cb-107fa7e46f46 |
| System-Admin         | role-4bd8f7f0-c5b0-4432-97cd-6cd66008ba7b |
| Application-Operator | role-e0b7a3b8-e8d4-4dce-bd76-67efa1c985f1 |
| Security-Admin       | role-58030a7a-6f31-4f42-8529-acc510a1067a |
| WAF-Admin            | role-307a935c-ef76-4fe7-a52e-bddb050dcc4a |
+----------------------+-------------------------------------------+


Configure the system-admin role with the privileges at the virtual service and the pool levels

Virtual Service


[admin]: > configure role system-admin
[admin]: role> privileges resource permission_virtualservice type write_access
New object being created
[admin]: role:privileges> save

Pool


[admin]: role> privileges resource permission_pool type write_access
New object being created
[admin]: role:privileges> save

Similarly, the role can be defined at the pool group level as shown below:


[admin]: role> privileges resource permission_poolgroup type write_access
New object being created
[admin]: role:privileges> save

The configured role is as shown below:


[admin]: role> where
Tenant: admin
Cloud: Default-Cloud
+---------------+---------------------------+
| Field         | Value                     |
+---------------+---------------------------+
| name          | system-admin              |
| privileges[1] |                           |
|   type        | WRITE_ACCESS              |
|   resource    | PERMISSION_VIRTUALSERVICE |
| privileges[2] |                           |
|   type        | WRITE_ACCESS              |
|   resource    | PERMISSION_POOL           |
| privileges[3] |                           |
|   type        | WRITE_ACCESS              |
|   resource    | PERMISSION_POOLGROUP      |
+---------------+---------------------------+

Adding a Filter to the Role

When adding filters to a role, we define the match operation or criteria, and match labels (key, values).
For example, to provide a role with access to both blue app and green app, use the following commands:


admin:10-79-110-8]: role> filters
New object being created
[admin]: role:filters> match_operation role_filter_equals
[admin]: role:filters> match_label
[admin]: role:filters:match_label> key app
[admin]: role:filters:match_label> values blue
[admin]: role:filters:match_label> values green
[admin]: role:filters:match_label> save
[admin]: role:filters>

The role is viewed as shown below:


[admin:10-79-110-8]: role:filters> where
Tenant: admin
Cloud: Default-Cloud
+-----------------+--------------------+
| Field           | Value              |
+-----------------+--------------------+
| match_operation | ROLE_FILTER_EQUALS |
| match_label     |                    |
|   key           | app                |
|   values[1]     | blue               |
|   values[2]     | green              |
+-----------------+--------------------+

Here,

  • Match operation or criteria – Equals
  • Match Labels are the key value pairs: (Key, Value): (app, blue) and (app, green)

The role system-admin is configured as shown below:


[admin]: role> where
Tenant: admin
Cloud: Default-Cloud
+-------------------+-------------------------------------------+
| Field             | Value                                     |
+-------------------+-------------------------------------------+
| uuid              | role-f75a89e6-32a8-4b9c-9192-547362c4e497 |
| name              | system-admin                              |
| privileges[1]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_VIRTUALSERVICE                 |
| privileges[2]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_POOL                           |
| privileges[3]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_POOLGROUP                      |
| filters[1]        |                                           |
|   match_operation | ROLE_FILTER_EQUALS                        |
|   match_label     |                                           |
|     key           | app                                       |
|     values[1]     | blue                                      |
|     values[2]     | green                                     |
|   enabled         | True                                      |
| tenant_ref        | admin                                     |
+-------------------+-------------------------------------------+

Creating User Access

Now that the role is created, this can now be associated with a User Account.
A role_ref is mapped to a tenant. The role applies to objects only in the mapped tenant.
To configure the role,


[admin]: user> configure user system-admin
[admin]: user> access role_ref system-admin
[admin]: user> access role_ref system-admin
 New object being created
[admin]: user:access> save
[admin]: user> password avi123
[admin]: user> access index 1

Configuring a Tenant

To configure a tenant,


[admin]: user:access>
[admin]: user:access> tenant_ref admin
[admin]: user:access> save

The user details are configured as shown below:


[admin]: user> where
Tenant: admin
Cloud: Default-Cloud
+--------------+--------------+
| Field        | Value        |
+--------------+--------------+
| password     | avi123       |
| name         | system-admin |
| access[1]    |              |
|   role_ref   | system-admin |
|   tenant_ref | admin        |
+--------------+--------------+
[admin]: user> save


[admin:10-79-110-8]: user> save
+------------------+-------------------------------------------+
| Field            | Value                                     |
+------------------+-------------------------------------------+
| uuid             | user-db66362d-53e6-46aa-bfec-bd8d578e8264 |
| username         | system-admin                              |
| password         | *sensitive*                               |
| name             | system-admin                              |
| email            |                                           |
| access[1]        |                                           |
|   role_ref       | system-admin                              |
|   tenant_ref     | admin                                     |
|   all_tenants    | False                                     |
| is_superuser     | False                                     |
| local            | True                                      |
| user_profile_ref | Default-User-Account-Profile              |
+------------------+-------------------------------------------+

Creating the Virtual Service and Pool

In this section, creation of virtual service, pool, and pool group with labels will be discussed.

Note: The labels framework is applicable only until Avi Vantage version 20.1.4. If you use Avi Vantage version 20.1.5, skip to the Extended Granular RBAC section.

Virtual Service

To create a virtual service which has app Blue,


[admin]: > configure virtualservice vs-1
[admin]: virtualservice> vip vip_id 0 ip_address 1.1.1.1
New object being created
[admin]: virtualservice:vip> save
[admin]: virtualservice> services port 80
New object being created
[admin]: virtualservice:services> save
[admin]: virtualservice> labels
New object being created
[admin]: virtualservice:labels> key app value blue
[admin]: virtualservice:labels> save

The virtual service is as shown below:


[admin]: virtualservice> where
Tenant: admin
Cloud: Default-Cloud
+--------------+---------+
| Field        | Value   |
+--------------+---------+
| name         | vs-1    |
| services[1]  |         |
|   port       | 80      |
| vip[1]       |         |
|   vip_id     | 0       |
|   ip_address | 1.1.1.1 |
| labels[1]    |         |
|   key        | app     |
|   value      | blue    |
+--------------+---------+

Pool
To create a pool which has app green,


[admin:10-79-110-8]: > configure pool pool-1
[admin:10-79-110-8]: pool> labels
New object being created
[admin:10-79-110-8]: pool:labels> key app value green
[admin:10-79-110-8]: pool:labels> save
[admin:10-79-110-8]: pool> save

The pool object is as shown below:


+---------------------------------------+------------------------------------------------+
| Field                                 | Value                                          |
+---------------------------------------+------------------------------------------------+
| uuid                                  | pool-5f9f0ec8-3ac2-4351-8598-225d79b0d120      |
| name                                  | pool-1                                         |
| default_server_port                   | 80                                             |
| graceful_disable_timeout              | 1 min                                          |
| connection_ramp_duration              | 10 min                                         |
| max_concurrent_connections_per_server | 0                                              |
| lb_algorithm                          | LB_ALGORITHM_LEAST_CONNECTIONS                 |
| lb_algorithm_hash                     | LB_ALGORITHM_CONSISTENT_HASH_SOURCE_IP_ADDRESS |
| inline_health_monitor                 | True                                           |
| use_service_port                      | False                                          |
| capacity_estimation                   | False                                          |
| capacity_estimation_ttfb_thresh       | 0 milliseconds                                 |
| vrf_ref                               | global                                         |
| fewest_tasks_feedback_delay           | 10 sec                                         |
| enabled                               | True                                           |
| request_queue_enabled                 | False                                          |
| request_queue_depth                   | 128                                            |
| host_check_enabled                    | False                                          |
| sni_enabled                           | True                                           |
| rewrite_host_header_to_sni            | False                                          |
| rewrite_host_header_to_server_name    | False                                          |
| lb_algorithm_core_nonaffinity         | 2                                              |
| lookup_server_by_name                 | False                                          |
| analytics_profile_ref                 | System-Analytics-Profile                       |
| labels[1]                             |                                                |
|   key                                 | app                                            |
|   value                               | green                                          |
| tenant_ref                            | admin                                          |
| cloud_ref                             | Default-Cloud                                  |
| server_timeout                        | 0 milliseconds                                 |
| delete_server_on_dns_refresh          | True                                           |
| enable_http2                          | False                                          |
| ignore_server_port                    | False                                          |
| routing_pool                          | False                                          |
+---------------------------------------+------------------------------------------------+

From the example, the virtual service VS-1 has access to app blue, and the pool has access to app green. The role system-admin has write access to both apps blue and green, defined in the privileges as shown below:


[admin]: > show role system-admin
+-------------------+-------------------------------------------+
| Field             | Value                                     |
+-------------------+-------------------------------------------+
| uuid              | role-f75a89e6-32a8-4b9c-9192-547362c4e497 |
| name              | system-admin                              |
| privileges[1]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_VIRTUALSERVICE                 |
| privileges[2]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_POOL                           |
| privileges[3]     |                                           |
|   type            | WRITE_ACCESS                              |
|   resource        | PERMISSION_POOLGROUP                      |
| filters[1]        |                                           |
|   match_operation | ROLE_FILTER_EQUALS                        |
|   match_label     |                                           |
|     key           | app                                       |
|     values[1]     | blue                                      |
|     values[2]     | green                                     |
|   enabled         | True                                      |
| tenant_ref        | admin                                     |
+-------------------+-------------------------------------------+

Configuring Labels via the UI

Starting with Avi Vantage version 20.1.4, labels can be applied to virtual service and pools from the UI.

To configure labels for a virtual service:

  1. From the New Virtual Service screen or Edit Virtual Service screen, navigate to the Step 4: Advanced tab.

  2. In the Role-Based Access Control (RBAC) section, click on Add.

  3. Enter the Key and the corresponding Value as shown below: RBAC VS

  4. Click on Next>Save.

To configure labels for a pool:

  1. From the New Pool screen or Edit Pool screen, navigate to the Step 4: Advanced tab.

  2. In the Role-Based Access Control (RBAC) section, click on Add.

  3. Enter the Key and the corresponding Value as shown below: RBAC pool

  4. Click on Next>Save.

Extended Granular RBAC

Starting with Avi Vantage 20.1.5, the granular RBAC feature is extended to support the following:

  • Multiple values (value 1, value 2, value 3…), mapped to a single key for an object
    Example:
    User 1 has to transfer a pre-prod application to prod, for which User 2 has access.
    The object has label “app”:[“pre-pred”].
    User 1 has access to “app”:”pre-prod”.
    User 1 needs to transfer this object to “prod“.
    In this case, the object has to be configured with “key” : “list of labels” for transferring the application.
    Any user who has access to the object with labels configured in the role, can use additional labels which the user does not have access to.
    Here, an additional label has to be applied for the object.
    “app“: [“pre-prod”, “prod”] After the transfer, the new app owner (User 2)can remove “app“: “pre-prod“ from the object to discontinue access to User 1.

  • A flag allow_unlabelled_ access to enable read access to unlabelled objects alongside labels objects, configured with role filters for a user. Example:
    A user with labels in a role needs to access certain standard profiles, which have no labels.
  • A new object, LabelGroup is introduced to track the labels allowed/suggested for a given tenant. For each tenant, there can be associated label groups. At the tenant level, the labels can either be enforced or deprecated.

Note: Starting with Avi Vantage version 20.1.15, the field Labels is deprecated. The new field markers supports a list of values on a key.

Using Markers

Configuring the Object

Let us consider configuring the pool object pool-123 with two owners, eng and marketing. Here,
“Key”: [“value1”, “value2”] :: “Owner”: [“eng”, “marketing”].


[admin:ctrl10]: > configure pool pool-123
[admin:ctrl10]: pool> markers
New object being created
[admin:ctrl10]: pool:markers> key owner
[admin:ctrl10]: pool:markers> values eng
[admin:ctrl10]: pool:markers> values marketing
[admin:ctrl10]: pool:markers> save
[admin:ctrl10]: pool> save

The pool configuration shows that the key and the corresponding values are assigned as shown below:


+---------------------------------------+------------------------------------------------+
| Field                                 | Value                                          |
+---------------------------------------+------------------------------------------------+
| uuid                                  | pool-0f373267-d62d-47b5-90e6-486abdd5da53      |
| name                                  | pool-123                                       |
| default_server_port                   | 80                                             |
| graceful_disable_timeout              | 1 min                                          |
| connection_ramp_duration              | 10 min                                         |
| max_concurrent_connections_per_server | 0                                              |
| lb_algorithm                          | LB_ALGORITHM_LEAST_CONNECTIONS                 |
| lb_algorithm_hash                     | LB_ALGORITHM_CONSISTENT_HASH_SOURCE_IP_ADDRESS |
| inline_health_monitor                 | True                                           |
| use_service_port                      | False                                          |
| capacity_estimation                   | False                                          |
| capacity_estimation_ttfb_thresh       | 0 milliseconds                                 |
| vrf_ref                               | global                                         |
| fewest_tasks_feedback_delay           | 10 sec                                         |
| enabled                               | True                                           |
| request_queue_enabled                 | False                                          |
| request_queue_depth                   | 128                                            |
| host_check_enabled                    | False                                          |
| sni_enabled                           | True                                           |
| rewrite_host_header_to_sni            | False                                          |
| rewrite_host_header_to_server_name    | False                                          |
| lb_algorithm_core_nonaffinity         | 2                                              |
| lookup_server_by_name                 | False                                          |
| analytics_profile_ref                 | System-Analytics-Profile                       |
| markers[1]                            |                                                |
|   key                                 | owner                                          |
|   values[1]                           | eng                                            |
|   values[2]                           | marketing                                      |
| tenant_ref                            | admin                                          |
| cloud_ref                             | Default-Cloud                                  |
| server_timeout                        | 0 milliseconds                                 |
| delete_server_on_dns_refresh          | True                                           |
| enable_http2                          | False                                          |
| ignore_server_port                    | False                                          |
| routing_pool                          | False                                          |
+---------------------------------------+------------------------------------------------+

Creating Roles

Create the Role named Eng with write access to the pool object:


[admin:ctrl10.79.169.184]: > configure role role-eng
[admin:ctrl10.79.169.184]: role> privileges
New object being created
[admin:ctrl10.79.169.184]: role:privileges> type write_access
[admin:ctrl10.79.169.184]: role:privileges> resource permission_pool
[admin:ctrl10.79.169.184]: role:privileges> save
[admin:ctrl10.79.169.184]: role> filters
New object being created
[admin:ctrl10.79.169.184]: role:filters> match_operation role_filter_glob_match
[admin:ctrl10.79.169.184]: role:filters> match_label
[admin:ctrl10.79.169.184]: role:filters:match_label> key owner
[admin:ctrl10.79.169.184]: role:filters:match_label> values *eng*
[admin:ctrl10.79.169.184]: role:filters:match_label> save
[admin:ctrl10.79.169.184]: role:filters> save
[admin:ctrl10.79.169.184]: role> no allow_unlabelled_access
[admin:ctrl10.79.169.184]: role> save

The role is viewed as shown below:


+-------------------------+-------------------------------------------+
| Field                   | Value                                     |
+-------------------------+-------------------------------------------+
| uuid                    | role-870880cf-6093-4dbb-83bb-b6e0566dfc83 |
| name                    | role-eng                                  |
| privileges[1]           |                                           |
|   type                  | WRITE_ACCESS                              |
|   resource              | PERMISSION_POOL                           |
| filters[1]              |                                           |
|   match_operation       | ROLE_FILTER_GLOB_MATCH                    |
|   match_label           |                                           |
|     key                 | owner                                     |
|     values[1]           | *eng*                                     |
|   enabled               | True                                      |
| allow_unlabelled_access | False                                     |
| tenant_ref              | admin                                     |
+-------------------------+-------------------------------------------+

Note: For this role, allow_unlabelled_access is disabled. This means, the unlabelled objects are not visible to the user. For unlabelled objects to be visible, this option has to be set to True.

Similarly, the role marketing can be configured with the required permissions to the object.

Create a Label Group

Create label group-123 which is a new object that holds a list of [“key1”: [“value1”, “value2’, “value3”, …].


[admin:ctrl]: > configure labelgroup labelgroup-123
[admin:ctrl]: labelgroup> labels
New object being created
[admin:ctrl]: labelgroup:labels> match_operation role_filter_equals
[admin:ctrl]: labelgroup:labels> match_label
[admin:ctrl]: labelgroup:labels:match_label> key owner
[admin:ctrl1]: labelgroup:labels:match_label> values eng
[admin:ctrl1]: labelgroup:labels:match_label> values marketing
[admin:ctrl1]: labelgroup:labels:match_label> values testing
[admin:ctrl1]: labelgroup:labels:match_label> save
[admin:ctrl1]: labelgroup:labels> save
[admin:ctrl1]: labelgroup> save

The label group object is as shown below:


+-------------------+-------------------------------------------------+
| Field             | Value                                           |
+-------------------+-------------------------------------------------+
| uuid              | labelgroup-dee35ef6-b3c3-4eae-956a-9b32b6a87d26 |
| name              | labelgroup-123                                  |
| labels[1]         |                                                 |
|   match_operation | ROLE_FILTER_EQUALS                              |
|   match_label     |                                                 |
|     key           | owner                                           |
|     values[1]     | eng                                             |
|     values[2]     | marketing                                       |
|     values[3]     | testing                                         |
+-------------------+-------------------------------------------------+

Associating Label Group to a Tenant


[admin:ctrl]: > configure tenant t-1
[admin:ctrl]: tenant> enforce_label_group
[admin:ctrl]: tenant> label_group_refs labelgroup-123
[admin:ctrl]: tenant> save

The configured tenant is as shown before:


+--------------------------------+---------------------------------------------+
| Field                          | Value                                       |
+--------------------------------+---------------------------------------------+
| uuid                           | tenant-b7a85c33-26c3-40eb-a25c-f86a58d3e5ff |
| name                           | t-1                                         |
| local                          | True                                        |
| config_settings                |                                             |
|   tenant_vrf                   | False                                       |
|   se_in_provider_context       | True                                        |
|   tenant_access_to_provider_se | True                                        |
| enforce_label_group            | True                                        |
| label_group_refs[1]            | labelgroup-123                              |
+--------------------------------+---------------------------------------------+

Creating an object with markers that does not qualify the assigned key:value rules in the label group, displayed an error.
For example, if the pool object is configured with the marker “Key”: [“sales”], an error is displayed as shown below:


[admin:ctrl]: > configure pool pool-4
[admin:ctrl]: pool> markers
New object being created
[admin:ctrl]: pool:markers> key owner
[admin:ctrl]: pool:markers> value sales
[admin:ctrl]: pool:markers> save
[admin:ctrl]: pool> save
Error: {"error": "Marker with key 'owner' to value 'sales' does not qualify the labelgroup rules on this tenant."}

Supported Objects

The labels framework is supported for the following config objects:

  • VIRTUALSERVICE
  • POOL
  • POOLGROUP
More Supported Objects
  • HEALTHMONITOR
  • NETWORKPROFILE
  • APPLICATIONPROFILE
  • HTTPPOLICYSET
  • DNSPOLICY
  • SECURITYPOLICY
  • IPADDRGROUP
  • STRINGGROUP
  • SSLPROFILE
  • SSLKEYANDCERTIFICATE
  • NETWORKSECURITYPOLICY
  • APPLICATIONPERSISTENCEPROFILE
  • ANALYTICSPROFILE
  • VSDATASCRIPTSET
  • PKIPROFILE
  • SERVERAUTOSCALEPOLICY
  • AUTOSCALELAUNCHCONFIG
  • IPAMPROFILE
  • HARDWARESECURITYMODULEGROUP
  • PRIORITYLABELS
  • POOLGROUPDEPLOYMENTPOLICY
  • GSLBSERVICE
  • GSLBGEODBPROFILE
  • GSLBAPPLICATIONPERSISTENCEPROFILE
  • TRAFFICCLONEPROFILE
  • WAFPOLICY
  • WAFPROFILE
  • ERRORPAGEPROFILE
  • ERRORPAGEBODY
  • L4POLICYSET
  • WAFPOLICYPSMGROUP
  • PINGACCESSAGENT
  • NETWORKSERVICE
  • NATPOLICY
  • SSOPOLICY
  • PROTOCOLPARSER
  • IPREPUTATIONDB
  • IpamDnsProviderProfile
  • SERVICEENGINEGROUP

Unsupported Permissions

The following permissions classified under Operations and Administrations are not supported for role-based access control per app via labels:

  • Operations
 'PERMISSION_ALERT', 'PERMISSION_ALERTCONFIG', 'PERMISSION_ALERTEMAILCONFIG', 'PERMISSION_ALERTSYSLOGCONFIG', 'PERMISSION_ACTIONGROUPCONFIG', 'PERMISSION_SNMPTRAPPROFILE', 'PERMISSION_TRAFFIC_CAPTURE', ],
  • Administration
 ADMINISTRATION: [
'PERMISSION_CONTROLLER', 'PERMISSION_INTERNAL', 'PERMISSION_TENANT', 'PERMISSION_SYSTEMCONFIGURATION', 'PERMISSION_USER', 'PERMISSION_ROLE', 'PERMISSION_UPGRADE', 'PERMISSION_REBOOT', 'PERMISSION_TECHSUPPORT', ]

Caveats and Limitations

  • The number of labels for objects is limited to 4
    Note: Starting with Avi Vantage 20.1.5, there is no restriction on the number of labels for objects
  • A maximum of 4 filters can be applied per role
  • The number of characters for the labels key and value is limited to 128
  • A user with no filters can access all objects as per the privileges configured in the role (as per the default behavior)

Document Revision History

Date Change Summary
April 16, 2021 Updated the article for field-level role based access controls (version 20.1.5)
October 13, 2020 Published the Feature KB for Granular RBAC (version 20.1.2)