Open Stack

Hi Jamie,

Glance has another way of specifying the swift credentials for the single
tenant store which may (?) be useful here.

In glance-swift.conf you can specify something like:

[ref1]
user = tenant:user1
key = key1
auth_address = auth123 at example.com

which means that in the database 'ref1' is stored instead of the
credentials: the location ends up looking something like:

swift+config://ref1@swift/container/object

The swift+config schema is used to indicate the real creds should be
fetched from the config file. (This avoids having to put them in the
database which isn't desirable and complicates password changing.)

We'd have to think about corner cases (I think --copy-from should be ok).

-Stuart

> Hey everyone,
>
> TL;DR: glance_store requires a way to do v3 authentication to the swift backend.
>
> The keystone team is making a push to properly deprecate the v2 authentication APIs this cycle. As part of that we have a series of devstack reviews that moves devstack over to only using v3 APIs[1] and an experimental gate job that runs devstack with the keystone v2 api disabled.
>
> The current blocker for this gate job is that in glance's single-tenant swift backend mode the config options only allow v2 authentication.
>
> Looking at glance store the username and password are stored as part of the location parameter in the form:
>
> swift://username:project_name:password@keystone/container
>
> even though devstack is still using the (deprecated?)
>
> swift_store_user = username:project_name
> swift_store_key = password
> swift_store_container = container
>
> I don't know how this relates to swift_store_config_files.
>
> There is support for v3 in swiftclient (though it's kind of ugly), to do v3 authentication i have to do:
>
> c = swiftclient.Connection(authurl='http://keystoneurl:5000/v3',
>                           user=username,
>                           key=password,
>                           auth_version='3',
>                           os_options={'project_name': project_name,
>                                       'project_domain_id': 'default',
>                                       'user_domain_id': 'default'})
>
> However in future we are trying to open up authentication so it's not limited to only user/password authentication. Immediate goals for service to service communications are to enable SSL client certificates and kerberos authentication. This would be handled by keystoneclient sessions but they are not supported by swift and it would require a significant rewrite of swiftclient to do, and the swift team has indicated they do not which to invest more time into their client.
>
> This leads me to my question: How do we support additional authentication parameters and in future different parameters?
>
> We could undo the deprecation of the config file specified credentials and add the additional options there. This would get us the short term win of moving to v3 auth but would need to be addressed in future for newer authentication mechanissms.
>
> I wrote a blog a while ago regarding how sessions supports loading different types of authentication from conf files[2], however as swiftclient doesn't support this the best it could do is fetch a url/token combo with which glance could make requests and it would have to handle reauthentication and retries somewhat manually. I actually think rewriting the required parts of the client wouldn't be too difficult, the problem then is whether this should live in glance or in swiftclient. This would also involve credentials in the config file rather than the location option.
>
> I'm not overly familiar with glance_store so there may be other options or what i've suggested may not be possible but I'd love to hear some opinions from the glance team as this is quickly becoming a blocker for keystone.
>
>
> Thanks,
>
> Jamie
>
>
>
> [1] https://review.openstack.org/#/c/186684/
> [2] http://www.jamielennox.net/blog/2015/02/17/loading-authentication-plugins/