On Sun, Aug 9, 2015 at 11:59 PM, Tony Breeds <t...@bakeyournoodle.com> 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'm not excited about making this the default until token revocations don't impact performance the way that they do now. I don't know how often this would get exercised though, but the impact of 100+ token revokes is noticeable on every API call. > > 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? > > Also is being able to bookmark/save the token a thing that users do? > > 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-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > >
__________________________________________________________________________ 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