[Kimchi-devel] [PATCH 0/6] Enable Kimchi authentication in console pages

[Aline Manera]

On 05/05/2014 12:41 AM, Zhou Zheng Sheng wrote:
> on 2014/05/04 23:14, Aline Manera wrote:
>> On 05/04/2014 04:21 AM, Zhou Zheng Sheng wrote:
>>> This is a nice idea. I tested the vnc part. A problem in previous "[v3]
>>> Enable encryption in vm VNC console connection" is that vnc_auto.html is
>>> not protected by kimchi authentication, and this patch fixes the
>>> problem. The reason why I did not implement authentication is that the
>>> port 64667 for the VNC websocket traffic itself is not protected by
>>> Kimchi authentication. Even with this patch series, one can just git
>>> clone the noVNC official git repo, then open the following link in Opera
>>> (or Chrome?).
>>>
>>>
>>> file:///home/edward/src/noVNC/vnc_auto.html?port=64667&host=X.X.X.X&path=?token=NAME_OF_THE_VM&encrypt=1
>>>
>>> Then you get the guest VNC console without logging in to Kimchi. So this
>>> patch does not improve anything compared to "[v3] Enable encryption in
>>> vm VNC console connection", and it involves another redirection which
>>> makes the process a bit more complicated.
>> I need to disagree with you.
>> With this patch the noVNC is protected from Kimchi perspective
>> (different from the previous patch), ie,
>> if the user wants to get the console, he does need to get it from noVNC
>> source code as you described above
>> but it will not be possible through Kimchi.
>>
>> Even with the password parameter you mentioned below, if the user has
>> the full URL (including the password)
>> he will be able to get the console from noVNC source code without
>> authentication.
>>
>> To the password parameter works, we need to set a random password for
>> each VNC connection with expiration
>> time (to reset it after connection is stabilized)
>>
>> So vm_connect() create a random VNC password with expiration time for
>> 10s (just the enough time to open
>> connection to noVNC)
>>
>> That way we ensure each connection has a single valid password and if
>> someone gets the full URL it won't be valid
>> anymore.
>>
>> We need to verify how much work is needed to implement this "password
>> with expiration time" approach.
>> Any help is welcome!
>>
> Had a little chat with Aline, and we have discussed two options.
>
> (1) Poxying Websocket Request
>   JS websocket request -> nginx -> Kimchi (CherryPy) -> websockify
> In this way Kimchi stays in the path so it gets the chance to auth the
> request before the protocol upgrade. However transparent websocket
> reverse proxing is just a new nginx feature, and it might not work with
> CherryPy. The mechanism is also too complex.
>
> (2) Permanent Password
> Firstly we generate a random password and set it for the VM console
> (Spice/VNC). When the user wants to visit the console, the user will be
> firstly led to
>   vms/vm_name/console
> and the handler firstly puts the password in the cookie, and raise an
> HTTP redirection to a fake "vnc_auto.html" served by websockify (HTTPs
> port 64667), so the user gets the chance to accept websockify server cert.
>
> Then the JS scripts in the fake "vnc_auto.html" redirects the user to
> the real "vnc_auto.html" served by Kimchi. At last the JS in the real
> "vnc_auto.html" gets the password from the cookie, and uses the password
> to connect to Spice/VNC via websockify.
>
> The real "vnc_auto.html" has to be served by Kimchi so that the JS in
> "vnc_auto.html" can get the cookies previously set by Kimchi.
>
> We should also have a "Show Console Password" button in the front-end,
> so the user can get the password and the user can use other tools to
> connect to VNC/Spice.
>
> (3) Temporary Password for Each New Console Session
> It works like option 2 but the a new password is generated and set each
> time in the "vms/vm_name/console" handler. We can alternatively provide
> a POST action on "vms/vm_name/set_ticket" to enable the JS set a
> temporary console password.
>
> Our plan is to implement option 2 firstly, if we have time, implement
> option 3. For VMs created outside of Kimchi, we shall still re-use
> option 2 but just without a password. A problem here is how do we
> distinguish VM managed by Kimchi and VM managed by other tools. Shall we
> use the meta data feature, Shao He?

For option 2, I sent a V2 of "Enable Kimchi authentication in console
pages" (which also fix a bug in spice support)
After getting it merged, we can work in the password part independently.

>>> I think instead of protecting vnc_auto.html, which is purely static
>>> content and not useful to protect, we should protect the VNC payload
>>> with password. Kimchi should start the VM with a random VNC password,
>>> when the user clicks the VNC link, it should links to
>>>
>>> https://server:64667/vnc_auto.html?password=XXX&port=XXX&token=XXX&encrypt=1&path=?
>>>
>>> Since the password is random generated, and the traffic encrypted on
>>> HTTPs, it's actually secure.
>>>
>>> We can also improve the security by generating a new random password
>>> every time the user opens a new VNC session.
>>>
>>> on 2014/05/02 08:49, Aline Manera wrote:
>>>> From: Aline Manera <alinefm at br.ibm.com>
>>>>
>>>> As I commented in mailing list ([v3] Enable encryption in vm VNC console connection)
>>>> to enable Kimchi authentication in console pages those need to be provided by 
>>>> Kimchi server instead of websockify web server.
>>>>
>>>> I reverted the "Enable encryption in vm VNC console connection" commit, applied
>>>> "[PATCH v2] Enable encryption in vm console connection" path send by Mark and
>>>> make the changes needed to redirect user from websockify web server to Kimchi.
>>>> So noVNC page continues to be rendered by Kimchi.
>>>>
>>>> With all that done, I was able to enable authentication to vnc_auto.html and
>>>> spice.html
>>>>
>>>> Aline Manera (5):
>>>>   Revert "Enable encryption in vm VNC console connection"
>>>>   Make use of the mini Web server in the websockify
>>>>   Enable Kimchi authentication in console pages
>>>>   backend: Redirect 401 error to default page
>>>>   UI: Redirect user to console page after logging
>>>>
>>>> Mark Wu (1):
>>>>   Enable encryption in vm console connection
>