<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 5, 2018 at 6:17 PM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:<br>
<span class="gmail-">> On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <<br>
> <a href="mailto:nishant.e.kumar@ericsson.com">nishant.e.kumar@ericsson.com</a>> wrote:<br>
> <br>
> > Hi,<br>
> ><br>
> ><br>
> ><br>
> > I have registered a blueprint for adding http security headers -<br>
> > <a href="https://blueprints.launchpad.net/cinder/+spec/http-security-headers" rel="noreferrer" target="_blank">https://blueprints.launchpad.<wbr>net/cinder/+spec/http-<wbr>security-headers</a><br>
> ><br>
> ><br>
> ><br>
> > Reason for introducing this change - I work for AT&T cloud project –<br>
> > Network Cloud (Earlier known as AT&T integrated Cloud). As part of working<br>
> > there we have introduced this change within all the services as kind of a<br>
> > downstream change but would like to see it a part of upstream community.<br>
> > While we did not face any major threats without this change but during our<br>
> > investigation process we found that if dealing with web services we should<br>
> > maximize the security as much as possible and came up with a list of HTTP<br>
> > security headers that we should include as part of the OpenStack services.<br>
> > I would like to introduce this change as part of cinder to start off and<br>
> > then propagate this to all the services.<br>
> ><br>
> ><br>
> ><br>
> > Some reference links which might give more insight into this:<br>
> ><br>
</span>> >    - <a href="https://www.owasp.org/index.php/OWASP_Secure_Headers_" rel="noreferrer" target="_blank">https://www.owasp.org/index.<wbr>php/OWASP_Secure_Headers_</a><br>
> >    Project#tab=Headers<br>
> >    - <a href="https://www.keycdn.com/blog/http-security-headers/" rel="noreferrer" target="_blank">https://www.keycdn.com/blog/<wbr>http-security-headers/</a><br>
> >    - <a href="https://securityintelligence.com/an-introduction-to-http-" rel="noreferrer" target="_blank">https://securityintelligence.<wbr>com/an-introduction-to-http-</a><br>
<span class="gmail-">> >    response-headers-for-security/<br>
> ><br>
> > Please let me know if this looks good and whether it can be included as<br>
> > part of Cinder followed by other services. More details on how the<br>
> > implementation will be done is mentioned as part of the blueprint but any<br>
> > better ideas for implementation is welcomed too !!<br>
> ><br>
> <br>
> Wouldn't this be a job for the HTTP server in front of cinder (or whatever<br>
> service)? Especially "Strict-Transport-Security" as one shouldn't be<br>
> enabling that without ensuring a correct TLS config.<br>
> <br>
> Bonus points in that upstream wouldn't need any changes, and we won't need<br>
> to change every project. :)<br>
> <br>
> // jim<br>
<br>
</span>Yes, this feels very much like something the deployment tools should<br>
do when they set up Apache or uWSGI or whatever service is in front<br>
of each API WSGI service.<br>
<br>
Doug<br>
<br></blockquote><div><br></div><div>I agree, this should all be set within an installer, rather then the base project itself. Horizon (or rather django) has directives to enable many of the common security header fields, but rather than set these directly in horizons local_settings, we patched the openstack puppet-horizon module. Take for the following for example around X-Frame disabling:<br><br><a href="https://github.com/openstack/puppet-horizon/blob/218c35ea7bc08dd88d936ab79b14e5ce2b94ea44/releasenotes/notes/disallow_iframe_embed-f0ffa1cabeca5b1e.yaml#L2">https://github.com/openstack/puppet-horizon/blob/218c35ea7bc08dd88d936ab79b14e5ce2b94ea44/releasenotes/notes/disallow_iframe_embed-f0ffa1cabeca5b1e.yaml#L2</a><br><br></div><div>The same approach should be used elsewhere, with whatever the preferred deployment tool is (puppet, chef, ansible etc).  That way if a decision is made to roll out out TLS then can also toggle in certificate pinning etc in the same tool flow.<br><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
</blockquote></div><br><br></div></div>