On 10/15/2013 01:20 PM, Bhuvan Arumugam wrote:
On Mon, Oct 14, 2013 at 7:20 PM, Jamie Lennox <jamielen...@redhat.com
<mailto:jamielen...@redhat.com>> wrote:
On Mon, 2013-10-14 at 18:36 -0700, Bhuvan Arumugam wrote:
> Just making sure i'm not the only one facing this problem.
> https://bugs.launchpad.net/nova/+bug/1239894
Yep, we thought this may raise some issues but insecure by default was
just not acceptable.
I think we should document it.
We are working on updating the docs. We would be appreciate you lending
a hand in documenting it.
> keystoneclient v0.4.0 was released last week and used by all
openstack
> services now. The insecure=False, as defined in
> keystoneclient.middleware.auth_token. The keystone client is
happy as
> long as --insecure flag is used. There is no way to configure it in
> other openstack services like nova, neutron or glance while it is
> integrated with self-signed keystone instance.
I'm not following the problem. As you mentioned before the equivalent
setting for --insecure in auth_token is setting insecure=True in the
service's config file along with all the other keystone auth_token
settings. The equivalent when using the client library is passing
insecure=True to the client initialization.
Yep, the problem is solved after setting this flag in
[filter:authtoken] section in /etc/nova/api-paste.ini.
No, the problem is kicked under the carpet. We cannot support insecure
by default. Doing certificates even for development is not that
difficult. We have patches up for review in Devstack etc to support this.
https://review.openstack.org/#/c/47076/
But it is still having Jenkins issues.
> We should introduce new config parameter keystone_api_insecure and
> configure keystoneclient behavior based on this parameter. The
config
> parameter should be defined in all other openstack services, as
all of
> them integrate with keystone.
A new config parameter where? I guess we could make insecure in
auth_token also response to an OS_SSL_INSECURE but that pattern is not
followed for any other service or parameter.
I think we are inconsistent in using this flag for different services.
For instance, we use:
neutron_api_insecure
glance_api_insecure
for keystone, we use:
insecure=True
I think it's reasonable as one way or the other, it's configurable.
We'll be good if we document it somwhere here.
http://docs.openstack.org/developer/python-keystoneclient/using-api.html
> Until it's resolved, I think the known workaround is to use
> keystoneclient==0.3.2.
>
>
> Is there any other workaround for this issue?
Signed certificates.
Oh yeah! we use signed cert in our prod environment. This one is our
test bed.
I'd like to move toward using certmonger for the client side of
certificate management and certmaster as a simplistic CA
https://fedorahosted.org/certmonger/
https://fedorahosted.org/certmaster/
Thank you,
--
Regards,
Bhuvan Arumugam
www.livecipher.com <http://www.livecipher.com>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
