Keystone 身份验证

NSX Advanced Load Balancer 可以使用 OpenStack 的 Keystone 服务在控制器中对用户进行身份验证。NSX Advanced Load Balancer支持 Keystone v3。

使用 Keystone 对登录到 NSX Advanced Load Balancer 的用户进行身份验证是一个可配置的选项。在 NSX Advanced Load Balancer 上配置 OpenStack 云时，此选项由 use_keystone_auth 标记控制。您可以在配置 OpenStack 云时停用此标记。在这种情况下，将仅允许在 NSX Advanced Load Balancer 上配置的用户登录。此外，无法从 Keystone 导入用户的租户和角色，因此必须由 NSX Advanced Load Balancer 管理员在本地创建。

使用 Keystone 进行身份验证时，只能将 NSX Advanced Load Balancer 与一个 Keystone 实例结合使用。不能使用任何其他远程身份验证机制。因此，使用 Keystone 进行身份验证时，只能为一个 NSX Advanced Load Balancer 系统配置一个 OpenStack 云。NSX Advanced Load Balancer 内部系统帐户（如 admin）将保留一个内部本地标记，表示这些帐户进行本地身份验证。

如以下流程图所示，当用户登录时，NSX Advanced Load Balancer 将首先对用户进行 Keystone 身份验证，仅当 Keystone 身份验证失败时才会检查本地用户数据库。我们强烈建议不要创建任何新的本地用户，因为这些用户名也可能在 Keystone 中使用，从而造成混淆。

仅当用户登录时，才会从 Keystone 中导入租户和角色信息。因此，在用户登录后，在 Keystone 中为该用户添加的任何新租户和新角色不会立即反映在 NSX Advanced Load Balancer 中。它们将在用户下次登录到控制器时才导入。

从 Keystone 导入的租户列表

NSX Advanced Load Balancer 仅从 Keystone 导入在 OpenStack 云中配置的用户有权访问的租户。假定在 NSX Advanced Load Balancer OpenStack 云中配置的用户仅有权访问 Keystone 中的租户 p1、p2 和 p3。如果另一用户登录到 NSX Advanced Load Balancer，且该用户有权访问租户 p1、p3 和 p6，那么 NSX Advanced Load Balancer 将仅导入这两个列表所共有的租户（即 p1 和 p3）的相关信息。

即使在 NSX Advanced Load Balancer OpenStack 云中配置的用户拥有对 Keystone 的管理员特权，如果 NSX Advanced Load Balancer 无权访问 Keystone 的 admin_url，也只能从 Keystone 导入配置的用户在其中具有明确角色的租户。在这种情况下，OpenStack 管理员必须确保配置的用户在 NSX Advanced Load Balancer 需要提供 LBaaS 服务的每个租户中都具有管理员角色。

在使用 Keystone v3.0 和多个域的情况下，在 NSX Advanced Load Balancer OpenStack 云中配置的用户将需要在除配置的用户所在域之外的其他域内的项目中具有相应角色，才能为这些项目提供 LBaaS 服务。

OpenStack 仪表板 (Horizon) 不支持跨域分配角色。我们建议使用 OpenStack CLI 完成此操作：

openstack role add --user <USERID> --project <PROJECTID> <ROLE-NAME>

使用 Keystone V3 时，openstack-cleanup API 将无条件地清理从 OpenStack 导入的失效用户和租户。

NSX Advanced Load Balancer 与 Keystone 的集成

对于身份验证，Keystone v2.0 具有 user、project（也称为 tenant）和 role 的概念。用户可以在一个或多个项目中具有一个或多个角色。OpenStack 的其他服务通过自己的策略来定义每个角色的特权。

Keystone v3.0 引入了另外一个概念，即 domain。域定义 Keystone 实体（user 和 project）管理的管理边界。因此，一个 user 或 project 只能属于一个域。每个域都有一个唯一名称。但是，同一用户名（例如，demo）可以存在于多个域中。为了与 Keystone v2.0 API 兼容，v3.0 创建了一个名为 Default 的默认域。可通过 Keystone v2.0 API 访问的所有 user 和 project 都放置在此默认域下。

Keystone 还引入了 group 的概念。group 是单个 domain 中的一组 user，由 domain 所有。可在项目中为 group 分配 role，从而在该项目中有效地将该角色授予该组中的 /all/ users。Keystone v2.0 公用 API 和 Keystone v3.0 的端点格式分别为 http://keystone:5000/v2.0 和 http://keystone:5000/v3。

在 NSX Advanced Load Balancer 中进行 Keystone 身份验证

用于 OpenStack 集成的云配置中包含 auth_url 字段。我们已弃用先前版本中使用的 keystone_host 字段，该字段用于指定 Keystone 主机名或 IP 地址。NSX Advanced Load Balancer 将解析 auth_url 字段，以确定与配置的 Keystone 服务通信时要使用的 API 版本 - 如果后缀以“v3”结尾，则使用 v3.0 API，否则将使用 v2.0 API。

NSX Advanced Load Balancer 身份验证模式当前没有 domain 实体。但是，域 testdomain 中的 Keystone 用户 test 将映射到 NSX Advanced Load Balancer 中名为 test@testdomain 的用户。同样，testdomain 中的 Keystone 项目 testproject 将映射为 NSX Advanced Load Balancer 中名为 testproject@testdomain 的租户。唯一的例外是 Keystone 中的 Default 域，该域具有一个特殊的 UUID default:，对于从 Keystone 的这个域中导入的用户和租户，NSX Advanced Load Balancer 会丢弃 @Default。对于任何其他域中的用户，在登录到 NSX Advanced Load Balancer 时或使用该用户在 NSX Advanced Load Balancer 上配置 OpenStack 云时，将始终明确使用 @domain 后缀。

因此，Keystone 上 testdomain 域中的 test 用户可以登录到控制器，如下所示：

如果未指定 @domain，控制器会假定用户属于配置的 Keystone v3.0 服务上的 Default 域。

假设 Keystone 上 testdomain 域中的 test 用户有权访问 Default 域中的 admin 项目以及 testdomain 域中的 test 项目。在登录到控制器后，该用户将有权访问以下两个 NSX Advanced Load Balancer 租户：

导入角色

NSX Advanced Load Balancer 允许管理员通过云资源 API 配置显式映射。openstack_configuration 中的 role_mapping 参数可定义如何将 OpenStack Keystone 中的用户角色映射到 NSX Advanced Load Balancer Controller 中的角色。以下是 role_mapping 参数的示例配置：

"openstack_configuration": {
   ....
   "role_mapping": [
      {"os_role": "admin", "avi_role": "Tenant-Admin"},
      {"os_role": "_member_", "avi_role": "Tenant-Admin"},
      {"os_role": "*", "avi_role": "Application-Operator"}
   ],
}

请注意，role_mapping 参数是一个有序列表，其中的每个项目指定 Keystone 角色 (os_role) 如何映射到 NSX Advanced Load Balancer Controller 中的角色 (avi_role)。您可以为 os_role 字段指定“/”通配符，以便为任何 Keystone 角色定义默认映射。在上例中，Keystone 中的 admin 和 _member_ 角色映射到 NSX Advanced Load Balancer Controller 中的 *Tenant-Admin 角色。此外，Keystone 中的任何其他角色都映射到 NSX Advanced Load Balancer 中的 Application-Operator 角色。

下面是另外一个示例，其中仅允许具有 lbaas_project_admin 角色的用户访问控制器，而没有该角色的 Keystone 用户将被拒绝登录：

"openstack_configuration": {
   ....
   "role_mapping": [
      {"os_role": "lbaas_project_admin", "avi_role": "Tenant-Admin"},
   ],
   ....
}

跳过对 @avilocal 用户的 Keystone 身份验证

启用 Keystone 身份验证后，默认情况下，将首先对登录到 NSX Advanced Load Balancer 的任何用户进行 Keystone 身份验证。如果失败，则会根据本地存储的凭据对用户进行身份验证。这意味着，non-Keystone Avi-local 用户的每次登录尝试都将导致一次失败的 Keystone 身份验证尝试，并可能导致在 Keystone 日志中生成审核消息。

因此，对于任何以 @avilocal 作为后缀的用户名，将仅在 NSX Advanced Load Balancer 中根据本地存储的凭据对用户进行身份验证。不会对此类用户进行 Keystone 身份验证。这样可避免额外的 Keystone 身份验证尝试，从而确保不会触发 Keystone 审核消息。