OpenStack Keystone如何处理长时间操作过程中的token过期问题

背景介绍

本文梳理 Keystone 的 token 过期的处理方式。Token 是有期限的,而且不能延期,过期以后,身份验证就会被拒绝。这种设计是token安全性的要求。那么,如果用户通过验证以后,所执行的服务操作费时很长,中途再次需要使用用户的已过期的token,该怎么处理?

早期版本的Keystone是不支持这种情况的,一般通过其他的设计来绕开这一局限性,比如把过期时间设置得足够长等。这实际上降低了token的安全性。比如,Horizon的用户就会遇到由于token过期而导致被log out的情况。对于那些长时间使用Horizon的用户而言,这使得Horizon比“正常”的web应用要显得繁琐一些。 在服务之间调用时,这一问题更严重。比如,当用户调用Nova API创建一个服务器时,Nova需要调用Glance服务来得到镜像,需要调用cinder来创建磁盘等等,也就是服务之间需要调用。当用户使用了合法(未过期)的token调用了Nova API,而Nova在调用后续其他服务API时,如果操作时间很长,那么用户的Token可能会过期。早期的设计中,这种请求下请求会超时失败,而且很难意识到是由于token过期导致的。

好消息是这一问题已经解决了。在现在的设计中,Keystone会区分user token和service …

Continue Reading

Keystone Token revocation issues

Keystone的Token Revocation的实现方式是导致Keystone Token Validation变慢的根源。 由于所有的OpenStack API调用均需要Validate Token,这也将该问题扩大成整个OpenStack云平台的性能瓶颈之一。

在2016年7月22日的Openstack Digest, Vol 37, Issue 22中,来自Redhat的Luke Hinds提到了该问题可被利用来进行拒绝服务攻击(DoS)。 Revocation Event记录的保存时间是Token Expiration 加上Expiration Buffer。在默认配置下,其值为1.5小时。在这个时间段内, 一个合法的普通OpenStack用户可以不停地生成Token,然后revoke Token,从而生成大量的Revocation Event记录,拖慢Token Validation。

在Validate Token时对Revocation Event表的查询语句是:

Select <Column List> from Revocation_Event Order By Revoked_at

在用户不停地调用revoke Token的情况下,这样一个语句的结果是变化的,导致在数据库端和Keystone端的缓存都是会失效的。 当结果集足够大时,这一查询过程和结果数据传输过程都会变得很费时 …

Continue Reading