Native Keystone Resources¶

https://blueprints.launchpad.net/heat/+spec/keystone-resources

问题描述¶

一些云运营商希望能够使用 Heat 模板来管理 Keystone 中的用户、项目和角色。目前我们只能创建用户，而且只能通过 AWS IAM 资源类型来实现。

这在邮件列表中讨论过，起始线程在这里

http://lists.openstack.org/pipermail/openstack-dev/2015-January/055554.html

提议的变更¶

实现以下原生资源类型

OS::Keystone::User
- name (可选 - 默认为 self.physical_resource_name())
- default_project_id (可选)
- email (可选)
- domain (可选)
- password (可选)
- enabled (默认 True)
- groups (列表)
- roles (列表)
  - domain (可选 - 必须指定 domain 或 project 或两者)
  - project (可选 - 必须指定 domain 或 project 或两者)
  - 角色
OS::Keystone::Group
- name (可选 - 默认为 self.physical_resource_name())
- domain (可选)
- description (可选)
- roles (列表)
  - domain (可选 - 必须指定 domain 或 project 或两者)
  - project (可选 - 必须指定 domain 或 project 或两者)
  - 角色
OS::Keystone::Role
- name (可选 - 默认为 self.physical_resource_name())
OS::Keystone::Project
- name (可选 - 默认为 self.physical_resource_name())
- domain (可选)
- description (可选)
- enabled (默认 True)

由于在默认 policy.json 配置中，这些 API 仅对管理用户可用，因此该插件将位于 /contrib 树中，并且默认情况下不会安装。

备选方案¶

另一种可能的数据模型是拥有一个单独的 RoleAssignment 资源（或类似资源）来将角色授予用户或组，而不是在用户或组资源中列出角色。类似的情况也适用于组中的用户列表，可以将其实现为 GroupMembership 资源。

然而，该数据模型存在一些问题。首先是添加用户到组或将角色授予用户/组不会创建具有自身 UUID 的物理资源。这使得 Heat 难以管理这些资源。

第二个问题是，这种方法倾向于为用户创建依赖问题 - 例如，在这种模型中，如果另一个资源依赖于 User，那么 Heat 可能会在 User 被分配其可能需要执行操作的角色之前开始创建它。这可能不如在 Keystone 资源中那样在 Neutron 资源中表现得明显，但这是 Heat 数据建模中已知的反模式。

用户和组也存在类似的问题 - 另一种实现方式是组定义包含一个用户列表，而不是用户定义包含一个组列表。优点是它更接近 API 的实现方式，但选择这种方式是因为它更有可能自动生成正确的依赖关系：任何依赖于 User 的资源都将始终等待所有组被分配。两种方法都可能使某些（不同的）用例变得笨拙，但唯一的解决方案是单独的 GroupMembership 资源类型，并且它将遭受所有与 RoleAssignment 讨论过的问题。

实现¶

负责人¶

主要负责人: kanagaraj-manickam

里程碑¶

完成目标里程碑: Kilo-3

工作项¶

用户插件
项目插件
组插件
角色插件
keystone.project 的自定义约束
keystone.group 的自定义约束
keystone.role 的自定义约束
keystone.domain 的自定义约束

依赖项¶

无

原生 Keystone 资源