Swift 多租户存储服务 Token 支持¶
这是一个关于如何使用组合 Token（又称服务 Token）来改进 Swift 多租户存储的 Glance 提案。
具体来说，是为了
保证 Glance 数据库和 Swift 存储之间的一致性。（例如，移除用户在 Glance 不知情的情况下删除镜像对象的能力。）
将镜像与用户的常规 Swift 数据分开存储，防止其帐户中的噪音，并更清晰地抽象 Glance API。
确保策略执行
消除命名空间冲突的可能性
问题描述¶
Glance 使用 Swift 代表用户存储数据。
数据存储方式有两种方法
单租户。对象存储在单个专用的 Swift 帐户中（即，所有用户的所有数据都存储在同一个帐户中）。
多租户。对象存储在最终用户的 Swift 帐户（项目）中。通常，会创建专用的容器来保存这些对象。
以下表格描述了两种方法各自的优点和局限性
项目 |
特性/主题 |
单租户 |
多租户 |
1 |
密码泄露易受攻击 (CVE-2013-1840) |
是 |
否 |
2 |
容易受到 Token 泄露的影响 (*) |
是 |
否 |
3 |
容器删除易受攻击 |
是 |
否 |
4 |
服务用户删除易受攻击 |
是 |
否 |
5 |
Swift 帐户中的“噪音” |
否 |
是 |
6 |
命名空间冲突（用户和服务选择相同的名称） |
否 |
是 |
7 |
一致性保证（Glance 数据库 vs swift 帐户）($), (+) |
是 |
否 |
8 |
策略执行（例如，镜像下载） |
是 |
否 |
9 |
公平的 Swift 速率限制（用户不受他人 Swift 使用的影响） |
否 |
是 |
- (*) 这里“脆弱”意味着单个泄露的 Token 可能被用来
访问所有用户的镜像数据。
- ($) 在多租户的情况下，用户可以删除底层镜像的对象
。
- (+) 如果启用了延迟删除，则不清楚多租户
的情况是否会“清理”得当。这不在本规范的考虑范围内。
提议的变更¶
在访问存储在多租户 Swift 存储中的镜像数据时，可选地需要服务 Token。
本提案使用了 Keystone 中间件中的“服务 Token 组合授权”支持 [1]。
本提案还使用了 Swift 对多个转售商前缀的支持，允许在项目特定的帐户中存储对象，同时保留通过组合 Token 控制如何访问这些对象的方式 [2]。
这些更改将适用于所有访问 Swift 后端的访问（上传、下载等）。
示例：现有的镜像下载
+----------------+
| User |
+-------+--------+
|
| 1. Get Glance Image 123
|
| GET http://glance:9292/v2/images/123/file
| X-AUTH-TOKEN: <token for user project 'abc'>
|
+-------v---------+
| Glance |
+-------+---------+
|
| 2. Get Swift Object Data
|
| GET http://swift:8080/v1/AUTH_abc/glance_123/123
| X-AUTH-TOKEN: <token for user project 'abc'>
|
+-------v---------+
| Swift |
+-----------------+
提议的访问模型有两个变化
与其使用标准的
AUTH_Swift 转售商前缀，不如使用专门的前缀，例如IMAGE_。将生成服务 Token 并与 Swift 请求一起提供
示例：提议的镜像下载
+----------------+
| User |
+-------+--------+
|
| 1. Get Glance Image 456
|
| GET http://glance:9292/v2/images/456/file
| X-AUTH-TOKEN: <token for user project 'abc'>
|
+-------v---------+
| Glance |
+-------+---------+
|
| 2. Get Swift Object Data
|
| GET http://swift:8080/v1/IMAGE_abc/glance_456/456
| X-AUTH-TOKEN: <token for user project 'abc'>
| X-SERVICE-TOKEN: <token for Glance service project>
|
+-------v---------+
| Swift |
+-----------------+
服务 Token 的生成方式与今天为单租户 Swift 存储生成的 Token 类似，即凭据将存储在 Glance 的配置中。与单租户存储凭据不同，如果多租户服务帐户凭据泄露，它们不会直接访问所有镜像。
用户 Token 和服务 Token 的组合将允许访问项目 abc 在 IMAGE_ 转售商前缀下。具体来说，Swift 将验证服务 Token 是否包含访问相关转售商前缀所需的特定角色。（有关更多详细信息，请参阅相关的 Swift 规范 [2]）。
Swift 转售商前缀可以由操作员定义，并将同时存在于 Swift 和 Glance 配置中。
对 IMAGE_ 前缀的 Swift 请求，如果没有包含适当范围的服务 Token，将返回 HTTP Forbidden (403)。
现有的非服务 Token 行为将继续受到支持。
服务 Token 生成不会绑定到特定项目。不依赖于特定项目。如果项目被删除，可以创建一个具有相同角色的新项目并用于生成服务 Token。
可以使用两个单独的项目或同一项目中的两个用户来执行服务项目的滚动密码更改。
如果操作员修改其配置以利用新的行为，预先存在的镜像——存储在旧转售商前缀 AUTH_ 下的镜像——将继续可访问。服务 Token 仍然会提供给 Swift，但会被忽略。
示例：镜像下载，向后兼容性
+----------------+
| User |
+-------+--------+
|
| 1. Get Glance Image 123
|
| GET http://glance:9292/v2/images/123/file
| X-AUTH-TOKEN: <token for user project 'abc'>
|
+-------v---------+
| Glance |
+-------+---------+
|
| 2. Get Swift Object Data
|
| GET http://swift:8080/v1/AUTH_abc/glance_123/123
| X-AUTH-TOKEN: <token for user project 'abc'>
| X-SERVICE-TOKEN: <token for Glance service project>
|
+-------v---------+
| Swift |
+-----------------+
备选方案¶
可以使用两个 Swift 安装通过对一个 Swift 进行防火墙用户访问来提供类似的行为。这将产生大量的硬件和操作员开销。
数据模型影响¶
对数据模型本身没有影响。
（新的镜像“位置”条目会略有不同，因为它们将包含不同的 Swift 路径。）
REST API 影响¶
无。
安全影响¶
此更改通过防止直接通过 Swift 访问镜像数据来增强安全性。这消除了绕过例如公共镜像、共享镜像和用户拥有镜像的镜像下载策略的能力。
通知影响¶
无
其他最终用户影响¶
新的镜像对象将不会列在用户的 Swift 帐户中。
性能影响¶
当访问 Swift 数据时，Glance API 进程需要请求服务 Token。这应该影响最小。Token 可以被缓存，因此只会影响少数访问 Swift 的请求。不访问 Swift 的请求（例如，列出镜像）不需要服务 Token。
由于用户 Token 和服务 Token 都可能过期，因此可能会出现更多 Token 过期（并影响上传/下载）的情况。目前有一些努力来缓解 Token 过期。可能可以重用其中一些努力来处理服务 Token。
其他部署者影响¶
如果操作员希望利用新的行为，他们需要创建一个服务项目并修改他们的 Swift 和 Glance 配置。（未修改的配置将像以前一样工作。）
预先存在的镜像将继续可访问。
开发人员影响¶
我们可能会提出对 python-swiftclient 的一些更改。
实现¶
负责人¶
主要负责人：Stuart McLaren
评审人员¶
核心审核员：Flavio Percoco, Nikhil Komawar
其他审核员：TBD
工作项¶
处理新的配置（服务凭据、Swift 转售商前缀）
Token 生成/缓存
任何 swift 客户端更改
测试滚动密码更改
依赖项¶
引入服务 Token 概念的 Keystone 更改已实施 [1]
引入服务 Token/多个转售商前缀支持的 Swift 更改已实施 [2]
所需的 Swift 客户端更改已实施 [3]
测试¶
理想情况下，这将成为 Glance 在 Tempest 中的默认配置，以及 devstack 的默认配置。
文档影响¶
需要创建示例策略文件，以显示如何在做出策略执行决策时使用从
X-SERVICE-TOKEN提供的新数据。更新 Glance 配置文档
