Patent Application
20240007465
In a software-defined data center (SDDC), virtual infrastructure, which includes virtual machines (VMs) and virtualized storage and networking resources, is provisioned from hardware infrastructure that includes a plurality of host computers (hereinafter also referred to simply as “hosts”), storage devices, and networking devices. The provisioning of the virtual infrastructure is carried out by SDDC management software that is deployed on management appliances, such as a VMware vCenter Server® appliance and a VMware NSX® appliance, from VMware, Inc. The SDDC management software communicates with virtualization software (e.g., a hypervisor) installed in the hosts to manage the virtual infrastructure.
It has become common for multiple SDDCs to be deployed across multiple clusters of hosts. Each cluster is a group of hosts that are managed together by the management software to provide cluster-level functions, such as load balancing across the cluster through VM migration between the hosts, distributed power management, dynamic VM placement according to affinity and anti-affinity rules, and high availability (HA). The management software also manages a shared storage device to provision storage resources for the cluster from the shared storage device, and a software-defined network, through which the VMs communicate with each other. For some customers, their SDDCs are deployed across different geographical regions, and may even be deployed in a hybrid manner, e.g., on-premise, in a public cloud, and/or as a service. “SDDCs deployed on-premise” means that the SDDCs are provisioned in a private data center that is controlled by a particular organization. “SDDCs deployed in a public cloud” means that SDDCs of a particular organization are provisioned in a public data center along with SDDCs of other organizations. “SDDCs deployed as a service” means that the SDDCs are provided to the organization as a service on a subscription basis. As a result, the organization does not have to carry out management operations on the SDDC, such as configuration, upgrading, and patching, and the availability of the SDDCs is provided according to the service level agreement of the subscription.
With a large number of SDDCs, monitoring and performing operations on the SDDCs through interfaces, e.g., application programming interfaces (APIs), provided by the management software, and managing the lifecycle of the management software, have proven to be challenging. Conventional techniques for managing the SDDCs and the management software of the SDDCs are not practicable when there is a large number of SDDCs, especially when they are spread out across multiple geographical locations and in a hybrid manner.
One or more embodiments provide a cloud platform from which various services, referred to herein as “cloud services” are delivered to the SDDCs through agents of the cloud services that are running in an appliance (referred to herein as an “agent platform appliance”). The cloud platform is a computing platform that hosts containers or virtual machines corresponding to the cloud services that are delivered from the cloud platform. The agent platform appliance is deployed in the same customer environment, e.g., a private data center, as the management appliances of the SDDCs. In one embodiment, the cloud platform is provisioned in a public cloud and the agent platform appliance is provisioned as a virtual machine in the customer environment, and the two communicate over a public network, such as the Internet. In addition, the agent platform appliance and the management appliances communicate with each other over a private physical network, e.g., a local area network. Examples of cloud services that are delivered include an SDDC configuration service, an SDDC upgrade service, an SDDC monitoring service, an SDDC inventory service, and a message broker service. Each of these cloud services has a corresponding agent deployed on the agent platform appliance. All communication between the cloud services and the management software of the SDDCs is carried out through the agent platform appliance, for example, through respective agents of the cloud services that are deployed on the agent platform appliance.
In one embodiment, a method of controlling access to components of an SDDC in a hybrid environment is provided, the hybrid environment including a cloud platform from which cloud services are delivered to the SDDC through agents deployed on an agent platform appliance which is connected to a management network of the SDDC. The method includes the steps of: transmitting to a first component of the SDDC, a request to create a first account for accessing the first component of the SDDC by a first agent, which is one of the agents deployed on the agent platform appliance; in response to the first agent requesting access to the first component of the SDDC, transmitting to the first component of the SDDC, credentials associated with the first account and a request for a first authentication token that authorizes the access to the first component of the SDDC; and upon receiving the first authentication token from the first component of the SDDC, transmitting the first authentication token to the first agent. The first agent transmits to the first component of the SDDC, the first authentication token along with a first command that instructs the first component of the SDDC to perform an operation.
Further embodiments include a non-transitory computer-readable storage medium comprising instructions that cause a computer system to carry out the above method, as well as a computer system configured to carry out the above method.
Techniques for connecting a tenant's SDDCs to a cloud platform are described. According to embodiments, an agent platform appliance is deployed in a customer environment of the tenant, the customer environment including one or more SDDCs with management software for the SDDCs executing therein. The agent platform appliance is connected to the same management network as management appliances on which the management software is deployed. To connect the tenant's SDDCs to cloud services of the cloud platform, agents are deployed on the agent platform appliance. The agents perform various functionalities, including transmitting commands to the management software of the SDDCs, acquiring authentication tokens for authenticating with the management software, and acquiring access tokens for authenticating with the cloud services.
Communications between the agent platform appliance and the SDDCs are authenticated using tokens (hereinafter referred to as “authentication tokens”). Each authentication token is scoped to a “role,” which is associated with privileges for accessing a component of each of the tenant's SDDCs. Accordingly, an agent of the agent platform appliance that possesses an authentication token is only permitted to issue commands that are within a defined set of privileges. Furthermore, communications between the agent platform appliance and the cloud platform are authenticated using tokens (hereinafter referred to as “access tokens”). Each access token authorizes accessing one or more of the cloud services and, for each cloud service that the access token authorizes access to, privileges defined by the cloud services for such access such as read and/or write access. Accordingly, an agent of the agent platform appliance that possesses an access token is only permitted to perform actions that fall within specified privileges, and with one or more specified cloud services. One of the agents of the agent platform appliance manages, for other agents executing therein, which authentication and access tokens the other agents are authorized to use. Such management improves security by preventing these agents from performing actions that are outside the scopes of the roles that are assigned to them.
Each of SDDCs 120 includes hosts 130, hosts 130 being constructed on server grade hardware platforms (not shown) such as x86 architecture platforms. Hosts 130 include conventional components of computing devices (not shown), such as one or more central processing units (CPUs), memory such as random-access memory (RAM), local storage such as one or more magnetic drives or solid-state drives (SSDs) and/or a host bus adapter for connection to a storage area network, and one or more network interface cards (NICs). The NIC(s) enable hosts 130 to communicate with each other and with other devices over a management network 104. Hosts 130 include software platforms including hypervisors (not shown), which are virtualization software layers that support VM execution spaces (not shown) within which VMs are concurrently instantiated and executed. Each of SDDCs 120 also includes additional hardware devices (not shown) such as shared storage and networking devices.
Each of SDDCs 120 includes a VIM server appliance 122, a network management appliance 126, and other SDDC components (not shown) each running various management software. VIM server appliance 122 logically groups hosts 130 into a cluster to perform cluster-level tasks such as provisioning and managing VMs and migrating VMs from one host 130 to another. One example of VIM server appliance 122 is a VMware vCenter Server® appliance from VMware, Inc. Network management appliance 126 provisions virtual networking resources for VMs executing on hosts 130. An example of network management appliance 126 is a VMware NSX® appliance from VMware, Inc.
VIM server appliance 122, network management appliance 126, and other SDDC components communicate via management network 104, and the various management software running thereon are referred to collectively herein as “management software.” Management network 104 is distinguishable from public network 101 in that it is a private network, e.g., a local area network or a sub-net, and is partitioned from public network 101 through a firewall. In some embodiments, each of the SDDC components including VIM server appliance 122 and network management appliance 126 is a VM instantiated on one or more of hosts 130. In other embodiments, each of the SDDC components may be implemented as a physical host having the conventional hardware platform described above with respect to hosts 130.
VIM server appliance 122 includes an authentication module 124, which communicates with an authentication server (not shown) to authenticate requests for access. When it is able to authenticate such requests, authentication module 124 issues role-based authentication tokens such as Security Assertions Markup Language (SAML) tokens. Each authentication token allows a party possessing the token to access VIM server appliance 122 to perform an operation on VIM server appliance 122 that is associated with the issued token. Network management appliance 126 similarly includes an authentication module 128, which communicates with an authentication server (not shown) to issue role-based authentication tokens for requesting parties. For security purposes, authentication tokens each have a specified time-to-live (TTL), after which the tokens expire.
Cloud platform 110 is provisioned in public cloud 10, and public cloud 10 is operated by a cloud computing service provider from a plurality of physical host computers (not shown). Cloud platform 110 includes cloud services such as cloud services 112, 113, and 114, a cloud authentication service 116, and an API gateway 118. The cloud services include an SDDC configuration service, an SDDC upgrade service, an SDDC monitoring service, an SDDC inventory service, and a message broker service.
Cloud authentication service 116 enables authentication with the cloud services. To enable such authentication, cloud authentication service 116 issues access tokens such as JavaScript Object Notation (JSON) web tokens (JWTs). Each access token allows a requesting party to communicate with a cloud service through API gateway 118, as discussed below. It should be noted that although cloud authentication service 116 is illustrated as being within cloud platform 110, cloud authentication service 116 may run on a virtual or physical server that is not part of cloud platform 110. For security purposes, access tokens each have a specified TTL, after which the tokens expire.
Agent platform appliance 140 is connected to management network 104 such that agent platform appliance 140 and SDDCs 120 are on the same side of a firewall (not shown) of customer environment 102. As a result, communications between agent platform appliance 140 and SDDCs 120 are secure and protected from attacks originating from outside customer environment 102 such as snooping attacks. In some embodiments, agent platform appliance 140 is a VM instantiated on a physical host having the conventional hardware platform described above with respect to hosts 130, including a CPU(s) configured to execute instructions such as executable instructions that perform one or more operations described herein and including memory in which such executable instructions are stored. In other embodiments, agent platform appliance 140 may be implemented as such a physical host.
On agent platform appliance 140, various agents are deployed, including cloud service agents 142, 143, and 144, discovery agents 150 and 160, and a coordinator agent 170. The agents on agent platform appliance 140 communicate with each other, e.g., through hypertext transfer protocol (HTTP) APIs. The agents on agent platform appliance 140 also communicate with SDDCs 120 and cloud platform 110, as discussed further below. Coordinator agent 170 deploys the agents on agent platform appliance 140, managing the lifecycle and orchestration thereof.
Some of the agents, referred to herein as “persistent agents,” execute in agent platform appliance 140 indefinitely once deployed. Other agents, referred to herein as “on-demand agents,” only execute in agent platform appliance 140 for limited times. Once deployed, the on-demand agents download executable scripts from which the on-demand agents issue commands to SDDCs 120 to execute workloads. Upon completion of the workloads, coordinator agent 170 deletes the on-demand agents. As illustrated in
Cloud service agents 142, 143, and 144, referred to collectively as “the cloud service agents,” correspond to cloud services 112, 113, and 114, respectively. The cloud service agents issue commands to the management software of SDDCs 120 and report results of operations to respective cloud services through APIs of the cloud services. The cloud service agents make API calls via API gateway 118 to respective cloud services, e.g., to report results of operations performed by the management software of SDDCs 120.
Discovery agents 150 and 160 are deployed on agent platform appliance 140 to manage communication with respective management software of SDDCs 120 and cloud services. Discovery agent 150 is deployed to manage communications with VIM server appliance 122 for all of SDDCs 120, and discovery agent 160 is deployed to manage communications with network management appliance 126 for all of SDDCs 120. There are also additional discovery agents (not shown) corresponding to the other SDDC components of SDDCs 120.
Discovery agents 150 and 160 store admin credentials of respective SDDC components for logging in to the respective SDDC components to perform administrative actions, as discussed further below. Discovery agents 150 and 160 also communicate with respective SDDC components to acquire authentication tokens for the cloud service agents. Discovery agents 150 and 160 maintain sets of SDDC privilege mappings 152 and 162, respectively. SDDC privilege mappings indicate which “roles” the cloud service agents are authorized for and what privileges are associated with these roles, as discussed further below in conjunction with
Using the admin credentials of respective SDDC components, discovery agents 150 and 160 create accounts in the respective SDDC components, referred to herein as “cloud service agent accounts.” Discovery agents 150 and 160 store credentials for the cloud service agent accounts in cloud service agent account mappings 154 and 164, respectively, as discussed further below in conjunction with
Discovery agents 150 and 160 are also configured to acquire access tokens from cloud authentication service 116. Discovery agents 150 and 160 acquire access tokens, for example, to enable the cloud service agents to directly report results of operations performed by respective management software, via APIs of the cloud services. Discovery agents 150 and 160, when deployed, are issued certificates that are associated with a private key and a public key. To authenticate with cloud authentication service 116, the discovery agents transmit a challenge phrase that is signed with the private key, and in response, cloud authentication service 116 decrypts the payload using the public key. If the decrypted payload matches the challenge phrase, cloud authentication service 116 issues the access token, which enables one of the cloud service agents to access one or more cloud services, as discussed further below.
Before providing access tokens to the cloud service agents, discovery agents 150 and 160 verify that the cloud service agents are authorized for the access tokens being requested. To perform this verification, discovery agents 150 and 160 maintain sets of cloud privilege mappings 156 and 166, respectively. Cloud privilege mappings indicate which cloud services the cloud service agents are authorized to communicate with and specified privileges for such communication, as discussed further below in conjunction with
In one embodiment, each of the cloud services is a microservice that is implemented as one or more container images executed on a virtual infrastructure of public cloud 10. Similarly, each of the agents deployed on agent platform appliance 140 is a microservice that is implemented as one or more container images executing in agent platform appliance 140.
A first role named “role-name-1” is associated with two privileges: an “access-privilege-1” and an “access-privilege-2.” Each of the two privileges associated with role-name-1 authorizes the retrieval of specified data or metadata. As depicted, “agent-name-1” is assigned role-name-1. Accordingly, if agent-name-1 requests an authentication token from discovery agent 150 for role-name-1, discovery agent 150 acquires the authentication token from VIM server appliance 122. The authentication token that is acquired is scoped by VIM server appliance 122 to permit retrieval of the data or metadata specified by access-privilege-1 and access-privilege-2.
A second role named “role-name-2” is associated with one privilege: an “update-privilege-1.” Update-privilege-1 authorizes the updating of specified data or metadata. As depicted, one agent named “agent-name-2” is assigned role-name-2. Accordingly, if agent-name-2 requests an authentication token from discovery agent 150 for role-name-2, discovery agent 150 acquires the authentication token from VIM server appliance 122. The authentication token that is acquired is scoped by VIM server appliance 122 to permit the updating of the data or metadata specified by update-privilege-1.
A third role named “role-name-3” is associated with one privilege: an “update-privilege-2.” Update-privilege-2 authorizes the updating of specified data or metadata. As depicted, one agent named “agent-name-3,” which is an on-demand agent, is assigned role-name-3. Accordingly, if agent-name-3 requests an authentication token from discovery agent 150 for role-name-3, discovery agent 150 acquires the authentication token from VIM server appliance 122. The authentication token that is acquired is scoped by VIM server appliance 122 to permit the updating of the data or metadata specified by update-privilege-2.
If one of the cloud service agents not identified as being authorized for a particular authentication token requests the authentication token from discovery agent 150, the request will be rejected. In addition, if one of the cloud service agents attempts to retrieve or update data or metadata of VIM server appliance 122 that is outside the scope of an authentication token, the attempt will fail.
The first two accounts are defined by the usernames “user-1” and “user-2,” respectively, and the passwords “pass-1” and “pass-2,” respectively. These two accounts are user accounts used for issuing commands to VIM server appliance 122. The third account is a cloud service agent account defined by the username “agent-name-1” and the password “pass-3.” Accordingly, to acquire an authentication token for agent-name-1, discovery agent 150 transmits to VIM server appliance 122, the credentials “agent-name-1” and “pass-3” along with a request for an authentication token for a role that agent-name-1 is authorized for.
Similarly, the fourth and fifth accounts are cloud service agent accounts defined by the usernames “agent-name-2” and “agent-name-3,” respectively, and the passwords “pass-4” and “pass-5,” respectively. Accordingly, to acquire an authentication token for agent-name-2, discovery agent 150 provides the credentials “agent-name-2” and “pass-4,” and to acquire an authentication token for agent-name-3, discovery agent 150 provides the credentials “agent-name-3” and “pass-5.” Agent-name-3 is a name of an on-demand agent, and the cloud service agent account defined by the username agent-name-3 is thus an “ephemeral account,” as discussed further below in conjunction with
A first role named “role-name-4” is associated with two privileges: a “cloud-service-1-r” privilege and a “cloud-service-2-w” privilege. Cloud-service-1-r authorizes reading data from a first cloud service “cloud service 1,” while cloud-service-2-w authorizes writing data to a second cloud service “cloud service 2.” As depicted, “agent-name-1” and “agent-name-2” are each assigned role-name-4. Accordingly, if agent-name-1 or agent-name-2 requests an access token from discovery agent 150 for role-name-4, discovery agent 150 acquires the access token from cloud authentication service 116. The access token that is acquired is scoped by cloud-service-1 and cloud-service-2 to permit the specified accesses.
A second role named “role-name-5” is associated with one privilege: a “cloud-service-2-rw” privilege. Cloud-service-2-rw authorizes reading data from and writing data to cloud service 2. As depicted, “agent-name-3,” which is an on-demand agent, is assigned role-name-5. Accordingly, if agent-name-3 requests an access token from discovery agent 150 for role-name-5, discovery agent 150 acquires the access token from cloud authentication service 116. The access token that is acquired is scoped by cloud-service-2 to permit the specified access.
If one of the cloud service agents not identified as being authorized for a particular access token requests the access token from discovery agent 150, the request will be rejected. In addition, if one of the cloud service agents attempts to access a cloud service that does not correspond to an access token provided by discovery agent 150 or attempts to perform an action that does not fall within the privileges of the access token, the attempt will fail.
Before method 500, discovery agent 150 is provided an “SDDC privilege file” and a “cloud privilege file,” which are files such as JSON files. The SDDC privilege file defines roles for accessing VIM server appliance 122, including information such as privileges and authorized cloud service agents for particular roles. Similarly, the cloud privilege file defines roles for accessing cloud service 122, including information such as privileges and authorized cloud service agents. The SDDC and cloud privilege files may be created by the tenant of SDDCs 120.
At step 502, discovery agent 150 selects an entry of the SDDC privilege file. At step 504, discovery agent 150 reads the entry to determine the role name and the associated privileges and authorized cloud service agents. At step 506, discovery agent 150 creates a new mapping, associating the determined role name with the determined privileges and authorized cloud service agents, and adds the new mapping to SDDC privilege mappings 152. At step 508, if there is another entry of the SDDC privilege file, method 500 returns to step 502, and discovery agent 150 selects another entry. Otherwise, method 500 moves to step 510.
At step 510, discovery agent 150 selects an entry of the cloud privilege file. At step 512, discovery agent 150 reads the entry to determine the role name and the associated privileges and authorized cloud service agents. At step 514, discovery agent 150 creates a new mapping, associating the determined role name with the determined privileges and authorized cloud service agents, and adds the new mapping to cloud privilege mappings 156. At step 516, if there is another entry of the cloud privilege file, method 500 returns to step 510, and discovery agent 150 selects another entry. Otherwise, method 500 ends.
After method 500, the tenant of SDDCs 120 may update the SDDC and cloud privilege files such as when deploying a new on-demand service agent. Accordingly, steps 504 and 506 may be repeated to read new entries of the SDDC privilege file and create new mappings for SDDC privilege mappings 152. Similarly, steps 512 and 514 may be repeated to read new entries of the cloud privilege file and create new mappings for cloud privilege mappings 156.
At step 602, discovery agent 150 selects one of the cloud service agents of agent platform appliance 140. At step 604, discovery agent 150 reads SDDC privilege mappings 152 to determine which roles the selected cloud service agent is authorized for. The selected cloud service agent may be authorized for only a single role or may be authorized for a plurality of roles. At step 606, discovery agent 150 creates a username and password for a new cloud service agent account to be created for the selected cloud service agent.
At step 608, discovery agent 150 transmits a request to VIM server appliance 122 to create a cloud service agent account. The request includes admin credentials of VIM server appliance 122 such as a username and password authenticating the request as being from discovery agent 150, which has administrative privileges such as to create cloud service agent accounts and to update the passwords of such cloud service agent accounts, as discussed further below. The request also includes the cloud service agent account credentials created at step 606 and role names of the roles that the selected cloud service agent is authorized for.
At step 610, VIM server appliance 122 verities the admin credentials to determine that the request is from discovery agent 150. At step 612, VIM server appliance 122 creates the requested cloud service agent account with the username and password created at step 606. VIM server appliance 122 further links the new cloud service agent account to roles that the selected cloud service agent is authorized for. At step 614, VIM server appliance 122 reports, to discovery agent 150, the creation of the cloud service agent account.
At step 616, discovery agent 150 creates a new cloud service agent account mapping, including the username and password created at step 606, and adds the new mapping to cloud service agent account mappings 154. At step 618, if there is another one of the cloud service agents to create a cloud service agent account for, method 600 returns to step 602, and discovery agent 150 selects another one of the cloud service agents. Otherwise, method 600 ends.
Method 600 may be repeated for each of SDDCs 120 to create cloud service agent accounts therefor. Furthermore, discovery agent 150 periodically transmits to VIM server appliance 122, requests to update the passwords associated with each of the cloud service agent accounts to improve the security of the accounts. The requests include amin credentials of VIM server appliance 122. Discovery agent 150 generates updated passwords and updates cloud service agent account mappings 154 accordingly. Additionally, for on-demand agents, the cloud service agent accounts are ephemeral. An ephemeral cloud service agent account may have a specified TTL, and upon the specified TTL elapsing, discovery agent 150 transmits a request to VIM server appliance 122 to delete the account. Discovery agent 150 may also transmit the request to VIM server appliance 122 to delete the account upon the deletion of the on-demand agent by coordinator agent 170. Discovery agent 150 then removes the ephemeral accounts from cloud service agent account mappings 154.
At step 708, if the cloud service agent is authorized, method 700 moves to step 710, and discovery agent 150 acquires an authentication token for the requested role, as discussed further below in conjunction with
Returning to step 708, if the cloud service agent is not authorized for the requested role, method 700 moves to step 714. At step 714, discovery agent 150 reports to the cloud service agent that the requested access to VIM server appliance 122 is denied. After step 714, method 700 ends.
At step 806, discovery agent 150 determines from cloud service agent account mappings 154, the credentials for the cloud service agent's account with VIM server appliance 122. At step 808, discovery agent 150 transmits a request to VIM server appliance 122 for the authentication token that is scoped to the requested role. The request includes the cloud service agent account credentials determined at step 806 and the role name of the requested role. At step 810, VIM server appliance 122 verifies the cloud service agent account credentials to determine that the cloud service agent account is linked to the requested role.
At step 812, VIM server appliance 122 returns an authentication token scoped to the requested role, to discovery agent 150. At step 814, discovery agent 150 stores the authentication token in cache 158. At step 816, discovery agent 150 transmits an authentication token to the cloud service agent, which was either found in cache 158 at step 802 or returned by VIM server appliance 122 at step 812. After step 816, method 800 ends.
At step 908, if the cloud service agent is authorized, method 900 moves to step 910, and discovery agent 150 acquires an access token for the requested role, as discussed further below in conjunction with
Returning to step 908, if the cloud service agent is not authorized for the requested role, method 900 moves to step 914. At step 914, discovery agent 150 reports to the cloud service agent that the requested access to cloud service 112 is denied. After step 914, method 900 ends.
At step 1006, discovery agent 150 transmits a request to cloud authentication service 116 for an access token that is scoped to the requested role. The request includes a payload signed by a private key of the tenant and the name of the requested role. At step 1008, cloud authentication service 116 verifies the payload using a public key of the tenant to determine that the request is from discovery agent 150. At step 1010, cloud authentication service 116 returns an access token scoped to the requested role to discovery agent 150. At step 1012, discovery agent 150 stores the access token in cache 158. At step 1014, discovery agent 150 transmits an access token to the cloud service agent, which was either found in cache 158 at step 1002 or returned by cloud authentication service 116 at step 1010. After step 1014, method 1000 ends.
The embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities. Usually, though not necessarily, these quantities are electrical or magnetic signals that can be stored, transferred, combined, compared, or otherwise manipulated. Such manipulations are often referred to in terms such as producing, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments may be useful machine operations.
One or more embodiments of the invention also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for required purposes, or the apparatus may be a general-purpose computer selectively activated or configured by a computer program stored in the computer. Various general-purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations. The embodiments described herein may also be practiced with computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, etc.
One or more embodiments of the present invention may be implemented as one or more computer programs or as one or more computer program modules embodied in computer-readable media. The term computer-readable medium refers to any data storage device that can store data that can thereafter be input into a computer system. Computer-readable media may be based on any existing or subsequently developed technology that embodies computer programs in a manner that enables a computer to read the programs. Examples of computer-readable media are hard disk drives (HDDs), SSDs, network-attached storage (NAS) systems, read-only memory (ROM), RAM, compact disks (CDs), digital versatile disks (DVDs), magnetic tapes, and other optical and non-optical data storage devices. A computer-readable medium can also be distributed over a network-coupled computer system so that computer-readable code is stored and executed in a distributed fashion.
Although one or more embodiments of the present invention have been described in some detail for clarity of understanding, certain changes may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein but may be modified within the scope and equivalents of the claims. In the claims, elements and steps do not imply any particular order of operation unless explicitly stated in the claims.
Virtualized systems in accordance with the various embodiments may be implemented as hosted embodiments, non-hosted embodiments, or as embodiments that blur distinctions between the two. Furthermore, various virtualization operations may be wholly or partially implemented in hardware. For example, a hardware implementation may employ a look-up table for modification of storage access requests to secure non-disk data. Many variations, additions, and improvements are possible, regardless of the degree of virtualization. The virtualization software can therefore include components of a host, console, or guest operating system (OS) that perform virtualization functions.
Boundaries between components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the invention. In general, structures and functionalities presented as separate components in exemplary configurations may be implemented as a combined component. Similarly, structures and functionalities presented as a single component may be implemented as separate components. These and other variations, additions, and improvements may fall within the scope of the appended claims.
