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" <ccole...@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@lists.openstack.org >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
