On 08/10/15 at 03:59pm, Tony Breeds wrote:
Hi All,
Nova has bug: https://bugs.launchpad.net/nova/+bug/1447679 (service No-VNC
(port 6080) doesn't require authentication).
Which explains that if you know the 'token'[1] associated with an instances
console you can get access to said console without otherwise proving that you
should be allowed access to that instance[3].
Nothing limits the problem to VNC, so all console types are potentially
affected.
There is a proposed solution (https://review.openstack.org/#/c/182129) which
adds a config option that means a token is only valid for a single usei[4].
The assertion is that bookmarking a URL to a console and then using it multiple
times is something that we want to still allow albeit discouraged. When the
config value is introduced it will default to False (meaning that the
bookmarking scenario above will still work). At some stage it'd be ideal to
invert this so that the option is True and operators can switch it if
appropriate.
I don't think that much of that in controversial, my question is what should
the schedule for switching this be? Assuming we land a fix in Liberty[5], make
the change in Mitaka? Norbert?
I would treat this like a deprecation and follow the standard of one
cycle of notice. So if it lands in Liberty it could be switched in
Mitaka.
Also is being able to bookmark/save the token a thing that users do?
I'm only one data point, but we have a short TTL on tokens so it is not
something that our users could reasonably due. And the Nova default TTL
is 10 minutes, which is also out of bookmarking range IMO.
Yours Tony.
[1] How you get that token isn't really the issue, it could be a network or
browser issue [2]
[2] I should look at the documentation of how we configure console access to
ensure it's "secure" by default
[3] Even if the console isn't logged in this is a bad thing(tm)
[4] There is an outstanding issue with SPICE that is being looked into
[5] Which isn't a given.
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
