非持久化令牌

随着撤销事件系统的添加,现在可以实现一个不需要根据令牌内的数据查找令牌 ID 的令牌提供程序(例如,撤销签发给特定用户 ID 的所有令牌)。新的撤销事件使用来自一类令牌的数据值(例如,用户 ID、域 ID、项目 ID)来确定令牌是否被撤销,而不是依赖于 Keystone 生成的显式令牌 ID 列表。新的撤销匹配是在每个令牌的 auth_token 中间件中执行的,而不是在 Keystone 中生成被撤销的令牌 ID 列表。

bp 非持久化令牌

问题描述

目前,管理令牌数据的持久化后端存在显著的开销。这种管理和性能开销表现为多种方式

  • SQL 后端数据库中出现显著的膨胀,导致性能下降,显著消耗处理和存储资源。

  • Memcached(以及大部分键值存储后端)在处理令牌撤销列表下的每个用户的令牌枚举方面表现不佳。即使使用撤销事件,后端存储的开销也可能很大,但提供的附加价值却很少。

提议的变更

更改将消除持久化令牌到任何形式的稳定存储的需要。在使用新的非持久化令牌提供程序时,UUID 和短哈希版本的 PKI 令牌将不受支持。UUID 和标准的 PKI 令牌提供程序在 Juno 开发周期内不会被弃用。原始 PKI 令牌提供程序(PKI 和 PKIZ)的弃用将最早在 K 周期发生;这种弃用延迟允许操作员和部署者在非持久化令牌成为默认部署模型之前采用新的非持久化令牌。UUID 令牌提供程序将根据继续使用 UUID 而不是 PKI 令牌的部署数量进行评估是否弃用。

备选方案

  • 可以使用对存储后端驱动程序的增量改进来代替非持久化令牌。但是,这些增量改进不会减轻管理或资源开销,就像根本不需要令牌持久化一样简单。从长远来看,这些增量改进将推动非持久化令牌,因为这成为最简单/最易于维护的解决方案(没有后端存储中数据丢失或数据损坏的风险,没有长期的内存/存储开销等)。

  • 扩展有效令牌的重用。目前提倡尽可能重用令牌,但是,在许多情况下,令牌重用没有实现、实现不佳或部分实现。即使使用可靠的令牌重用,管理持久化后端的膨胀和开销也不会消除。

数据模型影响

令牌的通用数据模型(内存中)将更改为与令牌版本无关的内存结构。这将与当前使用的 Python 字典不同(并且结构因令牌版本而异)。这种更改将消除一些用于支持不同令牌版本的复杂条件代码。对令牌的内存结构进行更改是为了确保代码易于理解,而不是拥有一个不断扩展的条件代码集来处理跨越来越多的版本令牌结构的变体。v2 和 v3 令牌具有显著的结构差异,在消除对 .get_token 的调用时,这将给代码库带来重大复杂性。

新的内存令牌模型将尽可能地序列化为 SQL 令牌后端的模式,以消除数据库迁移的需要。其他令牌持久化后端将对不同的令牌格式进行原地(无缝)处理。为了实现无缝升级到非持久化令牌,需要进行持久化后端更改。

需要为每个令牌版本开发 JSON 模式,以便在从版本化令牌格式转换为内部令牌对象时进行完整的验证。

REST API 影响

当使用新的提供程序(非持久化令牌提供程序)时,将仅签发 PKI 令牌,并且令牌的短哈希版本不能用于与 Keystone 交互。

直接处理令牌资源的 REST API 将被修改

  • V2.0 令牌 API 如果使用短哈希 ID,将返回 TokenNotFound(HTTP 404)。这将影响令牌 API 的 HTTP GET、HEAD 和 DELETE(验证、检查、撤销)。

  • V3 API 如果使用令牌短哈希,将引发 Forbidden(HTTP 403)。这与在短哈希 ID 中使用 X-SUBJECT-TOKEN 标头一致。

  • 基于从 X-AUTH-TOKEN 标头中的令牌派生的数据执行策略强制的 API,如果使用短哈希 ID,将返回适当的 401(无效令牌)(与使用任何无效令牌的结果相同)。

安全影响

内部令牌格式将更改为保持一致。外部面向和令牌的格式不受影响。

所有 PKI 令牌的情况都将在内存中解码(类似于 auth_token 中间件),而不是引用存储在令牌数据库持久化存储中的数据。将不再可使用令牌后端进行审计。相反,审计将完全依赖于 CADF 身份验证通知。

通知影响

其他最终用户影响

性能影响

一般来说,这种更改应该通过不需要持久化令牌数据来减少系统负载和资源消耗。令牌需要通过 CMS 解码,从而提高处理 GET 和 HEAD(验证和检查)机制的 CPU 成本,这些机制位于 v2.0 Identity API 中。这是由于数据没有存储在 PKI 签名令牌数据之外。

其他部署者影响

要利用非持久化令牌,部署者需要执行以下操作

  • 使用撤销事件而不是令牌撤销列表

    • auth_token 中间件需要配置为使用撤销事件。这将添加到 OpenStack 的部署文档中。不需要对 auth_token 中间件进行其他更改。

  • 将令牌提供程序设置为新的非持久化令牌提供程序

不会添加新的配置选项。

开发人员影响

所有对 token_api.get_token 的引用(不包括在 UUID token provider 中使用)都需要删除。在 PKI 令牌使用时,在不解码 PKI 令牌的情况下直接查找令牌数据将不可用。

对令牌数据的任何交互都将以一致的方式通过新的统一令牌对象完成,从而消除了对特定代码处理版本化令牌字典的需求。

实现

负责人

主要负责人

摩根·费因伯格 (mdrnstm)

其他贡献者

亚当·扬 (ayoung)

工作项

  • 令牌版本无关对象开发

  • 令牌验证/转换为新的令牌对象

  • Keystone AuthContextMiddleware 更新为始终对 PKI 令牌进行 CMS 解码。

  • 消除所有对 token_api.get_token 的调用,除了在使用 UUID 令牌提供程序时。

  • 实现非持久化 PKI 令牌提供程序

    • 需要代码来检测错误配置。非持久化令牌需要撤销事件并禁用按 ID 撤销。

    • 为 Keystone 实现新的统一配置错误异常。

    • 如果未启用撤销事件和/或启用了按 ID 撤销,将引发新的配置异常。

依赖项

测试

  • 需要一个 Tempest 场景来测试非持久化令牌提供程序的部署。

  • 需要单元测试来独立于 UUID 后端来测试非持久化提供程序。

  • 最初需要一个替代测试场景来验证非持久化令牌提供程序。一旦撤销事件成为默认部署方法,非持久化提供程序也应成为默认方法。

文档影响

需要包含有关使用撤销事件和非持久化 PKI 令牌提供程序进行部署的文档(配置更改)。

参考资料