Open Stack

Hi Rob,

We quickly discussed your ephemeral CA idea this morning and like it. We also realize that it will take a lot of work to make it happen. At this point in time we are attempting to simply add some form of SSL to a cloud installed with TripleO. We lost all of our previous installation tools and are essentially starting from ground zero. The TripleO community does not have a solution in place so we are all learning how to build ISOs and what files to add/modify to install SSL. Due to our short deadlines we will not be able to push our changes up through the community in time so we may have some throw away work once the community catches up.

Mark

-----Original Message-----
From: Clark, Robert Graham 
Sent: Friday, May 02, 2014 7:12 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] Security audit of OpenStack projects

> -----Original Message-----
> From: John Dennis [mailto:jdennis at redhat.com]
> Sent: 02 May 2014 14:23
> To: OpenStack Development Mailing List (not for usage questions)
> Subject: Re: [openstack-dev] Security audit of OpenStack projects
> 
> On 04/07/2014 12:06 PM, Nathan Kinder wrote:
> > Hi,
> >
> > We don't currently collect high-level security related information 
> > about the projects for OpenStack releases.  Things like the crypto 
> > algorithms that are used or how we handle sensitive data aren't 
> > documented anywhere that I could see.  I did some thinking on how we 
> > can improve this.  I wrote up my thoughts in a blog post, which I'll 
> > link to instead of repeating everything here:
> >
> >   http://blog-nkinder.rhcloud.com/?p=51
> >
> > tl;dr - I'd like to have the development teams for each project keep
a
> > wiki page updated that collects some basic security information.
> > Here's an example I put together for Keystone for Icehouse:
> >
> >   https://wiki.openstack.org/wiki/Security/Icehouse/Keystone
> >
> > There would need to be an initial effort to gather this information 
> > for each project, but it shouldn't be a large effort to keep it 
> > updated once we have that first pass completed.  We would then be
able
> > to have a comprehensive overview of this security information for
each
> > OpenStack release, which is really useful for those evaluating and 
> > deploying OpenStack.
> >
> > I see some really nice benefits in collecting this information for 
> > developers as well.  We will be able to identify areas of weakness, 
> > inconsistency, and duplication across the projects.  We would be
able
> > to use this information to drive security related improvements in 
> > future OpenStack releases.  It likely would even make sense to have 
> > something like a cross-project security hackfest once we have taken
a
> > pass through all of the integrated projects so we can have some 
> > coordination around security related functionality.
> >
> > For this to effort to succeed, it needs buy-in from each individual 
> > project.  I'd like to gauge the interest on this.  What do others
think?
> >  Any and all feedback is welcome!
> 
> Catching up after having been away for a while.
> 
> Excellent write-up Nathan and a good idea.
> 
> The only suggestion I have at the moment is the information concerning 
> how sensitive data is protected needs more explicit detail. For
example
> saying that keys and certs are protected by file system permissions is
not
> sufficient IMHO.
> 
> Earlier this year when I went though the code that generates and
stores
> certs and keys I was surprised to find a number of mistakes in how the 
> permissions were set. Yes, they were set, but no they weren't set
correctly.
> I'd like to see explicit listing of the user and group as well as the
modes and
> SELinux security contexts of directories, files (including unix
sockets). This
> will not only help other developers understand best practice but also
allow
> us to understand if we're following a consistent model across
projects.
> 
> I realize some may say this falls into the domain of "installers" and 
> "packaging", but we should get it right ourselves and allow it to
serve as an
> example for installation scripts that may follow (many of which just
copy
> the values).

It's a great project, we really should be doing this more.

I think there's certainly scope to record 'installer' type information too, in the form of either recommendations or 'enhancements'. This information could be aggregated in the OpenStack Hardening Guide too.

As Nathan said this really needs buy-in from individual teams in order to pay off and the effort would need to be repeated for each release. I expect that future iterations would require a lot less effort than the first though.

Projects like this can be a bit of a time drain for core developers and highly active code contributors but they're ideal for people starting off in a project, a nice way to have them look through the code, understand it and report on it

I'd be very interested in any ideas on how to take this forward

-Rob