Patent Application
20190394028
The present invention relates to the field of computing, and in particular to techniques for deploying multiple server applications in virtual environments.
There is a common need to instantiate and configure multiple servers in virtual environments in which the multiple servers need to communicate with each other, including logging in to each other. Currently, this deployment of virtual servers is performed by manually configuring user and password values in each deployed virtual server. The effort involved is significant, and security holes in the configuration and deployment process are common.
Alternatives that have been employed use “pre-configured” users and passwords, which have their own security holes. This alternative procedure is not always usable, such as where there is a server role that has multiple instances.
A more secure and simpler approach to deploying and configuring authentication in virtual servers would be desirable.
In one embodiment, a method of deploying virtual servers comprises installing a certificate authority certificate for a manager server in a virtual server image; instantiating a virtual server with the virtual server image by the manager server; creating a public key and a private key by the virtual server; generating a certificate signing request by the virtual server that includes the public key of the virtual server, signed with the private key of the virtual server; sending the certificate signing request to the manager server; creating a public key certificate from the certificate signing request signed by the private key of the manager server; and sending the public key certificate from the manager server to the virtual server.
In another embodiment, a non-transitory machine readable medium stores software for deploying virtual servers, wherein the software comprises instructions that when executed cause a processor of a manager server to install a certificate authority certificate for the manager server in an image for instantiating a virtual server; instantiate the virtual server with the virtual server image; receive a certificate signing request from the virtual server signed with a private key of the virtual server; create a public key certificate from the certificate signing request; and send the public key certificate to the virtual server.
In yet another embodiment, non-transitory machine readable medium stores software for use by a virtual server, wherein the software comprises instructions that when executed cause a virtual processor of the virtual server to create a public key and a private key for the virtual server in a secure environment; generate a certificate signing request that includes the public key of the virtual server, signed with the private key of the virtual server; send the certificate signing request to a manager server serving as certificate authority for the virtual server; and receiving a public key certificate from the manager server responsive to the certificate signing request.
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate an implementation of apparatus and methods consistent with the present invention and, together with the detailed description, serve to explain advantages and principles consistent with the invention. In the drawings,
In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the invention. It will be apparent, however, to one skilled in the art that the invention may be practiced without these specific details. In other instances, structure and devices are shown in block diagram form in order to avoid obscuring the invention. References to numbers without subscripts or suffixes are understood to reference all instance of subscripts and suffixes corresponding to the referenced number. Moreover, the language used in this disclosure has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter, resort to the claims being necessary to determine such inventive subject matter. Reference in the specification to “one embodiment” or to “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment of the invention, and multiple references to “one embodiment” or “an embodiment” should not be understood as necessarily all referring to the same embodiment.
As used herein, the term “a computer system” can refer to a single computer or a plurality of computers working together to perform the function described as being performed on or by a computer system.
This solution uses a PKI (Public Key Infrastructure) suite in which public-private key pairs are generated and used. While PKI provides the methods for creating private and public keys and other methods of securing them, it does not address the automation of installation of certificates in virtual machine environments where multiple servers need to communicate with each other in a secure way without human intervention.
Current server installation is manual and requires either using user and password or manual certificate installation per server. That burdens the IT administrator and requires planning and significant administrator time where large numbers of server installations and management is required, and is infeasible in situations with a need for quick, dynamic instantiation of virtual servers that may have short lives.
The techniques described below allow installation and maintenance of virtual servers that can be quick, automatic, easy, and achieved without human intervention. In addition, these techniques can be more secure than using user/password methods.
These techniques improve real-time applications, such as video conferencing, which may use multiple server topologies that requires high real-time scalability, as a result of changes in video conferencing port demand. In such cases, there is a requirement to spin-up new servers in seconds and to establish a secured connection between those new servers and the existing ones, because different servers have distinct roles and they need to communicate with each other in order to form one real-time video conferencing solution. In addition, the virtual servers may have short life spans between instantiation and termination.
The manager server 110 serves as a certificate authority (CA) to the virtual servers 120A-120N that are being deployed by the manager server 110. In some embodiments, the manager server 110's CA certificate is a self-signed certificate. Various embodiments may use open source libraries, such as OpenSSL®, that give one or more utilities for creating public and private keys, using a variety of different certificate formats. (OPENSSL is a registered trademark of the OpenSSL Software Foundation.) The manager server 110 is aware of the number of servers 120 being deployed and may generate authentication credentials for each of them.
In one embodiment, illustrated in the block diagram of
The installation of keys and certificates may be implemented in some embodiments by embedding the files in the virtual server images instantiated in each virtual server 120A-120N in a predefined location in the virtual server image that is known to the manager server 210 and each virtual server 220. Alternatively, the manager server 210 may use a virtual application programming interface (API), e.g., OpenStack® file injection or a vendor specific API, to inject a file with the public key of the manager server 210 into the virtual server 220. (OPENSTACK is a registered trademark of OpenStack Foundation.)
Using the public-private key pair enables authentication of each of the deployed virtual servers 120A-120N and the manager server 110 and also enables encryption through using Transport Layer Security (TLS) connections with certificate exchanges in action 250 that can start with asymmetric encryption and continue with symmetric encryption. However, public-private key injection is less secure than the certificate based approach described below.
In another embodiment a certificate signing request (CSR) procedure may be used for certificate creation in the deployed virtual servers 120A-120N. In this approach, illustrated in the flowchart 300 of
The procedure for creating a CSR involves the deployed server first generating a private and public key pair in block 320. Any desired technique for creating a public-private key pair may be used. Preferably, the deployed virtual server 120 may create the private and public keys in a secure environment such as a sandbox. By creating the private and public keys on the deployed virtual servers 120A-120N, there is no need to provision those keys by the CA (the manager server 110), avoiding the need to transmit them from the CA to the deployed virtual servers 120A-120N.
The CSR is then created in block 325 and contains information identifying the deployed virtual server 120, the public key of the deployed server 120, and optionally a set of attributes constructed by the deployed server 120. For example, the CSR attribute information may include a service type that may be used to differentiate between instances of the virtual servers 120A-120N. In another example, the CSR attribute The CSR also contains a signature algorithm identifier and a signature of the CSR information signed by the deployed virtual server 120's private key in block 330. The CSR may also contain any other credentials or other proofs of identity required by the manager sever 110, and the manager server 110 as CA may request additional information from the deployed server as desired. Finally the CSR is signed with the public key of the CA in block 335 before sending it to the CA.
The CA receives the CSR with the signature and verifies the CSR in block 340 using the public key of the virtual server 120. Once verified, the CA transforms the request into an X.509 public-key certificate signed with the private key of the CA in block 345. The CA then returns the certificate to the deployed virtual server 120 in block 350. This results in every instance of the deployed virtual servers 120A-120N having a public and private key and a public-key certificate. In block 355, the deployed virtual servers 120A-120N can use the CA's public key to verify the public key certificate received from the CA.
The CA public key may be used only after all certificate generation has been completed. The manager server 110 serving as the CA is aware of the number of virtual server instances that were deployed (because the manager server 110 spawned them), and can ensure that no fake entity can impose itself as one of the deployed servers.
Once each instance of the deployed virtual servers 120A-120N has its own private key, its own public key, the CA public key, and the public key certificate, the deployed virtual servers 120A-120N may use the public key certificate to individually establish in block 360 a Secure Sockets Layer (SSL) connection that includes both server and client certificate handshakes and verify the identity of the client/server against the CA certificate. This allows secured encrypted connections for communication among the various virtual servers 120A-120N and between the virtual servers 120A-120N and the manager server 110, as illustrated in
In some embodiments, the virtual servers 120A-120N and manager server 110 use the Simple Certificate Enrollment Protocol (SCEP) for using the CA's certificate to secure the message exchange for the CSR. The SCEP is described in the Internet Draft document entitled “Simple Certificate Enrolment Protocol, draft-gutman-scep-10” published by the Internet Engineering Task Force, which can be found in tools.ietf.org/html/draft-gutman-scep-10, and which is incorporated by reference herein in its entirety for all purposes.
Because the virtual servers 120A-120N may be short-lived, being created and terminated dynamically as needed, the manager server 110 may in some embodiments where the lifetime of a virtual server 120 is known set a lifetime for the X.509 public key certificate sent to the virtual server 120 based on the lifetime of the virtual server 120. In some embodiments, where the lifetime of the virtual server 120 is unknown a priori, the manager server 110 may revoke the X.509 public key certificate provided to the virtual server 120 as part of a procedure of terminating the virtual server 120. In some embodiments, where the lifetime of the virtual server 120 exceeds an expiration lifetime of the X.509 public key certificate, the virtual server 120 may need to renew the X.509 public key certificate. In some scenarios, the renewal may also require the virtual server 120 to generate a new private-public key pair and make a new CSR to certify the new public key for the virtual server 120. Similarly, if for any other reason the virtual server 120 needs to generate a new public-private key pair, such as compromise of the private key, a new CSR may be used to certify the new public key and a revocation of the prior X.509 public key certificate may be performed.
Referring now to
System unit 410 may be programmed to perform methods in accordance with this disclosure (an example of which is in
It is to be understood that the above description is intended to be illustrative, and not restrictive. For example, the above-described embodiments may be used in combination with each other. Many other embodiments will be apparent to those of skill in the art upon reviewing the above description. The scope of the invention therefore should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.
