配置 OpenStack Keystone 支持企业内部的域特定目录服务

问题导读

1.对于企业多个地方部署openstack，openstack是如何解决的？
2.多地企业目录本文是如何配置的？
3.openstack多域的含义是什么?有什么好处？

开源的 OpenStack 项目提供了一个基础架构即服务（IaaS）层来构建公共云和私有云。OpenStack 的应用目前得到了显著增长，公司、服务提供商、增值经销商、中小型企业、研究人员和全球数据中心都采用它来部署大规模的私有云或公共云。（请参阅 参考资料，了解有关 OpenStack 的更多信息。）

随着越来越多的企业客户开始部署 OpenStack，将 OpenStack 无缝集成到客户的现有企业目录基础架构中变得至关重要。虽然在某些情况下，这可能会通过 Keystone 的联合支持来处理，但对于很多企业来说，关键是与他们现有的 LDAP 或 Active Directory 集成。对单一企业目录的支持已经是多个 Keystone 版本的一部分，但更复杂的安装（比如，企业中每个部门具有不同的目录或目录挂载点，或服务提供商要为客户提供他们自己的目录）并没有得到很好的支持。在 Grizzly 版本中首次引入了实验版本的域特定的企业目录支持。而在 OpenStack Juno 版本中，现在已完全支持这一要求。 本文涵盖以下主题：

• 概述 OpenStack Keystone 对企业目录的经典支持
• 已添加到 Keystone 中使其能够支持域特定目录的增强
• 配置 Keystone 以使用该新支持的基本步骤
• 概述 OpenStack Keystone 在改进域特定的企业目录方面的未来发展方向
  

Keystone 的经典授权模型

在探讨 Keystone 的新域特定的目录支持之前，概述 Keystone 的经典单域目录支持会有所帮助。Keystone 的核心其实分为两个部分：身份和任务。身份（即，谁可以通过身份验证）允许将用户和组存储在本地 SQL 数据库，或通过远程利用 LDAP 或 Active Directory 服务提供的支持。任务（即，用户在通过身份验证后可以做什么）存储了项目、域、角色和这些角色的任务。同样，这些信息可以被存储在本地 SQL 数据库，或者较少见的情况是存储在远程 LDAP/AD 服务中，前提是您对它有读写访问权限。由于将 Keystone 的域结构映射到 LDAP 的挑战（从身份的角度），到现在为止，只要对身份启用了 LDAP，就被限制为单一的默认域。这限制了在更复杂的环境中使用 LDAP/AD。

对多域企业目录支持的要求
出于效率的考虑，我们希望共享 IaaS 层，但 LDAP/AD 架构无法很好地映射到共享 IaaS 层所需的典型模型上，既然无法改变这一事实，就需要改变 Keystone 模型与目录的交互方式。从本质上讲，需要在 Keystone 中处理 “域” 方面的信息，并且在与相应的公司目录通信时就好像它是所使用的惟一一个目录一样。这包括基于每个域定义所有典型的 LDAP/AD 参数（比如 URL、目录属性映射等），并保证每当读取给定域的用户记录时，都将调用路由到正确的企业目录。这一级别的支持是在 Grizzly 中引入的，但存在一些问题。其中最严重的问题是 Keystone API 的核心理念和这种多域支持之间的冲突 - 即，您可以将用户或组 ID 交给 API，而 Keystone 可以用它来找到所查询的用户/组实体。当有多个目录服务器时，您会查看哪一个？出于性能的考虑，搜索全部服务并不是一个可行的选择。因此，原来的实现试图推断所查询的域 - 例如，因为您通常必须使用域范围的令牌来基于用户 ID 检索用户实体，所以您可以使用该令牌的范围，为所查询的域确定适当的企业目录。然而，这种方法显然有其局限性；例如，您需要在只提供用户 ID 和密码的情况下就能够进行身份验证。即使您能解决这些限制，您是否应该相信任何给定的企业目录，以创建跨所有其他企业目录都惟一的一个实体 ID？



支持多域企业目录

OpenStack 的 Juno 版本解决了上述问题，由 Keystone 提供一个目录映射层，对其客户端生成惟一的用户和组 ID，并存储关于哪个身份后端驱动程序保存实体（和那个后端内的本地 ID）的基本详细信息。此目录映射层基本上对 Keystone API 的调用者是不可见的，并且映射是当 Keystone 在其身份驱动程序中遇到实体时动态建立的。调用者可能注意到的惟一一件事情是用户和组的 ID 已经变得更大（默认情况下，它们是 64 字节的 sha256 散列，而非经典的 32 字节 UUID）。应当注意的是，此目录映射与 Keystone 联合映射是不相关的，后者用于处理 IDP 声明属性到 Keystone 角色分配的映射。

因此，让我们来看看在实践中使用域特定目录的一个例子。在向其客户提供云服务的一家服务提供商中，在 Keystone 中将客户表示为一个域是很常见的。这使得客户能够拥有自己的用户、组和项目。提供商可能想做的是，能够为客户提供使用其现有企业目录对其域进行身份验证的能力 - 使每一个客户域能够指向客户自己的 LDAP/AD 服务。要做的第一件事是，在 Keystone 中启用域特定的配置支持（默认是禁用的），方法是在主 Keystone 配置文件中设置以下两个选项：

[mw_shl_code=bash,true] [identity]
    domain_specific_drivers_enabled=true
    domain_config_dir=/etc/keystone/domains[/mw_shl_code]

当启用了域特定的驱动程序时，Keystone 每次启动时都会扫描 domain_config_dir 的内容，查找任何域特定的配置文件。对于需要其惟一企业目录的每个域，服务提供商都创建一个域特定的配置文件，其中包含该域的企业目录的具体细节。例如，如果服务提供商创建一个名为 “customerA” 的域来表示客户，然后他们创建一个域特定的配置文件，名称为 keystone.customerA.conf（该名称很重要，并且其形式始终是：keystone.{domain-name}.conf -- 域名必须与在 Keystone 中创建的域名相匹配）。该配置文件的内容可能如下：
[mw_shl_code=bash,true] [ldap]
    url = ldap://ldapservice.thecustomer.com
    user = cn=Manager,dc=openstack,dc=org
    password = mysecret
    suffix = dc=openstack,dc=org
    group_tree_dn = ou=UserGroups,dc=openstack,dc=org
    ;user_tree_dn = ou=Users,dc=openstack,dc=org
    user_mail_attribute = mail

    [identity]
    driver = keystone.identity.backends.ldap.Identity[/mw_shl_code]

如您所见，它们与通常在主 Keystone 配置文件中设置的配置选项类型是完全一样的 - 但是在该域特定的配置文件中指定它们的情况除外。需要它自己的配置的每个域都需要有其自己的配置文件。请注意，这里只需要指定特定于域的选项；常用选项可以留在主 Keystone 配置文件中。
一旦域有了它自己的配置文件，Keystone 就会在遇到用户和组实体时在后端建立它们的映射，并将针对这些实体发出的任何请求路由到合适的企业目录。
虽然它主要用于支持不同的企业目录，但您也可以为一个域指定一个配置文件来使用 SQL 后端。如果您希望有一些本地用户（比如服务用户或本地管理员用户）不放在企业目录中，这种设计就特别有用。这与 LDAP/ AD 情况中的做法是完全一样的：使用相同的命名约定，为一个域创建域特定的配置文件，但是在这种情况下，它可能只包含驱动程序的名称。例如，您希望域 CloudAdmin 由 SQL 支持，而所有其他域都可能使用 LDAP，那就创建一个域特定的配置文件，名称为 keystone.CloudAdmin.conf，其中包含：

[mw_shl_code=bash,true]  [identity]
    driver = keystone.identity.backends.sql.Identity[/mw_shl_code]

但是，更大的限制是，Keystone 目前仅允许每次加载一个 SQL 驱动程序 - 因此，要么它是通用的驱动程序（通过在主 Keystone 配置文件中将身份指定为 SQL），要么它被分配给一个特定的域（使用域特定的配置文件）。如果您试图用其自己的 SQL 配置指定多个域，Keystone 将在启动时发生异常。未来的 Keystone 版本可能会解除此限制。


实际应用的提示和技巧

可以部署多种技术来使用所描述的功能，以简化生产配置。

以正确的顺序做事

如果默认域仅指向一个 LDAP/AD 企业目录时，那么使用经典配置时，步骤的顺序应该是：

• 在主 Keystone 配置文件中将 domain_specific_drivers_enabled 设置为 "true" 并重启 Keystone。
• 创建希望它有特定配置的域。
• 为每个域创建域特定的配置文件。
• 再次重启 Keystone。
  

在 LDAP 作为默认驱动程序时，如果没有先将 domain_specific_drivers_enabled 设置为 "true"，Keystone 会阻止您创建新域（因为它知道，默认的 LDAP 驱动程序只能处理默认域）。

如果域配置没有正常工作，请检查 Keystone 日志文件

如果您已经设置了域和配置文件，但仍然无法访问企业目录中的数据，那么可能要检查 Keystone 日志文件。在启动时，由于 Keystone 会扫描domain_config_dir，它将检查每一个文件。如果不匹配 keystone.{domain-name}.conf 的形式，则被忽略。如果 Keystone 无法找到在文件名中指定的名称的域，则它也将忽略该域。在这两种情况下，Keystone 都将加载一个带有问题文件名称的警告。例如：

[mw_shl_code=bash,true]    Invalid domain name (CustomerB) found in config file name
[/mw_shl_code]


偶尔对目录映射表进行维护
如前所述，Keystone 动态地建立目录映射，将外部发布的用户和组 ID 映射到相应的企业目录服务中的底层本地实体。因为从 Keystone 的角度看，这些企业目录通常是只读的，用户管理都在带外进行，使用工具维护所查询的企业目录。在实践中，这意味着，随着时间的推移，用户和组实体被从企业目录中删除，旧映射项将保留在 Keystone 的目录映射表中。虽然这是良性的，但随着时间的推移，它会使 Keystone 表增大。为了管理这种情况，keystone-manage 工具已得到增强，可以支持多种选项，将映射项清除出 Keystone 目录映射表。最特殊的选项是，清除指定域中指定本地标识符的映射。例如：


[mw_shl_code=bash,true]    keystone-manage mapping_purge --domain-name CustomerA --local-id abc@de.com
[/mw_shl_code]

如果这是较为常见的事情，那么您可能想自动进行这种清除。然而，另一种方法是定期清除指定域中的所有映射。更为直接的问题可能是，这是否会导致您丢失在外部为本地实体发布的 ID。事实上，这不是一个问题，因为映射算法的设计让 Keystone 可以重新生成映射，并保证重新分配相同的外部发布的用户/组 ID。注意，这假设用户没有在企业目录之间移动；如果用户有移动，则将这些用户视为不同的用户。清除指定域的所有映射：
[mw_shl_code=bash,true]keystone-manage mapping_purge --domain-name CustomerA[/mw_shl_code]

结束语

本文概述了 Keystone 新的域特定配置支持，并阐述了这种新功能如何使 Keystone 支持更广泛的企业配置。它还介绍了如何设置配置文件，以及在生产环境中管理配置文件的一些有用的提示。

参考资料
学习

• OpenStack：访问 OpenStack 网站，了解有关 OpenStack 软件的更多信息。
• Keystone 用户管理：了解有关 Keystone 的经典用户授权模型的更多信息。
• 配置 Keystone：了解如何在总体上配置 Keystone，包括域特定的驱动程序。
• Keystone：了解有关 OpenStack 的 Identity Service 项目的更多信息。
• 浏览 developerWorks 云计算 专区，您可在其中找到宝贵的社区讨论并了解与云相关的新技术资源。
  

卧槽,没看懂