Automating establishment of initial mutual trust during deployment of a virtual appliance in a managed virtual data center environment

System and method for securely deploying a virtual machine in a data center is disclosed. In one embodiment, public keys are established between the requesting virtual machine and the deployed virtual machine, so that authentication and communication between the machines can occur using the public keys. In another embodiment, a secret private key is established between the requesting virtual machine and the deployed virtual machine using a password authenticated key exchange protocol. Authentication and communication between the machines is then established using the secret private key.

BACKGROUND

As cloud computing becomes more affordable every year, the demand of software defined data centers in the cloud is on the rise. Rolling out a new data center for a customer involves deploying a plethora of management software typically bundled as virtual appliances. These virtual appliances, which are usually in the form of virtual machines, are stored in centralized storage and are accessed and deployed during data center creation which is typically done by a deployment and bring-up script.

A typical deployment environment starts with the appliances connected only to an isolated network. This assumption becomes the foundation for developer's confidence that such a setup is not vulnerable and hence establishing trust is ignored at the first step. After the first step, proper security is established for the deployed appliances and communications with the deployed appliances is then secure. However, the first step in the initial deployment of virtual appliances in the data center as well as in the later deployment of new virtual appliances, leaves a gap in security. It is important to close this gap in security.

DETAILED DESCRIPTION

FIG. 1depicts data center and deployment of a virtual machine. A data center102includes a hypervisor104and a hypervisor106for supporting virtual machines such as virtual appliances. Hypervisor104supports a data center manager108, which may be a virtual machine, along with a virtual machine, virtual machine X (VMX)110. Hypervisor106supports a number of virtual machines VM1112, VM2114, VM3116. VM3116includes a data center manager client process122, a trust store124, a TLS/SSH client process126and a VM3public digital certificate128. VMX110, which is the machine deployed in the data center at the request of VM3116, includes a VMX public certificate118and a TLS/SSH server process120. VMX110is configured to operate as a TLS/SSH server to VM3116which is configured to operate as a TLS/SSH client.

FIG. 2depicts a sequence diagram200for deployment of a virtual machine according to an embodiment. Execution of steps202-218assumes that it is possible to inject secrets into a virtual machine to be deployed and to retrieve arbitrary files from the virtual machine's virtual disk. In step202, VM3116requests the deployment of VMX110. In step204, data center manager108injects the public digital certificate for VM3116into a properties attribute of VMX110. The public digital certificate contains, among other data items, a public key for VM3116along with the issuer's digital signature to establish authenticity of the public key. In step206, data center manager108deploys VMX110to run on hypervisor104. In step208, the VMX110reads its properties attributes and obtains the injected public digital certificate. In step210, VMX110adds its public key to the set of authorized VMX keys. In step212, data center manager108reads an accessible disk file of VMX110and obtains the public digital certificate of VMX110and in step214, sends the certificate to VM3116. In step216, VM3116stores locally the public key for VM3116. In step218, VM3116establishes a secure connection with VMX110using the VMX public key. At this point, VM3116has the public key for VMX110and VMX110has the public key for VM3116so that a symmetric secret session key can be established for communication between VMX110and VM3116.

FIG. 3depicts a sequence diagram300for deployment of a virtual machine according to an embodiment. Execution of steps302-318assumes that it is possible to execute arbitrary commands in the deployed virtual machine's environment and it is possible to retrieve arbitrary files from the virtual machine's disk. In step302, VM3116request deployment of VMX110. In step304, data center manager108deploys VMX110along with its public digital certificate. In step306, data center manager108, performs a command that injects the public digital certificate for VM3116into the authorized keys for VMX110. In step308, using a secure channel, data center manager108obtains the public digital certificate for VMX110. In step310, the data center manager108sends the obtained digital public certificate to VM3116. In step312, VM3116locally stores the public key for VMX110. In step314, VM3116establishes a secure connection with VMX110using the VMX public key. At this point, VMX110has the public key for VM3116and VM3116has the public key for VMX110so that a symmetric secret session key can be established for communication between VMX110and VM3116.

FIG. 4depicts a sequence diagram for deployment of a virtual machine according to an embodiment. Execution of steps402-422assume that it is possible to execution arbitrary commands in the virtual machine's environment and it is possible to retrieve arbitrary files from the virtual machine's disk. In step402, VM3116requests to deploy VMX110and includes secret A (SEC-A) and secret B (SEC-B). In step404, data center manager108injects SEC-A and SEC-B into the properties attribute of VMX110. In step406, data center manager108deploys VMX110. In step408, VMX110reads SEC-A and sets its password to SEC-A. In step410, VMX110reads SEC-B and in step412stores SEC-B locally. In step414, VM3116connects with VMX110using a type of password-authenticated key agreement (PAKE) protocol, such as the Secure Remote Password (SRP) protocol, e.g., SRP-6. The SRP protocol is a variant of Diffie-Hellman key agreement protocol based on weak secrets (e.g., passwords) and results in each participant sharing a symmetric secret session key. Thus, at this point, both VMX110and VM3116share a symmetric secret session key. In step416, the connection between VM3116and VMX110is upgraded to a TLS session in one embodiment. The protocol in TLS has two layers, a record protocol, which encapsulates higher-level protocols and handles reliability, confidential and compression of messages exchanged over the connection, and a handshake protocol, which is responsible for setting up a secure channel between participants (server VMX and client VM3) and providing the keys and algorithm information to the record protocol. Thus, the TLS session provides security features such as identification, authentication, confidentiality and integrity for the communication between VMX and VM3. In step418, VMX110sends its public digital certificate to VM3116, which is verified by VM3to establish a secure connection. In step420, VM3116stores locally the public key for VMX110and in step422, VM3116provides SEC-A over the secure connection which is verified by VMX to authenticate VM3's identity.