yahoo-eng-team team mailing list archive

[Morgan Fainberg <morgan.fainberg@xxxxxxxxx>]

With regards to using "memcached" backend, there isn't a whole lot we
can do to prevent this. There are initiatives to remove the persistence
of tokens completely (revocation events, and non-persistent tokens).

I don't see how Keystone can otherwise address a fundamental issue with
the persistent store for tokens / revocation list.

I am marking this as Invalid as it is not something we directly can
address.  It would be possible (with the new dogpile system for KVS
token backends) to leverage Redis or other storage systems that
potentially have a disk-back to restore from when restarting the
external service.

** Changed in: keystone
       Status: Triaged => Invalid

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1182920

Title:
  restarting memcached loses revoked token list

Status in OpenStack Identity (Keystone):
  Invalid
Status in OpenStack Security Notes:
  Fix Released

Bug description:
  With the memcached backend to tokens, the revoked token list only
  lasts as long as the memcached server is up and running.  Thus, if the
  Keystone server is restarted, all token revocations are dropped, and
  they will not show up in later token revocation list requests.

  To reproduce:

  0.  Set up keystone using the memcached backend to tokens
  1. Create a token and ensure that it can be used via auth_token middleware
  2. Revoke the token
  3. fetch the revocation list and ensure that the token is listed
  4. restart Keystone
  5. fetch the revocation list and see that the token is not listed
  6. wait until the token revocation list has timed out and reissue request to a different remote service, token will be processed as valid.

  
  There are some mitigating factors.  Just submitting the revoked token to the same service after keystone has restarted will not show the error if the service is using memcached to hold the revocation list.  Restarting the memcache instance used by the remote server will dump the revocation list, and the problem will then appear.

  I have not yet verified this problem, but it follows from memcache.

  Keystone uses a local memcache instance.  If it were to be set up to
  use a remote memcache service, it would take restarting memcache to
  trigger the problem, and not keystone.

  This affects PKI tokens only.  UUID tokens are not affected:
  restarting memcached will drop them all, and they will report as
  invalid tokens.

  
  The KVS backend is affected as well.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1182920/+subscriptions