On 11/27/2013 08:58 AM, Paul Montgomery wrote: > 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
This is a great start. I think we really need to work towards a set of overarching security guidelines and best practices that can be applied to all of the projects. I know that each project may have unique security needs, but it would be really great to have a central set of agreed upon cross-project guidelines that a developer can follow. This is a goal that we have in the OpenStack Security Group. I am happy to work on coordinating this. For defining these guidelines, I think a "working group" approach might be best, where we have an interested representative from each project be involved. Does this approach make sense to others? Thanks, -NGK > > 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. > > Is there an OpenStack standard for code comments that highlight potential > security issues to investigate at a later point? If not, what would the > community think of making a standard for Solum? I would like to identify > these areas early while the developer is still engaged/thinking about the > code. It is always harder to go back later and find everything in my > experience. Perhaps something like: > > # (SECURITY) This exception may contain database field data which could > expose passwords to end users unless filtered. > > Or > > # (SECURITY) The admin password is read in plain text from a configuration > file. We should fix this later. > > Regards, > Paulmo > > > _______________________________________________ > 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
