Tech Debt: Change to use keystone v3 uuid auth tokens

[Adrian Otto]

Keystone v3 tokens are of unbounded length. They contain an encrypted/signed version of the auth token, and all the system endpoints. As the catalog grows, so does the token length. This is problematic for OpenStack services like swift that wish to enforce a header length maximum, because there is no sensible maximum length that would work for all possible lengths of the auth token. We ran into the problem while implementing this patch[1]. We worked around it by temporarily increasing the default header size used for swift in devstack[2]. Using a UUID as a keystone v3 token, and relying on services to call back to keystone to check for the related information is a better solution to keep request headers small. The default Keystone token provider is pki, but it can be changed to uuid using a configuration directive[3]. Adding support for this in swift is in-progress[4] and has some security drawbacks[5] that we will need to be sure are addressed prior to implementing this change.

The default size of 8192 Bytes[2] is still not enough for solum.

[1] https://review.openstack.org/92171 Update status and reason in conductor method.
[2] https://review.openstack.org/66615 Fix Error 400 Header Line Too Long
[3] https://github.com/openstack/keystone/blob/master/etc/keystone.conf.sample#L1266 Keystone Token Provider
[4] https://blueprints.launchpad.net/swift/+spec/keystone-v3-support Add support for authentication using keystone v3 API
[5] https://bugs.launchpad.net/swift/+bug/1299146 keystoneauth middleware not domain aware (keystone v3 issue)

[Simon Mazas (simon-mazas)]

I got 2 questions before trying to fix this :

1 - Are security drawbacks[5] need to be resolved before fixing this bug ?
Currently the drawbacks are in progress on swift repo, so we can consider we're sure they are addressed. But I'm still not sure if the bug (our) can be fix by now.

2 - Is the fix about setting uuid instead of 16384 in devstack config ?

Thanks

[Adrian Otto (aotto)]

Simon,

There are two new Keystone features that effectively mitigate this bug:

1) Token compression support in python-keystoneclient that makes the tokens about 1/8 of the previous length.

2) Service catalog filtering. We can m4ake requests to Keystone for Auth tokens that do not include the service catalog. We can get a normal token and cache the catalog content, and then a small token that does not include the catalog, and use the small version when sending API requests.

Using these new features in combination will allow us to continue using the pki token provider. We just learned about these features at the OpenStack summit last week.

I would like to continue using the pki token provider, but use compressed keys and catalog filtering.

Adrian

[Adrian Otto (aotto)]

We do not need to wait for any swift security changes to resolve this.

[Adrian Otto (aotto)]

Apparently we get token compression by default, so this task has no tangible value to us now. My request is hereby withdrawn.