----- 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
