On 03/16/2015 05:33 AM, joehuang wrote:
[Topic]: Huge token size
Hello,
As you may or may not be aware of, a requirement project proposal
Multisite[1] was started in OPNFV in order to identify gaps in
implementing OpenStack across multiple sites.
Although the proposal has not been approvedyet, we’ve started to run
some experiments to try out different methods. One of the problem we
identify in those experiments is that, when we want to use a shared
KeyStone for 101 Regions ( including ~500 endpoints ). The token size
is huge (The token format is PKI), please see details in the attachments:
token_catalog.txt, 162KB: catalog list included in the token
token_pki.txt, 536KB: non-compressed token size
token_pkiz.txt, 40KB: compressed token size
I understand that KeyStone has a way like endpoint_filter to reduce
the size of token, however this requires to manage many (hard to id
the exact number) endpoints can be seen by a project, and the size is
not easy to exactly controlled.
Do you guys have any insights in how to reduce the token size if PKI
token used? Is there any BP relates to this issue? Or should we fire
one to tackle this?
Right now there is an effort for non-multisite to get a handle on the
problem. The Fernet token format will make it possible for a token to
be ephemeral. The scheme is this:
Encode the minimal amount of Data into the token possible.
Always validate the token on the Keystone server.
On the Keystone server, the token validation is performed by checking
the message HMAC, and then expanding out the data.
This concept is expandable to multi site in two ways.
For a completely trusted and symmetric multisite deployement, the
keystone servers can share keys. The Kite project was
http://git.openstack.org/cgit/openstack/kite origianlly spun up to
manage this sort of symmetric key sharing, and is a natural extension.
If two keystone server need to sign for and validate separate serts of
data (future work) the form of signing could be returned to Asymmetric
Crypto. This would lead to a minimal tokne size of about 800 Bytes (I
haven't tested exactly). It would mean that any service responsible for
validating tokens would need to fetch and cache the responses for things
like catalog and role assignments.
The epehemeral nature of the Fernet specification means that revocation
data needs to bepersisted separate from the token, so it is not 100%
ephemeral, but the amount of stored data should be (I estimate) two
orders of magnatude smaller, maybe three. Password changes, project
deactivations, and role revocations will still cause some traffic
there. These will need to be synchronized across token validation servers.
Great topic for discussion in Vancouver.
[1]https://wiki.opnfv.org/requirements_projects/multisite
Best Regards
Chaoyi Huang ( Joe Huang )
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
