Open Stack

On 10/15/2013 01:20 PM, Bhuvan Arumugam wrote:
>
> On Mon, Oct 14, 2013 at 7:20 PM, Jamie Lennox <jamielennox at redhat.com 
> <mailto:jamielennox at 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 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/20131015/bc46e994/attachment.html>