Hypervisor assisted virtual machine clone auto-registration with cloud

A method for automatically reregistering a clone virtual machine with a cloud security monitoring service is provided. The method generally includes detecting a connection between a cloud agent running in a virtual machine on a host and a hypervisor module on the host. In response to detecting the connection, the cloud agent queries the hypervisor module for one or more first identifiers of the virtual machine. The method generally includes checking a database, by the cloud agent, for one or more second identifiers stored in the database matching the one or more first identifiers received from the hypervisor module and, based on finding no second identifiers stored in the database matching the one or more first identifiers, sending a request to the cloud security monitoring service to register the virtual machine with the cloud security monitoring service.

RELATED APPLICATION

Benefit is claimed under 35 U.S.C. 119 (a)-(d) to Foreign application Ser. No. 202241001119 filed in India entitled “HYPERVISOR ASSISTED VIRTUAL MACHINE CLONE AUTO-REGISTRATION WITH CLOUD”, on Jan. 8, 2022, by VMware, Inc., which is herein incorporated in its entirety by reference for all purposes.

INTRODUCTION

Virtual desktop infrastructure (VDI) is a desktop virtualization technology wherein virtual images of a desktop, running on a host in a remote data center, are delivered over a network to a client device (e.g., a personal computer (PC) or mobile device), using a remote display protocol, for display remotely at the client device. In particular, images of the remote desktop operating system (OS), or its applications, are captured and sent (e.g., as a stream of pixels) to the client device which allows a user of the client device to interact with the remote desktop OS, and its applications, as if they were running locally. The user may interact with the remote desktop using peripheral devices (e.g., a keyboard and/or a mouse) associated with the client device. Inputs by the user at the client device, using such peripheral devices, are captured by a VDI client (e.g., a user-side interface of the remote desktop) of the client device and redirected from the client device to a VDI agent of the remote desktop.

VDI uses virtual machines (VMs) to provide and manage virtual desktops. Virtualization is a process whereby software is used to create an abstraction layer over computer hardware that allows the hardware elements of a single computer to be divided into multiple virtual computers. The software used is called a hypervisor—a small layer that enables multiple OSs to run alongside each other, sharing the same physical computing resources. When a hypervisor is used on a physical server (also known as a bare metal server or a host) in a data center, the hypervisor allows the physical computer to separate its OS and applications from its hardware thereby enabling the creation and management of VMs. The result is that each VM contains a guest OS, a virtual copy of the hardware that the OS requires to run, and an application and its associated libraries and dependencies. Other types of virtual computing instances (VCIs) may also be used similarly as VMs.

VMs hosting a remote desktop can either be persistent or non-persistent. A non-persistent VM is created at logon and destroyed at logoff. A non-persistent VM uses instant cloning technology in which the parent's running state is replicated as-is on the clones and the clone machine is unaware that it is indeed a new machine. For seamless VM security, VM clones should be protected as soon as they are created.

Today's enterprises rely on defense-in-depth mechanisms (e.g., multiple layers of security defense controls used to provide redundancy in the event a security control fails) to protect endpoint computing devices from malware infection. Malware is malicious software that, for example, disrupts network operations and gathers sensitive information on behalf of an unauthorized third party. Targeted malware may employ sophisticated methodology and embed in the target's infrastructure to carry out undetected malicious activities. In particular, once malware gains access to an endpoint, the malware may attempt to control the device and use lateral movement mechanisms to spread to other endpoints and critical assets of an enterprise.

Anti-malware solutions are employed to detect and prevent malware from infiltrating such endpoint computing devices in a system using various techniques, such as, sandboxing of malware samples, signature based detection of known malwares, and blocking of malwares from spreading in the environment. Modern anti-virus solutions are generally software as a service (SaaS) based. In cloud based anti-virus solutions, a cloud agent (also referred to herein as the “sensor”) running on an endpoint (e.g., on a VM running on a host in a data center) and sends events to a cloud security monitoring service, which may be a cloud backend service. The cloud security monitoring service decides whether to allow or deny a network connection and publishes appropriate security policies and rules to the cloud agent, which the cloud agent enforces on the endpoint.

An example cloud security monitoring service is Carbon Black cloud made commercially available from VMware, Inc. of Palo Alto, California. Carbon Black cloud provides security software that is designed to detect malicious behavior and help prevent malicious files from attacking an organization. A Carbon Black sensor pulls information into a centralized data analytics platform that provides the customer with analysis, alerts, and intelligence on vulnerabilities, suspicious activity, and blocked malware. The Carbon Black sensor ingests a variety of data sources that are processed and stored as cybersecurity events, behaviors, and system state metrics that can be analyzed, visualized, and alerted upon for anomaly detection, incident investigation, and remediation of cybersecurity risks.

To register (e.g., at startup of the agent) with the cloud security monitoring service, the agent on the endpoint registers with the cloud security monitoring service. For example, the agent sends the cloud security monitoring service a device identifier (ID) associated with the agent (e.g., a “unique_deviceID”) and may send an additional parameter (e.g., a “company_code”). In response, the cloud security monitoring service assigns a unique registration ID (e.g., a “registrationId”) to the agent when the registration is successful. This pair of the device ID and the unique registration ID assigned to the agent (e.g., “<unique_deviceID, registrationID>”) is used as the identity of the agent in all further communication with the cloud security monitoring service. For successful operations, the agent should be uniquely identified, even for VM clones.

A VM clone is an exact copy of the parent VM (also referred to as the “golden image”). When a VM clone is created, the agent is unaware that the agent is now running on a new VM. As a result, the VM clone continues to communicate with the cloud security monitoring service using the same device ID and registration ID pair as the parent. When multiple VMs use the same ID, the cloud security monitoring service cannot differentiate between the parent and clone VMs, which can lead to erroneous event reporting and remediation. For example, one or more events or alarms from the VM clone (or clones) may be incorrectly associated with the parent VM by the cloud security monitoring service. Accordingly, techniques for registering clone VMs with a cloud security monitoring service may be desirable.

It should be noted that the information included in the Background section herein is simply meant to provide a reference for the discussion of certain embodiments in the Detailed Description. None of the information included in this Background should be considered as an admission of prior art.

SUMMARY

The technology described herein provides a method for registering with a cloud security monitoring service. The method generally includes detecting a connection between a cloud agent running in a virtual machine on a host and a hypervisor module on the host. The method generally includes, in response to detecting the connection, querying the hypervisor module, by the cloud agent, for one or more first identifiers of the virtual machine. The method generally includes checking a database, by the cloud agent, for one or more second identifiers stored in the database matching the one or more first identifiers received from the hypervisor module and, based on finding no second identifiers stored in the database matching the one or more first identifiers, sending a request to the cloud security monitoring service to register the virtual machine with the cloud security monitoring service.

Further embodiments include a non-transitory computer-readable storage medium storing instructions that, when executed by a computer system, cause the computer system to perform the method set forth above, and a computer system including at least one processor and memory configured to carry out the method set forth above.

DETAILED DESCRIPTION

Aspects of the present disclosure introduce hypervisor assisted auto-registration of VM clones with a cloud security monitoring service, which may be cloud backend service. Embodiments provided herein allow the cloud security monitoring service to uniquely identify cloned VMs to differentiate between VM clones and the parent. Though certain aspects are discussed with respect to cloned VMs used for a VDI, it should be noted that the techniques discussed herein may similarly be applied to any suitable VCIs. In some embodiments, when a VM clone is created, a cloud agent detects that it is associated with a new clone VM and triggers an auto-registration with the cloud security monitoring service using a new device ID to obtain a new registration ID to uniquely identify the clone VM. In some embodiments, the cloud agent establishes a connection with a host module on the host hypervisor and queries identifiers from the host module. Because the host module is located on the host hypervisor, the host module can differentiate between a parent and clone VM running on the host and the host module will provide different identifiers for the parent and VM clones to the cloud agent. The cloud agent persists the fetched identifiers to memory and uses the identifiers in messages to the cloud security monitoring service.

The persisted identifiers are used to determine whether a VM is a golden VM or a clone VM. When a VM clone is created, a query to the host module is triggered to fetch the identifiers from the host module. The cloud agent of the VM clone compares the fetched identifiers with the persisted identifiers. When the fetched identifiers differ (e.g., in the case of a cloned VM) from the persistent identifiers, the cloud agent will fire a re-registration request to the cloud security monitoring service using a new device ID. In registration response, the cloud service sends the cloud agent a new registration ID. The clone VM can then use the new device ID and registration ID to uniquely identify the clone VM (i.e., differently than the parent VM) in subsequent communications with the cloud security monitoring service.

FIG.1depicts example physical and virtual network components in a networking environment100in which embodiments of the present disclosure may be implemented. As shown inFIG.1, networking environment100may be distributed across a hybrid cloud. A hybrid cloud is a type of cloud computing that combines on-premises infrastructure, e.g., a private cloud152comprising one or more physical computing devices (e.g., running one or more VCIs) on which the processes shown run, with a public cloud, or data center102, comprising one or more physical computing devices (e.g., running one or more VCIs) on which the processes shown run. Hybrid clouds allow data and applications to move between the two environments. Many organizations choose a hybrid cloud approach due to organization imperatives such as meeting regulatory and data sovereignty requirements, taking full advantage of on-premises technology investment, or addressing low latency issues.

Data center102and private cloud152may communicate via a network160. Network160may be an external network. Network160may be a layer 3 (L3) physical network. Network160may be a public network, a wide area network (WAN) such as the Internet, a direct link, a local area network (LAN), another type of network, or a combination of these.

Data center102includes one or more hosts110, an edge services gateway (ESG)122, a management network130, a data network150, a controller104, a network manager106, and a virtualization manager108. Data network150and management network130may be implemented as separate physical networks or as separate virtual local area networks (VLANs) on the same physical network.

Host(s)110may be communicatively connected to both data network150and management network130. Data network150and management network130are also referred to as physical or “underlay” networks, and may be separate physical networks or the same physical network as discussed. As used herein, the term “underlay” may be synonymous with “physical” and refers to physical components of networking environment100. As used herein, the term “overlay” may be used synonymously with “logical” and refers to the logical network implemented at least partially within networking environment100.

Each of hosts110may be constructed on a server grade hardware platform140, such as an x86 architecture platform. Hosts110may be geographically co-located servers on the same rack or on different racks. Hardware platform140of a host110may include components of a computing device such as one or more processors (CPUs)142, storage144, one or more network interfaces (e.g., physical network interface cards (PNICs)146), memory148, and other components (not shown). A CPU142is configured to execute instructions, for example, executable instructions that perform one or more operations described herein and that may be stored in the memory and storage system. The network interface(s) enable host110to communicate with other devices via a physical network, such as management network130and data network150.

Each host110is configured to provide a virtualization layer, also referred to as a hypervisor120. Hypervisors abstract processor, memory, storage, and networking physical resources of hardware platform140into a number of VCIs or VMs112on hosts110. As shown, multiple VMs112may run concurrently on the same host110. In some embodiments, a remote desktop may run on one or more of the VMs112. In the example shown inFIG.1, a remote desktop may run on a first VM (e.g., golden VM), VM1121, and a clone remote desktop may run on a second VM (e.g., clone VM), VM1122.

As shown inFIG.1, a VM112may include a cloud agent114. In some embodiments, cloud agent114is a Carbon Black sensor. Cloud agent114may be configured to receive security policies and rules from private cloud152(such as from cloud services156) and enforce the policies and rules at the VM112. In some embodiments, cloud agent114communicates with private cloud152using hypertext transfer protocol (HTTP).

As discussed in more detail below with respect toFIGS.2-5, cloud agent114may be configured to query a host module115on hypervisor120of host110to fetch identifiers from host module115. In some embodiments, cloud agent114communicates with host module115using a virtual machine communication interface (VMCI). VMCI is a high-speed interface that VMs on the same host use to communicate with each other and with host kernel modules, circumventing the network layer. Proximity to the host's memory bus makes the communications faster and eliminates latency, and also allows applications to work when network access is restricted or unavailable. VMCI communications may use a VMCI sockets (VSOCK) application programming interface (API) library.

In some embodiments, cloud agent114is configured to query host module115any time cloud agent114detects a reset of the connection with host module115(e.g., such as upon creation of a new VM, creation of a clone VM, or upon reconnection of a disconnected VM). Cloud agent114may be configured to persist the identifiers, such as to memory148. As discussed in more detail herein with respect to theFIGS.2-5, cloud agent114may be configured to compare the identifiers fetched from host module115to any persisted identifiers and perform a re-registration with private cloud152when the fetched identifiers do not match the persisted identifiers. Cloud agent114may include the fetched identifiers, in addition to the device ID, in the registration request message to private cloud152.

Each hypervisor120may run in conjunction with an OS in its respective host110. In some embodiments, a hypervisor can be installed as system level software directly on a hardware platform140of its respective host110(e.g., referred to as “bare metal” installation) and be conceptually interposed between the physical hardware and the guest OSs executing in the VMs112.

Hypervisor120includes host module115. In some embodiments, host module115is a lightweight host user world module deployed on hypervisor120. As discussed in more detail below with respect to theFIGS.205, host module115may receive identifiers of VMs112from a cloud appliance123and provide the respective identifiers to a VM112when queried by a cloud agent114of the VM112.

ESG122is configured to operate as a gateway device that provides components in data center102with connectivity to an external network, such as network160. ESG122may be addressable using addressing of the physical underlay network (e.g., data network150). ESG122may manage external public IP addresses for VMs112. ESG122may include a router (e.g., a virtual router and/or a virtual switch) that routes traffic incoming to and outgoing from data center102. ESG122also provides other networking services, such as firewalls, network address translation (NAT), dynamic host configuration protocol (DHCP), and load balancing. ESG122may be referred to as a nested transport node, for example, as the ESG122does encapsulation and decapsulation. ESG122may be a stripped down version of a Linux transport node, with the hypervisor module removed, tuned for fast routing. The term, “transport node” refers to a virtual or physical computing device that is capable of performing packet encapsulation/decapsulation for communicating overlay traffic on an underlay network. While ESG122is illustrated inFIG.1as a component outside of host110, in some embodiments, ESG122may be situated on host110and provide networking services, such as firewalls, NAT, DHCP, and load balancing services as a service VM (SVM).

Private cloud152provides cloud services156to data center102. Cloud agent114may communicate with private cloud152via ESG122. Cloud services156ingests a variety of data sources that are processed and stored as cybersecurity events, behaviors, and system state metrics that can be analyzed, visualized, and alerted upon for anomaly detection, incident investigation, and remediation of cybersecurity risks. Cloud services156can determine policies and rules for network access and publish the policies and rules to cloud agent114, so that cloud agent114can enforce the policies and rules on VM112.

Data center102includes a management plane and a control plane. The management plane and control plane each may be implemented as single entities (e.g., applications running on a physical or virtual compute instance), or as distributed or clustered applications or components. In alternative embodiments, a combined manager/controller application, server cluster, or distributed application, may implement both management and control functions. In the embodiment shown, network manager106at least in part implements the management plane and controller104at least in part implements the control plane

The control plane determines the logical overlay network topology and maintains information about network entities such as logical switches, logical routers, and endpoints, etc. The logical topology information is translated by the control plane into network configuration data that is then communicated to network elements of host(s)110. Controller104generally represents a control plane that manages configuration of VMs112within data center102. Controller104may be one of multiple controllers executing on various hosts in the data center that together implement the functions of the control plane in a distributed manner. Controller104may be a computer program that resides and executes in a central server in the data center or, alternatively, controller104may run as a virtual appliance (e.g., a VM) in one of hosts110. Although shown as a single unit, it should be understood that controller104may be implemented as a distributed or clustered system. That is, controller104may include multiple servers or virtual computing instances that implement controller functions. It is also possible for controller104and network manager106to be combined into a single controller/manager. Controller104collects and distributes information about the network from and to endpoints in the network. Controller104is associated with one or more virtual and/or physical CPUs (not shown). Processor(s) resources allotted or assigned to controller104may be unique to controller104, or may be shared with other components of the data center. Controller104communicates with hosts110via management network130, such as through control plane protocols. In some embodiments, controller104implements a central control plane (CCP).

Network manager106and virtualization manager108generally represent components of a management plane comprising one or more computing devices responsible for receiving logical network configuration inputs, such as from a user or network administrator, defining one or more endpoints (e.g., VCIs) and the connections between the endpoints, as well as rules governing communications between various endpoints.

In some embodiments, virtualization manager108is a computer program that executes in a central server in the data center (e.g., the same or a different server than the server on which network manager106executes), or alternatively, virtualization manager108runs in one of VMs112. Virtualization manager108is configured to carry out administrative tasks for the data center, including managing hosts110, managing VMs running within each host110, provisioning VMs, transferring VMs from one host to another host, transferring VMs between data centers, transferring application instances between VMs or between hosts110, and load balancing among hosts110within the data center. Virtualization manager108takes commands as to creation, migration, and deletion decisions of VMs and application instances on the data center. However, virtualization manager108also makes independent decisions on management of local VMs and application instances, such as placement of VMs and application instances between hosts110. In some embodiments, virtualization manager108also includes a migration component that performs migration of VMs between hosts110, such as by live migration.

In some embodiments, network manager106is a computer program that executes in a central server in networking environment100, or alternatively, network manager106may run in a VM, e.g., in one of hosts110. Network manager106communicates with host(s)110via management network130. Network manager106may receive network configuration input from a user or an administrator and generate desired state data that specifies how a logical network should be implemented in the physical infrastructure of the data center. Network manager106is configured to receive inputs from an administrator or other entity, e.g., via a web interface or application programming interface (API), and carry out administrative tasks for the data center, including centralized network management and providing an aggregated system view for a user.

Data center102includes a cloud appliance123. Cloud appliance123may run on a VM external to host110. In some embodiments, cloud appliance123may run on virtualization manager108. Cloud appliance123is configured to provide identifiers of VM(s)112to host module115. In some embodiments, cloud appliance123provides host module115with, for each VM112, a unique identifier of the VM (e.g., a “VMuuid”) and a unique identifier of virtualization manager108(e.g., a “Muuid”).

FIG.2illustrates an example call flow200for registering a new VM (i.e., a golden VM) with a cloud security monitoring service, according to an example embodiment of the present application.

At operation202, cloud appliance123provides identifiers to host module115running on hypervisor120. In some embodiments, cloud appliance123provides the identifiers to host module115via an API call. In some embodiments, the identifiers include, for each VM112running on the host110on which host module115is running, a unique identifier of the VM112(e.g., VMuuid) and a unique identifier of the virtual manager108(e.g., Muuid) associated with the VM112.

When VM1121is created, a communication channel is established between cloud agent1141, and the host module115running on the hypervisor120of the host110. In some embodiments, the communication channel is a VMCI. At operation204, cloud agent114detects the VMCI connection.

In some embodiments, cloud agent1141is configured to trigger a query to host module115when cloud agent1141detects a VMCI connection (e.g., a disconnection, reconnection, or connection of the VMCI). Accordingly, the detection of the VMCI connection, at operation204, may trigger cloud agent1141to query, at operation206, host module115for first identifiers of the VM1121.

At operation208, host module115responds to the query with the first identifiers configured by cloud appliance123(at operation204) for the VM1121associated with cloud agent1141. For example, host module115provides the VMuuid and Muuid of VM1121to cloud agent1141.

At operation210, cloud agent1141compares the fetched first identifiers to any persisted second identifiers. In this example, because the new VM is the golden VM, there are not any matching persisted second identifiers.

Because there are not any persisted second identifiers matching the fetched first identifiers, at operation212, cloud agent1141persists the first identifiers. For example, cloud agent1141may persist the VMuuid and Muuid on the VM disk (VMDK) of VM1121in a persistent memory location, such as in memory148.

At operation214, cloud agent114sends a registration request to cloud services156. In the illustrated example, because the VM is a golden VM, the VM does not have an existing device ID and registration ID and, therefore, performs registration with cloud services156. Cloud agent114includes a device ID in the registration request message sent to cloud services156. In some embodiments, the device ID is a randomly generated ID by cloud agent114. In some embodiments, cloud agent114includes the first identifiers (e.g., VMuuid and Muuid) fetched from host module115in the registration request message in addition to the device ID.

At operation216, cloud services156sends cloud agent1141a registration response including a registration ID.

At operation218, cloud agent1141stores the device ID and registration ID and, at operation220, cloud services156also stores the device ID and registration ID. Cloud agent1141may store the device ID and registration ID in storage144. In some embodiments, cloud services156stores the VMuuid and Muuid in addition to the device ID and registration ID. Cloud services156may store the identifiers in database158.

At operation222, cloud agent1141subsequently communicates with cloud services156using the device ID and registration ID pair. In some embodiments, cloud agent1141also includes the fetched first identifiers (e.g., VMuuid and Muuid) in subsequent communications with cloud services156. Cloud services156may use the VMuuid and Muuid to identify a communication coming from a VM112as associated with a particular virtualization manager108. Cloud services156may monitor for communications from cloud agent1141using the stored device ID and registration ID. For example, cloud services156may monitor communications from cloud agent1141and collect information about VM1121, process the data to detect cybersecurity events, behaviors, and/or system state metrics, to provide analysis, visualizations, alerts, and/or remediation for detected anomalies, incidents, vulnerabilities, suspicious activities, and/or malware.

FIG.3illustrates an example call flow300for a reconnected VM communicating with a cloud security monitoring service, according to an example embodiment of the present application.

In some embodiments, after performing the registration with cloud services156, shown in call flow200inFIG.2, a VM112may become disconnected and subsequently reconnect. In some embodiments, a registered golden VM1121or a registered clone VM1122may become disconnected. In some embodiments, VM112may become disconnected when the sensor running on the VM is upgraded to a higher version sensor. When VM112reconnects, cloud agent114re-establishes the VMCI connection with host module115. At operation324, cloud agent114detects the VMCI reconnection. Based on detecting the reconnection of the VMCI, cloud agent114is triggered to query host module115, operation326, for third identifiers of the VM112.

At operation328, host module115responds with the third identifiers. Because the VM was previously connected, the VM is the still the same VM and host module115provides the same third identifiers as the first identifiers fetched at operation208and previously persisted at operation212. Accordingly, when cloud agent114compares the fetched third identifiers to persisted fourth identifiers (which includes the previously persisted first identifiers), at operation330, cloud agent114determines that the fetched third identifiers match the persisted fourth identifiers (i.e., indicating that the VM is not a new clone VM).

In this case, the VM is determined to be the same VM that previously registered with cloud services156and does not need to re-register. At operation332, cloud agent114continues subsequent communications with cloud services156using the persisted first identifiers (VMuuid, Muuid) and the device ID and registration ID pair previously received (at operation216) and stored (at operation218).

FIG.4illustrates an example call flow400for re-registering a new clone VM with a cloud security monitoring service, according to an example embodiment of the present application. As discussed above, a VM may be cloned. For illustrative purposes, the VM clone discussed with respect toFIG.4may be a clone of the golden VM discussed with respect toFIG.2.

At operation434, cloud appliance123provides identifiers (e.g., VMuuid and Muuid) of clone VM1122to host module115when the clone VM1122is created. Because clone VM1122is different than the golden VM1121, host module115provides different identifiers to host module115, at operation434, than the identifiers provided to host module115at operation202for the golden VM1121.

When a VM clone is created, cloud agent1142on the clone VM resets the VMCI connection with host module115. At operation436, cloud agent1142detects the VMCI connection. Based on detecting the VMCI connection, cloud agent1142is triggered to query host module115for the identifiers, at operation438. At operation440, host module115responds with the identifiers for the clone VM1122(e.g., the identifiers received from cloud appliance123at operation434). Because the clone VM1122is a new VM (not the golden VM1121), the identifiers provided by the host module115for clone VM1122, at operation440, are different than the identifiers provided by the host module115for the golden VM1121(at operation210). Accordingly, when cloud agent1142compares the fetched identifiers with the persisted values (e.g., the identifiers persisted at operation212), at442, cloud agent1142determines the fetched identifiers do not match any persisted values.

Based on determining the fetched identifiers do not match any persisted values (e.g., indicating the VM is a clone), cloud agent1142persists the fetched identifiers, at operation444, and is triggered to perform a reregistration with cloud services156. In some embodiments, cloud agent1142is triggered to perform a reregistration by cloud services156. For example, cloud agent1142may send a device status message to cloud services156including the fetched identifiers. Cloud services156may send cloud agent1142a device status response message including a reregistration hint (e.g., an indication for cloud agent1142to re-register with cloud services156). Cloud services156may include the reregistration hint when the identifiers included in the device status message from cloud agent1142are different than identifiers stored by cloud services156for the device ID and registration ID pair.

At operation446, cloud agent1142sends a reregistration request to cloud services156. Cloud agent1142includes a new device ID in the reregistration request. For example, based on determining, at operation442, that the fetched identifiers do not match any persisted values, cloud agent1142generates a new device ID. In some embodiments, cloud agent1142includes the fetched identifiers in addition to the device ID in the reregistration request.

At operation448, cloud services156sends cloud agent1142a reregistration response with a new registration ID (i.e., different than the registration ID provided to cloud agent1141at operation216).

At operation450, cloud agent1142stores the new device ID and the new registration ID (e.g., such as in storage144) and, at operation452, cloud services156stores the new device ID and the new registration ID (e.g., in database158). In some embodiments, cloud services156also stores the VMuuid and the Muuid in addition to the new device ID and new registration ID. Accordingly, for subsequent communications with cloud services156, at operation454, cloud agent1142uses the new device ID and registration ID pair. In some embodiments, cloud agent1142further includes the fetched identifiers in the subsequent communications.

As mentioned above, Cloud services156may use the VMuuid and Muuid to associate a VM112with a particular virtualization manager108. In some embodiments, a VM112is moved to a different host110serviced by a different virtualization manager108. In this case, the VMCI connection will be reset and the cloud agent114for the VDI will query host module115for the identifiers of the migrated VM112. Because the VM112is the same VM, in some embodiments, host module115will return the same identifier of the VM (i.e., the VMuuid) and only the identifier of the virtual manager108(i.e., the Muuid) will be different. Thus, cloud agent132will not re-register with cloud services156. In some embodiments, the identifier of the VM changes, in addition to the identifier of the virtualization manager108, when the VM is moved. In this case, cloud agent114reregisters with cloud services156. Accordingly, in some embodiments, cloud agent114is triggered to perform a reregistration with cloud services156only when the VMuuid does not match any persisted values.

FIG.5illustrates an example workflow500for registering a VM with a cloud security monitoring service, according to an example embodiment of the present disclosure. Workflow500ofFIG.5may be performed, for example, by components of networking environment100illustrated inFIG.1

Workflow500may begin, at operation502, by initiating a VM. In some embodiments, initiating the VM includes installing a remote desktop on a VM1121. In some embodiments, initiating the VM includes reconnecting VM1121after a disconnection (e.g., to upgrade the sensor version). In some embodiments, initiating the VM includes cloning VM1122to create clone VM1122. In some embodiments, initiating the VM includes reconnecting clone VM1122after a disconnection (e.g., to upgrade the clone sensor version).

At operation504, a VMCI connection is detected. In some embodiments, a cloud agent1141detects an established VMCI connection with host module115after a new golden VM1121is created. In some embodiments, cloud agent1141detects a reset of the VMCI connection with host module115after the golden VM1121is reconnected after a previous disconnection. In some embodiments, a cloud agent1142detects a reset VMCI connection with host module115after a clone VM1122is created or reconnected after a previous disconnection.

At operations506, cloud agent114queries host module115for identifiers. For example, based on detecting the VMCI connect, at operation504, cloud agent114queries host module115for the VMuuid and Muuid for VM112.

At operation508, cloud agent114compares the fetched identifier to persisted identifiers to determine whether the fetched identifiers match any persisted identifiers.

Cloud agent114may determine that the fetched identifiers match persisted identifiers. For example, where the VM is a golden VM or clone VM that previously disconnected and has now reconnected, then fetched identifiers will match persisted identifiers. That is, cloud agent114will have previously fetched and persisted identifiers for the VM112and, because the reconnected VM is the same VM, the newly fetched identifiers will be the same as the previously fetched and persisted identifiers. Accordingly, cloud agent114does not need to reregister with cloud services156and, at operation510, uses the existing device ID, registration ID, and identifiers for subsequent communications with cloud services156.

Cloud agent114may determine that the fetched identifiers do not match persisted identifiers. For example, where the VM is a new golden VM or new clone VM the fetched identifiers will not match any persisted identifiers. At operation512, cloud agent114persists the fetched identifiers. At operation514, cloud agent114sends a registration request (or a reregistration request for a new clone VM) to cloud services156including a newly generated device ID and the fetched identifiers. At operation516, cloud agent114receives a registration response from cloud services156including a new registration ID. At operation518, cloud agent114and cloud services156each stores the device ID and the registration ID. At operation520, cloud agent114uses the new device ID and the new registration ID for subsequent communication with cloud services156.

Accordingly, by fetching identifiers from host module115when a connection is detected, a clone VM can determine that it is a clone and that it needs to generate a new device ID and reregister with the cloud security monitoring service to obtain a new registration ID. With the new device ID and registration ID pair, the clone VM can be uniquely identified and differentiated from the parent VM by the cloud security monitoring service. Thus, the cloud security monitoring service can identify the source of events reported to the cloud security monitoring services and take appropriate remediation steps.

FIG.6illustrates an example flow diagram600for registering a VM with a cloud security monitoring service, according to an example embodiment of the present application. In embodiments, operations illustrated in flow diagram600may be performed by a cloud agent, such as a cloud agent114.

The operations may begin, at block602, by detecting a connection between a cloud agent running in a virtual machine on a host (e.g., such as a host110) and a hypervisor module (e.g., such as host module115on hypervisor120) on the host. The cloud agent may be cloud agent1141of VM1121or cloud agent1142of VM1122.

At604, in response to detecting the connection (e.g., a VMCI connection), the cloud agent queries the hypervisor module for one or more first identifiers of the virtual machine. In some embodiments, the one or more first identifiers comprise a VM identifier (e.g., VMuuid) and an identifier of a virtualization manager (e.g. Muuid) associated with the VM1121or the VM1122.

At606, the cloud agent checks a database for one or more second identifiers stored in the database matching the one or more first identifiers received from the hypervisor module. For example, cloud agent1141or cloud agent1142checks in a database for persisted VMuuids and Muuids (the one or more second identifiers), to determine whether the database includes a VMuuid and Muuid that matches the VMuuid and Muuid fetched from host module115(the one or more first identifiers).

At608, based on finding no second identifiers stored in the database matching the one or more first identifiers, the cloud agent sends a request to a cloud security monitoring service (e.g., cloud services156) to register the virtual machine with the cloud security monitoring service.

In some embodiments, based on finding no second identifiers stored in the database matching the one or more first identifiers, the cloud agent randomly generates a device ID. The request to the cloud security monitoring service includes at least the device ID. In some embodiments, the virtual machine comprises a clone of another virtual machine, wherein the other virtual machine previously registered with the cloud security monitoring service.

In some embodiments, the cloud agent receives, from the cloud security monitoring service, a response including a registration ID. In some embodiments, the cloud agent includes the device ID, the registration ID, and the one or more first identifiers in subsequent communications with the cloud security monitoring service.

In some embodiments, the cloud security monitoring service monitors the subsequent communications, collects security information associated with the virtual machine based on the subsequent communications, and generates one or more security alerts based on the security information.

In some embodiments, based on find finding no second identifiers stored in the database matching the one or more first identifiers, the cloud agent persists the one or more first identifiers in the database.

In some embodiments, the cloud agent detects a reconnection between the cloud agent running in the virtual machine on the host and the hypervisor module on the host. In response to detecting the connection, the cloud agent queries the hypervisor module for one or more third identifiers of the virtual machine, where the one or more third identifiers are the one or more first identifiers. The cloud agent checks a database for one or more fourth identifiers stored in the database matching the one or more third identifiers received from the hypervisor module, where the one or more fourth identifiers includes the one or more first identifiers. Based on finding one or more fourth identifiers stored in the database matching the one or more third identifiers, the cloud agent communicates with the cloud service using a previously obtained device ID and registration ID. For example, VM1121or VM1122may cloud agent1141or cloud agent1142may become disconnected and subsequently reconnect. When VM1121or VM1122reconnects, cloud agent1141or cloud agent1142detects a VMCI connection with host module115and queries host module115for identifiers (the third identifiers) of VM1121or VM1122. Because VM1121or VM1122is the same VM that previously connected, host module115provides the first one or more identifiers to cloud agent1141or cloud agent1142. When cloud agent1141or cloud agent1142checks the identifiers persisted in the database (the one or more fourth identifiers), the identifiers include the previously persisted one or more first identifiers of VM1121or VM1122matching the one or more third identifiers fetched from host module115.

One or more embodiments may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), NVMe storage, Persistent Memory storage, a CD (Compact Discs), CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can be a non-transitory computer readable medium. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion. In particular, one or more embodiments may be implemented as a non-transitory computer readable medium comprising instructions that, when executed by one or more processors of a computing system, cause the computing system to perform a method, as described herein.