Authentication offload in virtualized computing environments

Example methods are provided for a host to perform authentication offload in a virtualized computing environment that includes the host and a destination server. The method may comprise detecting, from a virtualized computing instance, a packet destined for the destination server. The method may also comprise: in response to determination that the detected packet is an authentication request, obtaining, from the virtualized computing instance, metadata associated with a client application for which authentication is requested; and sending the authentication request and the metadata to the destination server to cause the destination server to authenticate the client application based on the metadata.

BACKGROUND

Unless otherwise indicated herein, the approaches described in this section are not admitted to be prior art by inclusion in this section.

Virtualization allows the abstraction and pooling of hardware resources to support virtual machines in a Software-Defined Data Center (SDDC). For example, through server virtualization, virtual machines running different operating systems may be supported by the same physical machine (e.g., referred to as a “host”). Each virtual machine is generally provisioned with virtual resources to run an operating system and applications. The virtual resources may include central processing unit (CPU) resources, memory resources, storage resources, network resources, etc. For example, in practice, a virtual machine may run a client application that requires access to resources or services provided by a remote server. For security reasons, authentication of the client application may be performed to verify whether the client application should be have access to the resources or services. However, conventional authentication approaches may not be suitable for virtualized computing environments.

DETAILED DESCRIPTION

Challenges relating to authentication will now be explained in more detail usingFIG.1, which is a schematic diagram illustrating example virtualized computing environment100in which authentication offload may be performed. It should be understood that, depending on the desired implementation, network environment100may include additional and/or alternative components than that shown inFIG.1.

In the example inFIG.1, virtualized computing environment100includes multiple hosts110(one shown for simplicity) that are inter-connected via physical network105. Each host110includes suitable hardware112and virtualization software (e.g., hypervisor114) to support various virtual machines131-132. In practice, virtualized computing environment100may include any number of hosts, where each host may be supporting tens or hundreds of virtual machines. VM1131and VM2132each represent a software implementation of a physical machine.

Although examples of the present disclosure refer to virtual machines, it should be understood that a “virtual machine” running on host110is merely one example of a “virtualized computing instance” or “workload.” A virtualized computing instance may represent an addressable data compute node or isolated user space instance. In practice, any suitable technology may be used to provide isolated user space instances, not just hardware virtualization. Other virtualized computing instances may include containers (e.g., running within a VM or on top of a host operating system without the need for a hypervisor or separate operating system or implemented as an operating system level virtualization), virtual private servers, client computers, etc. Such container technology is available from, among others, Docker, Inc. The virtual machines may also be complete computational environments, containing virtual equivalents of the hardware and software components of a physical computing system. An application supported by a virtual machine may be a containerized application. The term “hypervisor” may refer generally to a software layer or component that supports the execution of multiple virtualized computing instances, including system-level software in guest virtual machines that supports namespace containers such as Docker, etc.

Hypervisor114maintains a mapping between underlying hardware112and virtual resources allocated to respective virtual machines131-132. Hardware112includes suitable physical components, such as central processing unit(s) or processor(s)120; memory122; physical network interface controllers (NICs)124; and storage disk(s)128accessible via storage controller(s)126, etc. Virtual resources are allocated to each virtual machine131/132to support guest operating system (OS)151/152and client application141/142. Corresponding to hardware112, the virtual resources may include virtual CPU, virtual memory, virtual disk, virtual network interface controller (VNIC), etc. In the example inFIG.1, virtual machines131-132are associated with respective VNICs171-172(also known as virtual Ethernet cards). Although one-to-one relationships are shown, one virtual machine may be associated with multiple VNICs (each VNIC having its own network address).

Hypervisor114further implements virtual switch116to handle egress packets from, and ingress packets to, respective virtual machines131-132. The term “packet” may refer generally to a group of bits that can be transported together from a source to a destination, such as message, frame, segment, datagram, etc. For example inFIG.1, VM1131and VM2132implement respective client applications141-142to access resources or services provided by remote server180supporting server application182. Server180may be implemented using a physical machine and/or virtual machine(s). In one example, server180may be a virtual machine supported by another host110in virtualized computing environment100.

Authentication may be performed verify whether client application141/142should have access to the resources or services provided by server180. However, conventional approaches for authentication may not be suitable for virtualized computing environment100. For example, one conventional approach involves a user (e.g., network administrator) manually pairing client application141/142with server application182, and pushing authentication credentials to virtual machine131/132supporting client application141/142. During authentication, client application141/142interacts with server180to provide the authentication credentials, based on which server180may verify the identity of client application141/142.

However, since it is necessary for client application141/142to manage or maintain their own authentication credentials according to the conventional approach, a third party might exploit a vulnerability of virtual machine131/132, such as guest OS151/152and/or client application141/142, to steal the authentication credentials and launch a malicious attack. A successful attack on one virtual machine may adversely affect the performance and security of other virtual machines in virtualized computing environment100. This problem is exacerbated in virtualized computing environment100where there are hundreds or thousands of virtual machines implementing a large number of client applications.

Authentication Offload

According to examples of the present disclosure, authentication offload may be performed to relieve client application141/142from the responsibility of maintaining authentication credentials, and providing the authentication credentials to server180during authentication. Instead, the task of interacting with server180during an authentication process is “offloaded” or delegated from client application141/142to hypervisor114, which provides better security protection against malicious attacks compared to virtual machine131/132. In the example inFIG.1, host110may implement authentication agent118to manage the authentication of various client applications141-142executing on virtual machines131-132supported by host110.

In more detail,FIG.2is a flowchart of example process200for host110to perform authentication offload in a virtualized computing environment100. Example process200may include one or more operations, functions, or actions illustrated by one or more blocks, such as210to240. The various blocks may be combined into fewer blocks, divided into additional blocks, and/or eliminated depending on the desired implementation. Example process200may be performed by host110, and more particularly, VNIC171/172and authentication agent118supported by hypervisor114. Various examples will be explained below using VM1131and VM2132as example “virtualized computing instances” and server180as an example “destination server” performing authentication.

In a first example, according to210inFIG.2, a first packet destined for server180is detected from VM1131via VNIC1171. According to220and230, in response to determination that the first packet is an authentication request (see190inFIG.1), metadata associated with first client application141for which authentication is requested is obtained from VM1131. According to240, the authentication request from VM1131and the metadata associated with first client application141(see192inFIG.1) are sent to server180to cause server180to authenticate first client application141based on the metadata.

Similarly, in a second example, according to210inFIG.2, a second packet destined for server180is detected from VM2132via VNIC2172. According to220and230, in response to determination that the second packet is an authentication request (see194inFIG.1), metadata associated with second client application142for which authentication is requested is obtained from VM2132. According to240, the authentication request from VM2132and the metadata associated with second client application142(see196inFIG.1) are sent to server180to cause server180to authenticate second client application142based on the metadata. In practice, the authentication request from VM2132may be destined for a different server.

As will be described further below, the term “metadata” associated with client application141/142may refer generally to any suitable data based on which authentication may be performed to verify an identity of client application141/142, such as a hash value and/or a digital signature associated with client application141/142. The metadata may be obtained from guest OS151/152associated with VM131/132, such as by invoking a call supported by guest enhancement toolkit161/162. The call may include any suitable header data (e.g., source port number) of the authentication request for guest enhancement toolkit161/162to identify client application141/142. Various examples will be explained below usingFIG.3toFIG.5.

Authentication Request

FIG.3is a flowchart of example detailed process300for authentication offload in virtualized computing environment100. Example process300may include one or more operations, functions, or actions illustrated by one or more blocks, such as305to390. The various blocks may be combined into fewer blocks, divided into additional blocks, and/or eliminated depending on the desired implementation. As will be described further below, hypervisor114may implement example process300using VNIC1171and authentication agent118(may also be referred to as a virtual authenticator). The example inFIG.3will be discussed usingFIG.4, which is a schematic diagram illustrating example400of authentication offload according to the example inFIG.3

At305inFIG.3, host110, or more particularly authentication agent118, establishes a trust channel with server180to facilitate authentication offload. Here, the “trust channel” represents a communication channel over which authentication-related traffic (e.g., authentication requests and responses) may be transmitted between authentication agent118and server180. In the example inFIG.4, the trust channel (see405) may be established using any suitable approach, such as bidirectional authentication using any suitable protocol such as transport layer security (TLS), shared secret key, tamper resistant software (TRS), authentication token such as JavaScript Object Notation (JSON) Web Token (JWT), etc.

Once the trust channel or relationship is established, server180recognizes authentication agent118as a trusted source, and vice versa. The same trust channel may be used to send authentication requests from different client applications141-142to server180. Authentication agent118may establish multiple trust channels with different servers. For example, if authentication is required from a second server (not shown), a second trust channel may be established between authentication agent118and the second server, etc.

At310inFIG.3, client application141executing on VM1131generates and sends an authentication request packet destined for server180. Depending on the desired implementation, the authentication request is generally in plain text and not encrypted. The authentication request may be generated by client application141using any suitable protocol, such as Transmission Control Protocol (TCP), HyperText Transfer Protocol (HTTP), HTTP Secure (HTTPS), etc.

In the example inFIG.4, the authentication request (see410) may be a request to establish a TCP connection with server180, such as a Synchronization (SYN) packet as part of a three-way handshake. In this case, the authentication request includes header data identifying 5-tuple parameters of the TCP connection: (source IP address, destination IP address, source port number, destination port number, protocol=TCP). Once the TCP connection is established, HTTP requests and responses may be exchanged between client application141and server180over the TCP connection. The authentication request may also be a HTTP or HTTPS request for a service supported by server180.

To facilitate authentication offload, hypervisor114A performs packet snooping at VNIC1171and VNIC2172to detect any packet from respective VM1131and VM2132. At315and320inFIG.3, in response to detecting a packet from VM1131via VNIC1171, it is determined whether the packet is an authentication request. For example, authentication agent118may have access to a list of servers (e.g., destination IP addresses) that require authentication. In this case, authentication agent118may determine whether the packet is destined for one of the servers on the list based on the header data of the packet (e.g., destination IP address and destination port number). The list may be configured by a user (e.g., network administrator), learned or updated by authentication agent118over time, etc.

At325inFIG.3, if the packet detected at315is not an authentication request (e.g., the destination does not require authentication), the packet will be sent to its destination. Otherwise (i.e., authentication required), at330, a notification will be sent from VNIC1171to authentication agent118.

In the example inFIG.4, in response to detecting the authentication request (see410), VNIC1171may also extract any suitable header data from the authentication request, such as source port number, destination port number, source IP address, destination IP address, etc. In this case, the notification (see420) sent from VNIC1171to authentication agent118may include the authentication request, the header data and any additional data identifying VM1131(e.g., VNIC ID=VNIC1).

Metadata Associated with Client Application

At335and340inFIG.3, authentication agent118identifies VM1131(e.g., based on VNIC ID=VNIC1), and obtains metadata associated with client application141from VM1131based on the header data of the authentication request. In the example inFIG.4, this may involve authentication agent118requesting for the metadata from guest OS151by invoking a call supported by guest enhancement toolkit161. For example, the call (see430) may identify header data of the authentication request, such as the source port number extracted from the authentication request.

In practice, guest enhancement toolkit161/162may represent a set of device drivers and services that are generally installed on guest OS151/152to boost the performance of guest OS151/152, facilitate management of VM131/132, improve the interaction between VM131/132and its host110, etc. One example of guest enhancement toolkit161/162is VMware Tools™ available from VMware, Inc. Any other suitable toolkit that supports the call at block340may be used in practice.

At345inFIG.3, in response to the call by authentication agent118, guest enhancement toolkit161retrieves the metadata associated with client application141. For example, since there may be multiple applications (or processes) running on VM1131, client application141may be identified based on the source port number provided in the call.

In example inFIG.4, the “metadata” (see440) associated with client application141may include any suitable data that allows server180to verify an identity of client application141, such as a (process) hash value associated with client application141, a digital signature, etc. For example, the hash value may be calculated for client application141using any suitable hash function, such as Secure Hash Algorithm (SHA), Message Digest (MD), variants thereof, etc. Depending on the desired implementation, the hash value may be calculated using MD5, SHA-1 or SHA-256, etc. An input of the hash function may include binary content associated with client application141. The hash value may be used by server180to identify client application141and/or to check that its binary content is unchanged.

Additionally or alternatively, the digital signature (also known as application signing information) associated with client application141may be generated any suitable digital signature function, such as RSA-based algorithms, Digital Signature Algorithm (DSA) and its elliptic curve variants, etc. The hash value and digital signature may be calculated when client application141is installed on VM1131. Depending on the desired implementation, the metadata may be static data that is updated when authentication agent118is updated. The update may be initiated by a user (e.g., network administrator) and managed at a hypervisor level.

In practice, a kernel-mode device driver (not shown) in guest enhancement toolkit161may be used to facilitate communication between guest OS151and authentication agent118. For security purposes, such as to avoid or reduce the likelihood of data forgery, access control of the device driver may be configured to allow access by those with privileged rights only (e.g., local system in Windows OS, etc.). In this case, a data collection program in guest enhancement toolkit161may be run with privileged right so that data is only sent to the device driver. Access by non-privileged users or processes will be forbidden. This way, a malicious process without the required privileged right will not be able to send fake or forged data to the device driver.

At350,355and360inFIG.3, in response to receiving the metadata from guest enhancement toolkit161of guest OS151, authentication agent118sends the authentication request from VM1131and the metadata to server180. As shown in the example inFIG.4, the authentication request from VM1131and metadata (see450) are sent via the trust channel (see405) established between authentication agent118and server180at block305inFIG.3. For example, header data of the authentication request may be modified to include the metadata. In the case of HTTPS request, the metadata may be included in JSON format in the header of the HTTPS request, which will be sent over the trust channel established based on TLS bi-directional authentication, JWT token, etc.

Authentication

At365inFIG.3, in response to receiving the authentication request and metadata, server180performs authentication to verify an identity of client application141based on metadata. For example, if the metadata includes a hash value associated with client application141, server180verifies whether the hash value is correct, such as to ensure that its binary content is unchanged. Additionally or alternatively, the authentication may be based on a digital signature associated with client application141.

At370inFIG.3, in response to determination that authentication is successful, server180sends a response that includes an authentication token to authentication agent118. Otherwise (not shown for simplicity), a failed notification will be sent from server180to authentication agent118. At375and380, authentication agent118receives and forwards the authentication token to VM1131.

In the example inFIG.4, the authentication token (see460) is sent to authentication agent118via the trust channel (see405) between them. Authentication agent118then forwards the authentication token to VM1131via VNIC1171(see470and480). Here, the term “authentication token” (also known as a security token or access token) may refer generally to any suitable data that indicates that client application141has an authenticated or trusted relationship with server180.

At385and390inFIG.3, client application141may use the authentication token for subsequent client-server communication with server application182supported by server180. An example will be described usingFIG.5, which is a schematic diagram illustrating example communication500between client application141and server application182after authentication is performed according to the example inFIG.3.

In the example inFIG.5, client application141generates and sends a HTTP request to request for a service provided by server application182. The HTTP request (i.e. service request) and the authentication token are then sent via VNIC1171to server180(see510and520). Server application182then processes the HTTP request and sends a HTTP response providing the requested service to client application141(see530and540).

Note that authentication agent118is shown in dashed line inFIG.6to indicate that the communication between client application141and server application182is conducted without any involvement by authentication agent118. In practice, parameters relating to a connection or session (e.g., TCP) between client application141and server application182may be stored at VNIC1171such that blocks315to360are not performed packets destined for server180after authentication. This reduces any adverse performance impact relating to packet snooping or filtering.

Although explained using client application141at VM1131, it should be understood that example process300may be implemented to authenticate client application142at VM2132. An authentication request from VM2132may be destined for server180, or any other destination. This way, authentication agent118is able to facilitate the authentication of various client applications executing on multiple virtual machines supported by host110, without necessitating the client applications to maintain their own authentication credentials.

Computer System

The above examples can be implemented by hardware (including hardware logic circuitry), software or firmware or a combination thereof. The above examples may be implemented by any suitable computing device, computer system, etc. The computer system may include processor(s), memory unit(s) and physical NIC(s) that may communicate with each other via a communication bus, etc. The computer system may include a non-transitory computer-readable medium having stored thereon instructions or program code that, when executed by the processor, cause the processor to perform processes described herein with reference toFIG.1toFIG.5. For example, a computer system may be deployed in virtualized computing environment100to perform the functionality of host110or server180.

Those skilled in the art will recognize that some aspects of the embodiments disclosed herein, in whole or in part, can be equivalently implemented in integrated circuits, as one or more computer programs running on one or more computers (e.g., as one or more programs running on one or more computer systems), as one or more programs running on one or more processors (e.g., as one or more programs running on one or more microprocessors), as firmware, or as virtually any combination thereof, and that designing the circuitry and/or writing the code for the software and or firmware would be well within the skill of one of skill in the art in light of this disclosure.