Swift/ideas/object-lock

问题

一些对象存储提供商支持对象锁定，防止删除或特定类型的修改。这些锁旨在允许用户设置一个保留期限，无论使用何种对象存储 API 权限级别都无法覆盖，从而即使用户的管理员凭据泄露或损坏，写入对象存储的数据也无法被篡改。用例示例包括不可变的备份以防止勒索软件，以及符合法律保留要求。

对象锁定在 S3 API 中有一组明确的行为，我们应该在 Swift 的 S3 兼容 API 中复制这些行为。在使用 Swift API 时，也需要一组等效的属性，并且应该以相同的方式工作。

该提案建议我们使用对象和容器上的受保护元数据来表示与 S3 API 期望相同的状态和解释，进而映射到 S3 兼容层中的 API。

Swift API 的外观将如下所示

GET/POST/PUT /v1/{account}/{container} 需要新的头部用于容器级别配置，与 S3 匹配
- X-Container-Lock-Mode, X-Container-Lock-Days, X-Container-Lock-Years, X-Container-Lock-Enabled
POST/PUT /v1/{account}/{container}/{object} 需要额外的头部用于锁定，与 S3 匹配
- X-Object-Lock-Mode, X-Object-Lock-Days, X-Object-Lock-Years, X-Object-Lock-Enabled
- X-Object-LegalHold-Enabled（用于法律保留，这除了保留期限之外）
GET /v1/{account}/{container}/{object} 需要额外的头部用于读取当前状态
- X-Object-Lock-Mode, X-Object-Lock-LockedUntil, X-Object-Lock-Enabled
- X-Object-LegalHold-Enabled（用于法律保留，这除了保留期限之外）

请注意，对象读取返回 X-Object-Lock-LockedUntil 而不是保留期限，因为保留期限是相对于对象被锁定的时间点而言的。它也可以返回对象锁定开始日期和保留期限，但感觉 LockedUntil 通常更有用。

S3 期望存在某些额外的角色用于模式和法律保留。这些应该可配置为特定的 Keystone 角色，也许通过策略。

Swift 不会将元数据更新同步写入对象的每个副本，而是采用最终一致性。这意味着设置在现有对象上的对象锁定不会立即应用于所有副本，因此某些服务成员会允许某些 DELETE 操作。由于这是 Swift 元数据的工作核心，该提案不会尝试更改它。

如果容器上设置了锁定策略，则锁定应始终在创建时写入所有副本，因此不应存在任何具有不一致元数据的副本。

总而言之，我们预计写入后锁定将仅是最终一致的，而创建时锁定（来自容器设置）应该没有任何延迟的一致性。