分层管理边界
Arvind Tiwari
摘要
在大型 OpenStack 云部署中，云服务提供商（CP）可能希望以白标（又称经销商或增值经销商）商业模式销售其服务。这是一种共生关系，CP 以批量方式销售其服务，而经销商获得适当的折扣。
在这种商业模式下，CP 为每个经销商在其基础设施或托管云（HC）上设置一个“虚拟私有云”（VPS）。经销商获得管理其客户和分配给客户使用的资源的特权。
需求
云服务提供商视角
- 云服务提供商希望能够管理多个经销商帐户。
- 能够按需启动多个经销商帐户。
- 能够管理经销商帐户，包括他们的直接资源（IAM 和非 IAM）。
- 能够管理子客户（经销商的直接客户），包括他们的资源（IAM 和非 IAM）。
例如，Cloud Provider Inc. (CPI) 拥有大型 OpenStack 部署，并以经销商模式销售其服务。
经销商视角
- 经销商希望在 CP 的云基础设施上拥有自己的领域（vpc），并期望进行品牌重塑。
- 能够代表我的客户启动多个帐户，无需 CP 的干预。
- 能够无需 CP 干预来管理我的客户。
- 能够无需 CP 干预来管理我的客户资源（IAM 和非 IAM）。
例如，Services Provider Inc. (SPI) 是一家向多个客户在第三方云平台上销售服务的服务提供商。
潜在方案
注意：本提案的范围较低，重点仅限于身份管理（Keystone）系统的架构更改。
为了解决这些问题，我们需要能够在云部署中设置分层管理边界，以便可以创建多个服务提供商（如 SPI），并在其管理边界下的域中拥有管理权限。在这种模式下，CP 将是分层管理边界的根。
Keystone 具有域的概念，这只是管理边界的一种概念。一个域的管理员被允许管理特定域内的资源（计算和非计算），但不能跨域管理（前提是策略正确）。此功能已经存在，因此不需要更改。
我们可以进一步扩展域的概念，以建立根（父/上级）和叶（子/下级）域关系，一组根域和叶域将定义分层管理边界。下图描绘了一个域层次结构，其中根表示云服务提供商（根管理边界），以下每个级别表示不同的分层管理边界。
Keystone 提供强大的基于角色的访问控制（RBAC）功能，其中角色通过策略与访问控制规则相关联。主题与作用域到域或域内项目的角色相关联。Keystone 还支持继承的角色概念，该概念允许角色（通常是项目）从其所有域继承。我们需要扩展当前的角色继承模型，以便主题（Keystone 中的身份）继承的角色（项目和/或域）可以向下传播到域层次结构中。下图显示了角色继承的传播。
注意：角色继承传播仅向下进行，不向上或侧向进行。
云服务提供商（或经销商）管理员必须将他的/她的安全令牌限定到特定的子域（或子域中的项目），才能获取继承的管理角色。Keystone RBAC 策略执行将防止对外部资源的恶意和未经授权的访问。下图显示了云管理员如何将令牌限定到叶域中的项目来管理其计算资源。
影响
大部分更改仅限于 Keystone，显然，外部服务（Nova、Swift、……）不需要更改。
- 需要扩展域模型以支持域层次结构的概念。
- 角色子系统将受到影响，以处理分层继承的角色。
- 角色评估子系统将受到影响，以处理分层继承的角色。
- 身份验证中间件和令牌验证需要增强。
- 域 API 将受到影响，以捕获域层次结构。
