显式域 ID¶
问题描述¶
许多组织正在部署多个 OpenStack 环境。这些系统未共享到单个大型集群的原因有很多。有些由不同的子组织拥有。另一些由于应用程序生命周期而保持分离。还有一些是物理上彼此隔离的。所有这些问题都阻止了跨集群的协作。
如果组织使用 LDAP 作为用户后端，则 id_mapping 表中的用户条目会生成一个新的 local_id，该 local_id 是 domain_id 和 LDAP 服务器上的唯一标识符的哈希值。如果两个不同部署中的域 ID 不同，则用户最终将拥有两个不同的用户 ID。然后，尝试在多个部署中构建审计跟踪必须关联不同 Keystone 服务器上的用户 ID。
为了避免这种情况，操作员希望将 LDAP 用户保存在跨部署具有一致 ID 的域中。然而，唯一具有可预测 ID 的域是 default。 默认域在初始安装期间使用，因此具有服务用户。因此，将 LDAP 用户放在默认域中是不切实际的。如果某个站点希望在特定于域的后端中拥有两个 LDAP 服务器，则只能将一个放在默认域中。
如今，如果部署者希望在避免数据库复制的同时保持两个 Keystone 服务器同步，他们必须修改数据库以更新域 ID，以便条目匹配。域 ID 然后用于 LDAP 映射的 ID，如果它们不匹配，则用户 ID 将不同。应该能够添加一个具有显式 ID 的域，以便这两个服务器可以匹配用户 ID。
目前，一项正在进行的工作旨在使联合身份源使用与 LDAP 相同的机制。这项工作受到与 LDAP 相同的 domain_id 限制的阻碍。
在多个部署中保持标识符的一致性将有助于几种用例
这将使跨两个不同部署同步角色分配更容易，因为第一个部署中的用户 ID 可以用于第二个部署。
应用程序现在能够预测用户在集群中将拥有的用户 ID，甚至在用户访问该集群之前。这允许系统预创建用户记录，并在用户最终通过身份验证到 Keystone 服务器时将它们链接到身份源。
一种可用于多个部署的结构是让每个 Keystone 服务器代表不同的区域，并且每个区域拥有一组作为记录系统的域。这允许本地写入并避免冲突。为了使中央系统跟踪域 ID 并跨不同服务器同步它们，其中一个系统需要能够显式地分配它们。
提议的变更¶
创建域时，用户可以传递可选参数 explicit_domain_id，在创建域时使用该参数。以这种方式创建的域将不使用自动生成的 ID，而是使用传入的 ID。
以这种方式传递的标识符必须符合现有的 ID 生成方案：不带破折号的 UUID4。请注意，此 API 仅可通过系统成员资格访问，将其限制为部署管理员和操作员。
备选方案¶
站点间数据库 Galera 同步。这仅能扩展到少量位置。考虑到每个站点 3 个节点的本地 HA 要求，这可能扩展到个位数的位置。
使域名称不可变并更改方案以使用名称。这将破坏所有现有的 LDAP 部署，以及破坏 API 向后兼容性。
K2K 联合已被讨论为帮助管理多个站点的一种方式，但它没有解决使用户 ID 一致以用于审计的需要。此外，K2K 添加了额外的 SAML 间接层，没有在此提供额外价值：它解决了用户存储在一个 Keystone 服务器中，但需要访问单独云的问题。因此，K2K 将遭受与任何联合身份提供商相同的问题。
安全影响¶
这应该对安全性没有直接影响，甚至几乎没有。然而，它将大大有助于可审计性，因为可以在多个部署中关联用户 ID。
域管理员滥用此新选项的风险很小。创建域是一项罕见的操作，仅保留给云管理员。因此，他们正在同步域 ID 以帮助实现自己的组织目标。如果他们选择不同步域，它只会影响他们自己的集群，而不会影响其他集群。审计的退化情况将是当前状态。
用户的 ID 现在将属于“可预测但不可设置”的类别。由于 uuid 是字符串的哈希值，而不是显式设置的，因此不会存在“用户 ID 占用”的潜力，即用户预分配条目以阻止其他用户。
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
主要负责人
Adam Young <ayoung>
工作项¶
Keystone 服务器更改 Openstack SDK 更改 OpenStack CLI 更改
依赖项¶
无
文档影响¶
需要在文档中包含新选项，包括更新 LDAP 和联合文档。
参考资料¶
无
