[openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

Fox, Kevin M Kevin.Fox at pnnl.gov
Wed Jun 29 21:46:39 UTC 2016


Ah. I was going to bring this up eventually but hadn't gotten to it yet.

I started up a patch for adding similar support for horizon here:
https://review.openstack.org/#/c/311189/

My intention is to use it to make a Horizon Plugin to speak to a Keystone authenticated Kubernetes api directly.

Thanks,
Kevin

________________________________
From: Timur Sufiev [tsufiev at mirantis.com]
Sent: Wednesday, June 29, 2016 2:10 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [security] [horizon] Security implications of exposing a keystone token to a JS client

Hello, vigilant folks of OpenStack Security team!

The commit(s) I'd like you to take a look at introduces a new Horizon feature, Create (Glance) Image using CORS (AKA Cross-Origin Resource Sharing) [1].

The main idea is to bypass Horizon web-server when uploading large local image and to send it directly to Glance server, thus saving network bandwidth and disk space on the controller node where Horizon web-server is deployed. However there is one possible security trade-off I had to make so that Glance service would allow me to upload an image - I'm passing the Keystone token to the Horizon JS runtime [2], and then pass it to Glance service [3] or [4] (different links here correspond to different versions of new Create Image - Django and Angular). This trade-off made Horizon community somewhat hesitant if we should push these changes forward, but nobody yet voiced a viable alternative, so here I'm writing this letter to you.

The usual Horizon workflow for working with Keystone tokens is the following: retrieve scoped token and put it into web-server session, which is itself not exposed to browser (unless SESSION_STORAGE signed_cookies backend was chosen, but even in that case session contents are encrypted in some way), but is kept on web-server and referenced using the session key which is kept in browser cookies - so one may say that in existing setup keystone token never leaks to browser.

On the other hand, in some not so far (I hope) future, when more logic is moved to client-side UI (i.e. browser), the issue of browser authenticating to some OpenStack services directly would become more widespread, it just happened that this work on Create Image in Horizon is pioneering this area (AFAIK). So, what do you think of possible security implications of this setup?

Just for the reference, three patches mentioned in [1-3] implement most of the logic of new Create Image feature.

[1] https://blueprints.launchpad.net/horizon/+spec/horizon-glance-large-image-upload
[2] https://review.openstack.org/#/c/317365/15/openstack_dashboard/api/glance.py@215
[3] https://review.openstack.org/#/c/230434/37/horizon/static/horizon/js/horizon.modals.js@212
[4] https://review.openstack.org/#/c/317456/16/openstack_dashboard/static/app/core/openstack-service-api/glance.service.js@151
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160629/744d6b8b/attachment.html>


More information about the OpenStack-dev mailing list