The Avi Load Balancer can use OpenStack’s Keystone service for user authentication to the Controller. The Avi Load Balancer supports Keystone v3.
Using Keystone for authenticating users logging into Avi Load Balancer is a configurable option. This is controlled by the flag use_keystone_auth when configuring an OpenStack cloud on Avi Load Balancer. You can configure an OpenStack cloud with this flag deactivated. In such case, only users configured on Avi Load Balancer are allowed to login. Also, tenants and roles for users can not be imported from Keystone, and hence have to be created locally by the Avi Load Balancer administrator.
When Keystone is used for authentication, the Avi Load Balancer can only be used with one instance of Keystone. No other remote authentication mechanisms can be used. Therefore, a single Avi Load Balancer system can only be configured with one OpenStack cloud when using Keystone for authentication. The Avi Load Balancer internal system accounts, such as admin, will maintain an internal local flag, denoting that they are locally authenticated.
As the following flowchart shows, when a user logs in, the Avi Load Balancer will first authenticate against Keystone and only check the local user database if the Keystone authentication fails. We strongly recommend against creating any new local users, as those names might also potentially be used in Keystone and thus cause confusion.
The tenant and role information from Keystone is imported only when a user logs in. So, when a user is logged in, any new tenants and new roles added in Keystone for that user are not immediately reflected in Avi Load Balancer. They are imported the next time the user logs into the Controller.
List of tenants imported from Keystone
The Avi Load Balancer imports from Keystone only those tenants to which users configured in the OpenStack cloud have access. Assume that the user configured in the Avi Load Balancer OpenStack cloud has access to only tenants p1, p2, and p3 in Keystone. When another user logs into the Avi Load Balancer and has access to tenants p1, p3, and p6, the Avi Load Balancer will only import information about the tenants in the intersection of those two lists, namely, p1 and p3.
Even if the user configured in the Avi Load Balancer OpenStack cloud has admin privileges on Keystone, if the Avi Load Balancer does not have access to the admin_url for Keystone, it can only import those tenants on Keystone where the configured user has explicit roles. In this case, OpenStack admin have to ensure that the configured user has the admin role in each tenant where the Avi Load Balancer needs to provide the LBaaS service.
With Keystone v3.0 and multiple domains in use, the configured user in the Avi Load Balancer OpenStack cloud will need a role in projects in domains other than the domain of the configured user, to be able to provide LBaaS service for those projects.
OpenStack dashboard (Horizon) does not support assigning roles across domains. We recommend using the OpenStack CLI to achieve this:
openstack role add --user <USERID> --project <PROJECTID> <ROLE-NAME>
While using Keystone V3, openstack-cleanup API will unconditionally clean up stale users and tenants imported from OpenStack.
Avi Load Balancer-Keystone Integration
For authentication, Keystone v2.0 has the concept of users, projects (also called tenants), and roles. A user can have one or more roles in one or more projects. Other services of OpenStack have their own policies to define the privileges of each role.
Keystone v3.0 introduces an additional concept of domains. A domain defines the administrative boundaries for management of Keystone entities (user and project). So, a user or project belongs to one and only one domain. Each domain has a unique name. However, the same user name, for example, demo, can exist in multiple domains. To be compatible with Keystone v2.0 APIs, v3.0 creates a default domain named Default. All users and projects that are accessible under Keystone v2.0 APIs are placed under this default domain.
Keystone also introduces the concept of groups. A group is a collection of users in a single domain, and is owned by a domain. A group can be assigned a role in a project, effectively giving that role in that project to /all/ users of that group. The format for endpoints of Keystone v2.0 public API and Keystone v3.0 are http://keystone:5000/v2.0 and http://keystone:5000/v3.
Keystone Authentication in Avi Load Balancer
The cloud configuration for OpenStack integration includes the auth_url field. We have deprecated the field keystone_host that was used in the previous versions to specify the Keystone host’s name or IP address. The Avi Load Balancer parses the auth_url field to determine the API version to use when communicating with the configured Keystone service – if the suffix ends in “v3,” v3.0 APIs are used, otherwise, v2.0 APIs are used.
The Avi Load Balancer authentication model currently does not have a domain entity. However, a Keystone user test in domain testdomain is mapped to a user named test@testdomain in Avi Load Balancer. Similarly, a Keystone project testproject in testdomain is mapped as a tenant with name testproject@testdomain in Avi Load Balancer. The only exception is the Default domain on Keystone, which has a special uuid default:, the Avi Load Balancer drops the @Default for users and tenants imported from Keystone from that domain. For a user in any other domain, always explicitly use the @domain suffix when logging into Avi Load Balancer or when using that user in configuring OpenStack cloud on AAvi Load Balancer.
So, the user test in domain testdomain on Keystone can login into the Controller as shown below:
When no @domain is specified, the Controller assumes that the user belongs to the Default domain on the configured Keystone v3.0 service.
Assume that user test in domain testdomain on Keystone has access to the admin project in domain Default and test project in domain testdomain. Once that user logs into the Controller, they will have access to the following two Avi Load Balancer tenants:
Importing Role
The Avi Load Balancer allows admins to configure an explicit mapping through the Cloud resource APIs. Parameter role_mapping in openstack_configuration defines how a user’s role from OpenStack Keystone are mapped to roles in the Avi Load Balancer Controller. Following is an example configuration for the role_mapping parameter:
"openstack_configuration": {
....
"role_mapping": [
{"os_role": "admin", "avi_role": "Tenant-Admin"},
{"os_role": "_member_", "avi_role": "Tenant-Admin"},
{"os_role": "*", "avi_role": "Application-Operator"}
],
}
Note that the role_mapping parameter is an ordered list, where each item specifies how a Keystone role (os_role) maps to a role in the Avi Load Balancer Controller (avi_role). You can define a default mapping for any Keystone role by specifying the “/” wildcard for the os_role field. In the above example, roles admin and _member_from Keystone are mapped to the role *Tenant-Admin in Avi Load Balancer Controller. Also, any other role from Keystone is mapped to the Avi Load Balancer role Application-Operator.
Following is another example that allows only users with role lbaas_project_admin to access the Controller, and Keystone users who do not have that role are denied from logging in:
"openstack_configuration": {
....
"role_mapping": [
{"os_role": "lbaas_project_admin", "avi_role": "Tenant-Admin"},
],
....
}
Skipping Keystone Authentication for @avilocal Users
Once Keystone authentication is enabled, by default, any user logging into Avi Load Balancer is first authenticated against Keystone. If that fails, the user is authenticated against the locally stored credentials. This means that every login attempt of a non-Keystone Avi-local user will result in a failed Keystone authentication attempt, and a possible audit message in the Keystone logs.
Any user name with @avilocal as a suffix is only authenticated against locally stored credentials in the Avi Load Balancer. Such users are not authenticated against Keystone. This avoids the extra Keystone authentication attempts and so no Keystone audit messages are triggered.
