cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rohit Yadav <rohit.ya...@shapeblue.com>
Subject Re: [DISCUSS] Enhancement: Use CA framework to enable secured live KVM VM migration
Date Fri, 23 Mar 2018 10:21:23 GMT
Wido - fair point, considering this I'll add some notes in our release notes. With the suggested
change, during pkg upgrade libvirtd will not be reconfigured:

https://github.com/shapeblue/cloudstack-apple/pull/65/commits/9dd93ee3c7b0a31cbd262a51aaed2b325decfbd8


Instead, KVM hosts that don't meet following conditions will show up as 'unsecure' when they
connect to management server:

- Host does not have certificates setup at /etc/cloudstack/agent

- Host's libvirtd is not tls enabled with any provisioned certificate


The admin can then simply choose to provision certificate to secure 'unsecure' hosts post
upgrade via api or the newly added button. This process will provision (or renew) certificates,
configure only tls settings in libvirtd and restart libvirtd and then restart the agent. See
the PR for details. Thanks.



- Rohit

<https://cloudstack.apache.org>



________________________________
From: Wido den Hollander <wido@widodh.nl>
Sent: Thursday, March 22, 2018 10:14:31 PM
To: dev@cloudstack.apache.org
Subject: Re: [DISCUSS] Enhancement: Use CA framework to enable secured live KVM VM migration



On 03/21/2018 10:06 AM, Rohit Yadav wrote:
> Thanks Wido for your comments.
>
>
> Yes, for any changes to libvirtd the proposal is to re-use cloudstack-setup-agent which
in fact reconfigures libvirtd config at the time of the addition of host and also configure
iptables rule. As part of upgrading a KVM agent, the post-install script (part of deb/rpm
pkg) can also run the same to secure libvirt tls configuration only on KVM hosts that have
any existing certificates/keystore.
>

Hmm, we might want to be careful with a postinst. I'm not against it
being handled by a postinst, but we should watch out with overwriting
config files without the user knowing.

Wido

>
> - Rohit
>
> <https://cloudstack.apache.org>
>
>
>
> ________________________________
> From: Wido den Hollander <wido@widodh.nl>
> Sent: Wednesday, March 21, 2018 1:38:19 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [DISCUSS] Enhancement: Use CA framework to enable secured live KVM VM migration
>
>
>
> On 03/21/2018 08:05 AM, Rohit Yadav wrote:
>> All,
>>
>>
>> With the introduction of a native CA framework in CloudStack, with 4.11+ it will
be used to secure addition of KVM hosts and agents (cpvm, ssvm). However, the KVM host agent
may be secured while it communicates to the management server, the live VM migration still
happens on insecure tcp connection.
>>
>>
>> It is proposed to re-use the existing mechanism introduced in 4.11 and re-use host
certificates that are used to secure a KVM host to secure libvirt for allowing secured TLS-enabled
VM migration. Further, the UI may be enhanced to discover unsecured KVM hosts and allow securing
(or renewal/provisioning of certificates) through a button. Please find the FS for the proposed
enhancement:
>>
>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM
>>
>
> Seems good! As long as we make sure that only cloudstack-setup-agent
> touches the libvirt config files I'm good with it.
>
> Many people (like us) have the libvirt config files managed through a
> tool like Salt/Puppet/Chef and don't like it when daemons suddenly start
> changing configuration files.
>
> But this looks good to me!
>
> Wido
>
>>
>> - Rohit
>>
>> <https://cloudstack.apache.org>
>>
>>
>>
>> rohit.yadav@shapeblue.com
>> www.shapeblue.com<http://www.shapeblue.com>
>> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
>> @shapeblue
>>
>>
>>
>>
>
> rohit.yadav@shapeblue.com
> www.shapeblue.com<http://www.shapeblue.com>
> 53 Chandos Place, Covent Garden, London  WC2N 4HSUK
> @shapeblue
>
>
>

rohit.yadav@shapeblue.comĀ 
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK
@shapeblue
  
 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message