Restarting memcached loses revoked token list ----- ### Summary ### When a cloud is deployed using Memcache 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, Memcache ### Discussion ### There might be ways to mitigate 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. Memcachedb might also be a potential way to mitigate. 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://bugs.launchpad.net/ossn/+bug/1182920 Blueprint : https://blueprints.launchpad.net/keystone/+spec/revocation-backend OpenStack Security ML : openstack-security at lists.openstack.org OpenStack Security Group : https://launchpad.net/~openstack-ossg
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack Post to : [email protected] Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
