Restarting memcached loses revoked token list
---

### Summary ###
When a cloud is deployed using Memcached as a backend for Keystone
tokens, there is a security concern that restarting Memcached will lose
the list of revoked tokens, potentially allowing bad tokens / users to
access the system after they had been revoked.

### Affected Services / Software ###
Keystone, Memcached, Havana, Icehouse, Juno

### Discussion ###
The list of revoked tokens, stored in Memcached could be lost if the
Memcached service is stopped or crashes before the revocation list is
persisted on disk.

There might be ways to mitigate this issue in the future, such as
running Memcached on multiple machines to ensure redundancy should the
Keystone server fail. In a clustered environment, it will only be an
issue if all of the Memcached machines shutdown. This would require
replication of data between the Memcached backends, which is not
possible with Keystone today.

Memcachedb might also be a potential way to mitigate this issue:

  http://memcachedb.org/

NOTE: Some deployments may intentionally flush Memcached in response to
https://bugs.launchpad.net/ossn/+bug/1179955 - please exercise caution
when considering how to approach this problem.

### Recommended Actions ###
This is a fundamental problem with using in-memory ephemeral storage for
security information. If your deployment has strong security
requirements or a reliance on up-to-date revoked token information, we
suggest you consider using an on-disk DB such as MySQL / PostgreSQL or
perhaps look into Memcachedb.

### Contacts / References ###
Author: Robert Clark, HP
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0034
Original LaunchPad Bug : https://bugs.launchpad.net/keystone/+bug/1182920
OpenStack Security ML : openstack-security@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg