Open Stack

On Thu, Jul 5, 2018 at 6:17 PM, Doug Hellmann <doug at doughellmann.com> wrote:

> Excerpts from Jim Rollenhagen's message of 2018-07-05 12:53:34 -0400:
> > On Thu, Jul 5, 2018 at 12:40 PM, Nishant Kumar E <
> > nishant.e.kumar at ericsson.com> wrote:
> >
> > > Hi,
> > >
> > >
> > >
> > > I have registered a blueprint for adding http security headers -
> > > https://blueprints.launchpad.net/cinder/+spec/http-security-headers
> > >
> > >
> > >
> > > Reason for introducing this change - I work for AT&T cloud project –
> > > Network Cloud (Earlier known as AT&T integrated Cloud). As part of
> working
> > > there we have introduced this change within all the services as kind
> of a
> > > downstream change but would like to see it a part of upstream
> community.
> > > While we did not face any major threats without this change but during
> our
> > > investigation process we found that if dealing with web services we
> should
> > > maximize the security as much as possible and came up with a list of
> HTTP
> > > security headers that we should include as part of the OpenStack
> services.
> > > I would like to introduce this change as part of cinder to start off
> and
> > > then propagate this to all the services.
> > >
> > >
> > >
> > > Some reference links which might give more insight into this:
> > >
> > >    - https://www.owasp.org/index.php/OWASP_Secure_Headers_
> > >    Project#tab=Headers
> > >    - https://www.keycdn.com/blog/http-security-headers/
> > >    - https://securityintelligence.com/an-introduction-to-http-
> > >    response-headers-for-security/
> > >
> > > Please let me know if this looks good and whether it can be included as
> > > part of Cinder followed by other services. More details on how the
> > > implementation will be done is mentioned as part of the blueprint but
> any
> > > better ideas for implementation is welcomed too !!
> > >
> >
> > Wouldn't this be a job for the HTTP server in front of cinder (or
> whatever
> > service)? Especially "Strict-Transport-Security" as one shouldn't be
> > enabling that without ensuring a correct TLS config.
> >
> > Bonus points in that upstream wouldn't need any changes, and we won't
> need
> > to change every project. :)
> >
> > // jim
>
> Yes, this feels very much like something the deployment tools should
> do when they set up Apache or uWSGI or whatever service is in front
> of each API WSGI service.
>
> Doug
>
>
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:

https://github.com/openstack/puppet-horizon/blob/218c35ea7bc08dd88d936ab79b14e5ce2b94ea44/releasenotes/notes/disallow_iframe_embed-f0ffa1cabeca5b1e.yaml#L2

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.



> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180706/8b72e28d/attachment.html>