Open Stack

On Thu, Sep 25, 2014 at 3:21 PM, Ved Lad <vedlad at gmail.com> wrote:

> The Openstack installation (Havana) at our company has a large number of
> service endpoints in the catalog. As a consequence, when using PKI tokens,
> my HTTP request header gets too big to handle for services like neutron. Im
> evaluating different options for reducing the size of the catalog in the
> PKI token. Some that I have found are:
>
> 1. Using the per tenant endpoint filtering extension: This could break if
> the per tenant endpoint list gets too big
>

In Juno, there's a revision to this which makes the management easier:


https://blueprints.launchpad.net/keystone/+spec/multi-attribute-endpoint-grouping


>
> 2. Using PKIZ Tokens(In Juno): Were using Havana, so I cant use this
> feature, but it still doesnt look scalable
>

You're correct, it's a step in the right direction that we should have
taken in the first place, but it's still going to run into the same problem
with (even larger) large catalogs.


>
> 3. Using the ?nocatalog option. This is the best option for scalability
> but isnt the catalog a required component for authorization?
>

The catalog (historically) does not convey any sort of authorization
information, but does provide some means of obscurity. There's been an
ongoing effort to make keystonemiddleware aware of the endpoint it's
protecting, and thus the catalog becomes pertinent authZ data in that
scenario. The bottom line is that the ?nocatalog auth flow is not a
completely viable code path yet.


>
> Are there any other solutions that i am unaware of, that scale with number
> of endpoints?
>

Use UUID tokens, which Keystone defaults to in Juno for some of the same
pain points that you're experiencing. UUID provides the same level of
security as PKI, with different scaling characteristics.


>
> Thanks,
> Ved
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140925/719cc4b8/attachment.html>