Open Stack

Hi Joe,

Just to be clear, my interpretation of what Adam is proposing is that
unless an organizations CA is specified, Keystone will create a self-signed
SSL environment for itself. Totally OK with me.

This is how Puppet works in a client/server setup and I quite like it a
lot. It places more emphasis on the fact that communication is secure than
the (potential) hassle of configuring the environment with your existing
SSL infrastructure and ensuring all communication points are compatible
with that.

This is just my opinion, though. While my organization does use our own key
and CA for certain certs, it's not enough to warrant that they are used for
every SSL implementation. I'd love to hear what others think -- especially
those in larger SSL environments.

Joe



On Sat, Oct 27, 2012 at 2:41 PM, heckj <heckj at mac.com> wrote:

> Adam posted this thread to the OpenStack-dev mailing list, but since some
> of the context here is what (simple) tooling requirements should exist for
> establishing SSL certs within the confines of various CA mechanisms, I
> thought it would be good to get some input from the broader operator
> community.
>
> The last paragraph being the one with relevant questions:
>
> > We can generate a csr based on the hostname of the machine,
> > and that way we know that the certificate is formatted for SSL, but is
> it really
> > better to write a tool to do this (it is goingto be done once very year
> or there
> > about) or just point the users at decent documentation about how to do it
> > themselves?
> ...
>
> The whole message:
>
>
> > -----Original Message-----
> > From: Adam Young [mailto:ayoung at redhat.com]
> > Sent: Friday, October 26, 2012 6:17 PM
> > To: OpenStack Development Mailing List
> > Subject: [openstack-dev] SSL and devstack
> >
> > Although SSL in Python is slow, we really should enable it in devstack
> from
> > here on out.  My understanding is that people with live deployments front
> > Keystone with some other SSL terminator.  We should thus plan on running
> > the python-keystoneclient code through SSL by default to make sure all
> SSL
> > issues are shaken out.
> >
> > If you run keystone-manage --pki_setup  it generates a CA certificate for
> > you.  This is done by default in devstack, in order to get pki tokens to
> work.
> > However, there are no SSL certifcates provided.  The config documentation
> > states: "a set of sample certficates is provided in the examples/ssl
> directory
> > with the Keystone distribution for testing."  However, it uses a
> different CA
> > than the one in the test/signing, so there is no one set of certificates
> we can
> > provide.
> >
> > I think I would like to add an additional option to the keystone-manage
> > CLI: --ssl_setup. What I would like to do is gather what the
> requirements for
> > this should be.  To start:
> >
> > 1. If no CA is in the path indicated by the config file, generate a self
> signed
> > one.  The assumption is that this code will be common between pki and ssl
> > setup.
> > 2. Use the CA from the above path to sign the ssl certificate.
> >
> > I am assuming that most organizations large enough to have Open Stack
> have
> > their own Public Key Infrastructure.  Thus, the self signed CA and SSL
> cert
> > should not be the norm.  WHat I am wondering is if there is anything we
> > should be doing.  For those cases.  There is no standard for remotely
> > submitting a Certificate Signing Request (CSR) and getting back a signed
> > certificate.  We can generate a csr based on the hostname of the machine,
> > and that way we know that the certificate is formatted for SSL, but is
> it really
> > better to write a tool to do this (it is goingto be done once very year
> or there
> > about) or just point the users at decent documentation about how to do it
> > themselves?
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>



-- 
Joe Topjian
Systems Administrator
Cybera Inc.

www.cybera.ca

Cybera is a not-for-profit organization that works to spur and support
innovation, for the economic benefit of Alberta, through the use
of cyberinfrastructure.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20121028/93138d5d/attachment.html>