Open Stack

Thanks Clayton!  I added your new content.

To all:
The OpenStack Security Guide is a very good resource to read -
http://docs.openstack.org/security-guide/content/openstack_user_guide.html

Apologies for not being up to speed on how things work in OpenStack yet
but here is a list of topics that I would like to discuss with the
community and reach a conclusion (guidance on how to get there is greatly
appreciated):

1) Solum community agrees that the OpenStack Security Guide (OSSG) will be
the basis for the Solum security architecture
2) Create a list of Solum security requirements that the community agrees
to take on from the OSSG and create a separate list of security
implementation that operators will be expected to implement on their own
3) Create a list of Solum-specific security requirements that the
community approves.  I recommend that
https://wiki.openstack.org/wiki/Solum/Security becomes this Solum-specific
security requirements list which the OSSG doesn't cover
4) Assign each security requirement a future Solum milestone, (beyond
milestone-1), details TBD

Finally determine the method for putting security requirements into the
work queue.  Sometimes blueprints will work but some security topics are
not easily confined to a single task or section of code.  Wikis or even
HACKING.rst might be locations for these requirements.



On 12/9/13 9:09 AM, "Clayton Coleman" <ccoleman at redhat.com> wrote:

>
>
>----- Original Message -----
>> I created some relatively high level security best practices that I
>> thought would apply to Solum.  I don't think it is ever too early to get
>> mindshare around security so that developers keep that in mind
>>throughout
>> the project.  When a design decision point could easily go two ways,
>> perhaps these guidelines can sway direction towards a more secure path.
>> 
>> This is a living document, please contribute and let's discuss topics.
>> I've worn a security hat in various jobs so I'm always interested. :)
>> Also, I realize that many of these features may not directly be
>> encapsulated by Solum but rather components such as KeyStone or Horizon.
>> 
>> https://wiki.openstack.org/wiki/Solum/Security
>> 
>> I would like to build on this list and create blueprints or tasks based
>>on
>> topics that the community agrees upon.  We will also need to start
>> thinking about timing of these features.
>> 
>
>A few suggested additions:
>
>  # Request load management
>
>  A number of proposed Solum operations are computationally/resource
>expensive.  The fulfilment of those operations should be predictable and
>linear, and resist denial-of-service or amplification attacks on a per
>user / project / service basis as needed.  This may involve queueing
>requests, having high water marks for these queues (where additional
>requests are rejected until existing requests clear), throttling delays
>on queue processing, separate work pools, or other load management
>techniques.  The system must remain available for other tenants even if a
>subset are targeted or malicious.
>
>  # Secure Storage (addendum)
>
>  Confidential data such as credential information should not be stored
>unencrypted in non-volatile storage. This is a defense in depth topic to
>place a barrier in front of attackers in the event that they gain access
>to some of the Solum control plane.
>
>  ADD: Where possible, distribute security responsibilities to user
>application storage / execution environments.  Even encrypted data in
>non-volatile storage is potentially valuable (especially given the
>possibility bugs in implementation), creating a high value target.
>Pushing secure data out as far as possible reduces the value of any
>individual data store to an attacker.
>
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev