Re: [openstack-dev] [glance] V3 Authentication for swift store
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 = auth...@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/
__
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
Re: [openstack-dev] [glance] V3 Authentication for swift store
- Original Message - From: stuart mclaren stuart.mcla...@hp.com To: openstack-dev@lists.openstack.org Sent: Thursday, 18 June, 2015 7:06:12 PM Subject: Re: [openstack-dev] [glance] V3 Authentication for swift store 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 = auth...@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 snip Interesting, this actually maps really closely with one of the concepts that loading auth plugins from conf already provides. You can say [keystone_authtoken] auth_section = ref1 ... [ref1] auth_plugin = password auth_url = ... username = ... ... So that you can share or separate auth. We can probably leverage something similar here. Is this the correct way to configure glance? Would i be working on a deprecated section of code to make this support plugins? I can't really tell what is recommended from the code. So the question still comes down to fix it properly or get it working. If we configure glance this way i can add user_domain_id, user_domain_name, project_domain_id, project_domain_name to the variables that are read from [ref1] and get v3 support for user/pass that way fairly easily. To move to fully loading auth_plugins we would need to either get swiftclient support for sessions or move to using the HTTP API directly. I'm inclined to just patch it in for now, work on getting swiftclient session support and then use that when ready. Would this be ok? Jamie __ 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-dev] [glance] V3 Authentication for swift store
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/
__
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
