This extends securing of KVM hosts to securing of libvirt on KVM
host as well for TLS enabled live VM migration. To simplify implementation
securing of host implies that both host and libvirtd processes are
secured with management server's CA plugin issued certificates.
Based on whether keystore and certificates files are available at
/etc/cloudstack/agent, the KVM agent determines whether to use TLS or
TCP based uris for live VM migration. It is also enforced that a secured
host will allow live VM migration to/from other secured host, and an
unsecured hosts will allow live VM migration to/from other unsecured
host only.
Post upgrade the KVM agent on startup will expose its security state
(secured detail is sent as true or false) to the managements server that
gets saved in host_details for the host. This host detail can be accesed
via the listHosts response, and in the UI unsecured KVM hosts will show
up with the host state of ‘unsecured’. Further, a button has been added
that allows admins to provision/renew certificates to KVM hosts and can
be used to secure any unsecured KVM host.
The `cloudstack-setup-agent` was modified to accept a new flag `-s`
which will reconfigure libvirtd with following settings:
listen_tcp=0
listen_tls=1
tcp_port="16509"
tls_port="16514"
auth_tcp="none"
auth_tls="none"
key_file = "/etc/pki/libvirt/private/serverkey.pem"
cert_file = "/etc/pki/libvirt/servercert.pem"
ca_file = "/etc/pki/CA/cacert.pem"
For a connected KVM host agent, when the certificate are
renewed/provisioned a background task is scheduled that waits until all
of the agent tasks finish after which libvirt process is restarted and
finally the agent is restarted via AgentShell.
There are no API or DB changes.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
I found this empty test while working on other PRs. Empty/ignored tests do not help us. I am removing it. In the future, if we manage to improve these classes, we can work on unit test cases for them.
While debugging the VR for #2579, I noticed that one of the scripts were breaking. The variable RROUTER was not set and this broke a conditional.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* dependencies update
* Add extra blank line required by ...!?
* fix W605 invalid escape sequence and more blank lines
* print all installed python packages versions
This allows CloudStack to use a console proxy domain instead of public
IP address even when ssl is not enabled but console proxy url/domain
is defined in global settings.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
While executing the find/replace, I found some blocks of duplicated code. Therefore, I extracted the duplicated part to an utils file, and then removed the duplicated blocks.
* Add stack traces information
* update stack trace info
* update stack trace to make them consistent
* update stack traces
* update stacktraces
* update stacktraces for other similar situations
* fix some other situations
* enhance other situations
* Create database upgrade from 4.11.0.0 to 4.11.1.0 & VMWare version to OS mappings (#2490)
* Create database upgrade from 4.11.0.0 to 4.11.1.0. Add missing VMWare version to OS mapping SQL in the schema-41100to41110.sql.
* add unit test and add 4.11.0.0 entry to _upgradeMap
* upgrade 4.11.1 to 4.12 definition
* applied Nitin's comments
* systemvm: turn off apache2 server tokens and signature
This turns off apache2 server version signature/token in headers.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* systemvm: remove invalid code as conf.d is not available now
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
We no longer hash password in the user side. All of the password processing is executed in the server side according to the priority of hashing mechanism defined by the administrator.
* [CLOUDSTACK-10230] User is able to change to “Guest OS type” that has been removed
Users are able to change the OS type of VMs to “Guest OS type” that has been removed. This becomes a security issue when we try to force users to use HVM VMs (Meltdown/Spectre thing). A removed “guest os type” should not be usable by any users in the cloud.
The host/alert dashboard panels are on the top side, the dashboard
statistics page gets less room. This increases the panel by 100px for
zone dashboard and decreases the host/alert panels by 100px.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* [CLOUDSTACK-10226] CloudStack is not importing Local storage properly
CloudStack is importing as Local storage any XenServer SR that is of type LVM or EXT. This causes a problem when one wants to use both Direct attach storage and local storage. Moreover, CloudStack was not importing all of the local storage that a host has available when local storage is enabled. It was only importing the First SR it sees.
To fix the first problem we started ignoring SRs that have the flag shared=true when discovering local storages. SRs configured to be shared are used as direct attached storage, and therefore should not be imported again as local ones.
To fix the second problem, we started loading all Local storage and importing them accordingly to ACS.
* Cleanups and formatting
* Create database upgrade from 4.11.0.0 to 4.11.1.0. Add missing VMWare version to OS mapping SQL in the schema-41100to41110.sql.
* add unit test and add 4.11.0.0 entry to _upgradeMap
Remove deprecated tomcat configuration file instead of moving it, since moving it prevented the 4.11 upgrade from overwriting it with the new jetty configurations. Also added systemctl daemon-reload to refresh daemon services so that management server can start up seamlessly after the upgrade.
Fixes#2537
* translate groovy test for ADLdapUserManagerImpl to java
* fixed by returning the actual result instead of false
* unit test case for manual mapped user in ldap
This removes old cloudstack-usage jars during upgrade as part of
the pre-install step of cloudstack-usage deb package.
This fixes#2542.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
The idea is to create a property in /etc/defaults/cloudstack-management that can be enabled/disabled (uncommented/commented) to control the enabling of Java remote debug in CloudStack's JVM.
In cloudstack no-one person or organisation will ever be able to run all tests involving all kinds of hardware. make the checklist more realistic in this perspective.