af3baa14fc
A handful of previously published OSSNs were never migrated to our git repo or publishing area on the wiki. This adds the existing notes to the git repo. A few updates have been made to the original notes to follow the current formatting standards, correct typos, add affected release info, and other similar changes. Change-Id: I50d0d37f51350a2c0bd3e8096f1f856fe424904c
45 lines
1.8 KiB
Plaintext
45 lines
1.8 KiB
Plaintext
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 ###
|
|
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
|