Open Stack

On 04/10/2014 09:48 AM, Russell Bryant wrote:
> On 04/10/2014 11:39 AM, Steven Hardy wrote:
>> On Mon, Apr 07, 2014 at 09:06:23AM -0700, 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!
>>
>> I think this is a good idea, and hopefully can provide valuable insight
>> into common pain-points or areas for improvement.
> 
> Huge +1.  I think tracking this information is very valuable.
> 
>> I've made a start on a page for Heat, feedback welcome!
>>
>> https://wiki.openstack.org/wiki/Security/Icehouse/Heat
> 
> I wonder if it would be easier to keep up if we restructure this a bit.

I'm all for restructuring.  These are the details we need to hash out to
determine what makes sense across all of the projects.  I see two main
viewpoints that we need to keep in mind when determining how to handle this:

- Maintenance should be easy for developers to keep the information up
to date and in sync with the code with minimal overhead.

- Consumption of the documentation should be easy for those evaluating
and deploying OpenStack.

>  In particular, I'm wondering if having a project-specific page that
> isn't version specific would be easier.  It could just contain version
> pointers where appropriate.

The downside with this is that the page starts to get confusing/complex
after a number of releases.  It's not going to provide a concise picture
of a given release 5 releases from now.

I was thinking that this should be similar to a source control branching
model.  A project would be updating this information for the trunk, then
branching when we near a release.  This effectively provides a snapshot
of the security information for a particular release, which should only
need to be updated if we backport code changes that necessitate a
documentation change.  The size of the document will not get out of hand
over many releases, but we will just have different versions of the
document for different releases.  This model could be seen as an
argument for keeping the doc in-tree with the source code, which we
could then publish for easier consumption by non-developers (wiki and/or
the OpenStack Security Guide).

> 
> In the case of Nova, we already have a number of sub-pages under
> wiki/Nova, so I think a wiki/Nova/Security page would make sense.
>