Open Stack

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-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev