Compacting PKI Token in keystone

Atsuko Ito

on LinkedIn

PKI tokens was too fat in big clouds, and it was a real PITA. I've replaced it with Fernets, but here is a story behind it.

Problem

Let’s see the scenario:

  1. User opens console, sources openrc and issues any nova (for example) command
  2. novaclient asks for the token via python-keystoneclient

  3. User has got this token, here is POST /v2.0/tokens response:

    { "access": { "token": { "issued_at": "2014-05-30T12:16:19.582411", "expires": "2014-05-31T12:16:19Z", "id": "token", "tenant": { "description": "", "enabled": true, "id": "659f2aeaea5a43e18abea1a598557f24", "name": "devel" } }, "serviceCatalog": [ ... ], "user": { "username": "yottatsa", "roles_links": [], "id": "20613f973ead4ecab32ad47a24fddfe6", "roles": [ { "name": "admin" } ], "name": "yottatsa" }, "metadata": { "is_admin": 0, "roles": [ "54178770527648468a02f1bf1d0cfc09" ] } } }

  4. novaclient extracts compute endpoint from supplied serviceCatalog

  5. Let’s pretend we’re using PKI tokens for the large cloud
  6. novaclient builds requests to nova-api
  7. It fails because of header size if you cloud is large enough

We have no any approach to use OpenStack with more than N regions

Why?

  1. Token compression isn't ready yet, and IMHO it is not worth the effort that had been made for. It's easier to enlarge your MAX_HEADER_SIZE instead.
  2. UUID token loads keystone
  3. Optional catalog has been implemented only in keystoneclient's middleware, so we can’t just use it for end user clients.

Plus. Some services like is trying to proxy your requests to another services. Like nova proxying cinder. There are some tests and bug about it.

Nova is relying on X-Service-Catalog WSGI header in nova/api/auth.py, which is marked as optional in keystoneclient's auth_token.py. So we could run into EndpointNotFound if we remove service catalog.

Solution

First idea was: let’s remove service catalog from signed part, so it will be much smaller, which I had done. It made some problems, which exactly the same with this bug, so there I’ve got a hint from Dolph Mathews, he said:

the long term goal with removing the service catalog from the token also included a new endpoint on keystone to fetch a catalog, e.g. GET /v3/catalog separately from the token. When presented with a catalog-free token, keystoneclient.middleware.auth_token could call GET /v3/catalog and populate the X-Service-Catalog header as usual.

So I did this too. Here it is, patch for catalog repopulation and patch to remove a catalog. And here is a blueprint.

What’s next: