Keystone的服务器端架构

个人专题目录

---

一、Keystone的服务器端架构

• Keystone的服务器端提供了一些Restful API

二、客户端发送HTTP请求流程

• 客户端创建一个Keystone Client对象，其实就是一个HTTP Client对象
• 直接请求服务器端的Restful API

三、Keystone提供的几种用户认证形式

• admin_token方式认证-这种认证定义在admin_token_auth过滤器中。
• 用户名密码方式认证：
• 本地认证
• Token认证
  服务器端和客户端都会缓存用户的token
• 外部认证
  提供了两种token格式，UUID和PKI。

OpenStack 发展至今，共产生了 UUID、PKI、PKIZ、Fernet 四种 Token。下面将分别介绍这四种 Token。

UUID

OpenStack D 版本之初，仅有 UUID 类型的 Token 可供使用。UUID Token 是一个长度固定为 32 Byte 的随机字符串，通过 uuid.uuid4().hex 生成。

1546422819324.png

UUID Token 虽然简单易用，但是很容易产生性能问题。由于 UUID Token 不携带其他信息，OpenStack API 收到该 Token 后，既不能判断该 Token 是否有效，也无法得知该 Token 携带的用户信息。从上图中可以看出，每当 OpenStack API 接收到用户的请求，就需要向 keystone 验证该 Token 的有效性，并获取用户信息。

UUID Token 简单易用，不携带其他信息，因此 keystone 必须实现 Token 的存储和认证。随着集群规模扩大，Keystone 成了最大的性能瓶颈。

另外，Keystone 不限制用户产生的 Token 数量，大量的 Token 会永久保留在数据库中。当用户频繁发出请求时，Token 的数量增长非常迅速，可以达到几十万条，直接降低 Token 的验证效率。在 Havana 版本中，Keystone 提供 keystone-manage token-flush 命令来清理过期的 Token。并且将 Token 的默认有效时间缩短为一个小时（此前为24小时），避免在大量请求的情况下，数据库中的 Token 太多而影响整个系统的性能。

我们也可以通过一些措施来提高 Keystone 的性能， 例如优化 mysql，使用 memcached 来代替数据库存储 UUID Token，使用 Apache server 来部署 Keystone 等等。这些措施对于单个 Region 和小规模部署的 OpenStack 环境是有效的，但是面对大规模部署，或者是多个 Region 部署，Keystone 将奔溃。主要有两个原因：

• Keystone 对处理多个并发请的性能低下
• UUID Token 在不同 Region 之间存在同步问题

PKI

于是，从 Folsom 版本开始， 社区提出了 PKI(Public Key Infrastructure) Token，并在 Grizzly 版本中全面支持。在阐述 PKI Token 前，先了解一下公开密钥加密(public-key cryptography)和数字签名。

• 公开密钥加密，也称为非对称加密(asymmetric cryptography，加密密钥和解密密钥不相同)。在这种密码学方法中，需要一对密钥，分别为公钥(Public Key)和私钥(Private Key)，公钥是公开的，私钥是非公开的，需用户妥善保管。
• 数字签名又称为公钥数字签名，首先采用 Hash 函数对消息生成摘要，摘要经私钥加密后称为数字签名。接收方用公钥解密该数字签名，并与接收消息生成的摘要做对比，如果二者一致，便可以确认该消息的完整性和真实性。

PKI 使用密钥对来实现服务本身的离线认证，Keystone 用私钥对 Token 进行数字签名，各个 API server 用公钥在本地验证该 Token。离线认证步骤如下：

1. Keystone 服务器生成一对密钥，对于 OpenStack 中的服务，每个服务都会拥有一份 Keystone 的公钥，废弃名单和 CA 证书。
2. 当 Keystone 接收到生成 Token 的请求，会创建 json 格式的对象，该对象包含了用户所授权的用户组、服务目录和 meta data 等信息。
3. Keystone 会对这个 json 使用签名证书和私钥来签名和编码，生成 CMS 格式的Token。值得注意的是，在这个过程中，并没有对 Token 进行加密，如果此时 Token 在传输过程中被黑客截取，用户信息将会暴露。
4. 用户可以使用这个 Token 来请求操作。

如下图所示:

1546423060445.png

例如用户使用 Token 来请求 Nova 服务创建虚拟机。Nova 在收到 API 请求后，会对 PKI Token 进行解码，拿到编码前的 json 对象。在这个对象里已经包含了 Token 的有效期及其它相关信息，因此 Nova 不需要再请求 Keystone 来验证这个 Token，从而实现离线的验证。

1546423119532.png

和 UUID 相比，PKI Token 携带更多用户信息的同时还附上了数字签名，以支持本地认证，从而分流了 Keystone 服务的工作负载。但这种 Token 格式也存在两个较大的问题。

• PKI Token 本身的性能问题。通过 OpenStack wiki 上的 KeystonePerformance 一文可以看出，PKI 的性能是低于 UUID 的，尤其是对于创建 Token 的压力测试情景。
• PKI Token 的长度问题。PKI 编码和签名方式是基于整个 json 对象的，如果在服务目录里 endpoint 比较多的情况下，获取到的 Token 会轻松超过 8K。而 HTTP header 的长度是有限制的，Apache 服务的长度限制是 8K，如果使用 haproxy 做负载均衡，haproxy 默认支持 4K。可以通过重新编译 Apache 或者 haproxy 来增加更长的 header，但并不能解决根本问题。

除此之外，PKI Token 还有和 UUID Token 同样的问题，就是 Token 的持久化带来的对系统性能的开销，以及在多个 Region 部署时 Token 同步所带来的系统设计复杂性的开销。

PKIZ

PKIZ 在 PKI 的基础上利用 zlib 对 Token 进行压缩处理，但是压缩的效果极其有限，一般情况下，压缩后的大小为 PKI Token 的 90% 左右，所以 PKIZ 并不能友好的解决 Token size 太大问题。

Fernet

前三种 Token 都会持久性存于数据库，与日俱增积累的大量 Token 引起数据库性能下降。为了避免该问题，社区在 Kilo 版本提出了 Fernet Token，它携带了少量的用户信息，采用了对称加密，无需存于数据库中。

Fernet 是专为 API token 设计的一种轻量级安全消息格式，不需要存储于数据库，减少了磁盘的 IO，带来了一定的性能提升。并且可以通过使用 Key Rotation 更换密钥来提高安全性。

• Fernet Token 使用 Fernet 标准。Fernet 是一种采用 Cryptography 对称加密库（symmetric cryptography，加密密钥和解密密钥相同）方法的认证系统实现，广泛应用于 Heroku 项目。简单来说，Fernet 使用 AES-CBC 来加密并使用 SHA256 散列函数来签名用户提供的信息，其中包含了加密时的时间戳信息。这个 Token 中所包含的信息只能使用加密和签名时使用的 Key 来读取和更改。
• Keystone 中的 Fernet Token 不使用任何持久化的后端。相反，对于多个 Keystone 节点的部署，只需要将相同的 Key 同步到所有的 Keystone 节点上，然后无论通过哪个节点所生成的 Token，都可以被其他 Keystone 节点所验证。

1546423161414.png

最后，Fernet Token 只加密必要的信息，长度一般不超过 255Byte，从而避免了 Token 过大的问题。

四、访问Openstack服务的流程

访问其他服务（如Cinder、Nova）的流程大致如下

• 创建Keystone Client对象。通过Keystone Client对象向Keystone服务器发送认证请求，申请用户Token。在用户Token中，可以提取Token ID和服务目录。
• 创建需要访问的Openstack组件的相应Client对象（如果需要访问Glance服务，则创建Glance Client对象）。根据Token中的服务目录，设置Client对象的endpoint等信息
• 当Client对象向Openstack服务发送HTTP请求时，OpenStack服务会通过auth_token过滤器向Keystone服务器发送认证请求。如果认证成功，OpenStack再调用相应的方法处理用户请求。

五、参考

https://blog.csdn.net/nirendao/article/details/78868633