Jump to: navigation, search

OSSN/OSSN-0034


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:


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

Retrieved from "https://wiki.openstack.org/w/index.php?title=OSSN/OSSN-0034&oldid=128798"