Re: [openstack-dev] [glance] V3 authentication to swift
Thanks for the heads up Jamie, I'll try to take a look. -Stuart Glancers, A while ago I wrote an email outlining a couple of ways we could support keystone v3 authentication when using swift as a backend for glance_store. In the long term it would be best to transition swiftclient to use sessions as this would allow us to do more extensive (kerberos, ssl etc) authentication in the future, however this is a longer term plan that requires a lot of effort and coordination. For right now glance-swift is the last piece of devstack that only works with v2 authentication[1] and with a relatively small amount of code we can support v3 username/password which is by far the most common scenario. I've been prompting for a while on IRC however can I please request some reviews of https://review.openstack.org/#/c/193422/ as it has now become a blocker for the v3 authentication effort. Thanks for your help, Jamie [1] Note, that by this i mean that with v2 keystone disabled glance-swift communication is the last thing in the standard devstack gate path that can't be configured to v3. It does not mean that tempest will succeed or that all of OpenStack is v3 compatible just that we can start running meaningful gate jobs. __ 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 to swift
Glancers, A while ago I wrote an email outlining a couple of ways we could support keystone v3 authentication when using swift as a backend for glance_store. In the long term it would be best to transition swiftclient to use sessions as this would allow us to do more extensive (kerberos, ssl etc) authentication in the future, however this is a longer term plan that requires a lot of effort and coordination. For right now glance-swift is the last piece of devstack that only works with v2 authentication[1] and with a relatively small amount of code we can support v3 username/password which is by far the most common scenario. I've been prompting for a while on IRC however can I please request some reviews of https://review.openstack.org/#/c/193422/ as it has now become a blocker for the v3 authentication effort. Thanks for your help, Jamie [1] Note, that by this i mean that with v2 keystone disabled glance-swift communication is the last thing in the standard devstack gate path that can't be configured to v3. It does not mean that tempest will succeed or that all of OpenStack is v3 compatible just that we can start running meaningful gate jobs. __ 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
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