Re: [openstack-dev] [Solum] [Security]
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
Re: [openstack-dev] [Solum] [Security]
- 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
Re: [openstack-dev] [Solum] [Security]
Yep, certainly interested in a broader OpenStack view of security; sign me up. :) On 11/27/13 9:06 PM, Adrian Otto adrian.o...@rackspace.com wrote: On Nov 27, 2013, at 11:39 AM, Nathan Kinder nkin...@redhat.com wrote: 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? Nathan, that sounds great. I'd like Paul Montgomery to be involved for Solum, and possibly others from Solum if we have volunteers with this skill set to join him. 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 ___ 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
[openstack-dev] [Solum] [Security]
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. 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
Re: [openstack-dev] [Solum] [Security]
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
Re: [openstack-dev] [Solum] [Security]
On Nov 27, 2013, at 11:39 AM, Nathan Kinder nkin...@redhat.com wrote: 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? Nathan, that sounds great. I'd like Paul Montgomery to be involved for Solum, and possibly others from Solum if we have volunteers with this skill set to join him. 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
