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

[Zhou Zheng Sheng]

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?

>> 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


-- 
Zhou Zheng Sheng / 周征晟
E-mail: zhshzhou at linux.vnet.ibm.com
Telephone: 86-10-82454397