Method, system, and non-transitory computer-readable medium for edge attestation of computing node authorization in a cloud infrastructure system

Abstract

The present embodiment relates to edge proof of host node access to a cloud infrastructure environment. An authentication data set may be obtained from a console for authorizing the host node. The authentication data set may include a first endorsement key and an authentication policy that identifies characteristics of the host node. The host node may send a request for a network address for connecting to the cloud infrastructure environment. The host node may generate a second endorsement key and authentication data that may be verified to correspond to the authentication data set received from the console. In response to verification of the second endorsement key and the received host node authentication data, a network address may be provided to the host node, which may be used to connect to the cloud infrastructure environment using the network address.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to U.S. patent application No. 17 / 523,789, filed on November 10, 2021, entitled “Edge Attestation for Authorization of a Computing Node in a Cloud Infrastructure System,” the disclosure of which is incorporated herein by reference in its entirety for all purposes. Technical Field

[0003] The disclosed technology relates to cloud computing authentication. More specifically, the disclosed technology relates to authenticating a new host node that has just joined a cloud computing environment by using an edge component of the environment, for example, before granting the host node network access rights. Background Art

[0004] In a data center environment, new components (e.g., servers) may be added as new host devices. New components may be added to a cloud computing environment to increase computing resources in the cloud environment or to provide additional functionality to applications / services executed on components in the cloud environment. New components may be physically connected to other devices in the data center environment, thereby connecting multiple devices that implement the cloud computing environment. For example, a colocation center may provide a data center environment that houses components that implement the cloud computing environment.

[0005] However, in many cases, a data center environment (e.g., a hosting center) may house computing devices / data centers of other entities. In such cases, another entity may have access to areas near the data center environment that houses components that implement the cloud computing environment. For example, another entity may maliciously connect a device to the data center environment without authorization. Without requiring any verification process, the connected device may access data and / or services privately maintained in the cloud computing environment. Summary of the invention

[0006] The present embodiment relates to edge proof of host node access to a cloud infrastructure environment. A first exemplary embodiment provides a method for proof of host node access to a cloud infrastructure environment. The method may include obtaining an authentication data set for authorizing the host node from a console. The authentication data set may include a first endorsement key and an authentication policy that identifies a characteristic of the host node. The authentication policy may include a first platform configuration register (PCR) value.

[0007] The method may also include obtaining, from the host node, a request for a network address for connecting to the cloud infrastructure environment. The method may also include receiving a second endorsement key from the host node. The method may also include comparing the second endorsement key with the first endorsement key received in the authentication data set to verify the second endorsement key.

[0008] The method may also include receiving a host node authentication data set from the host node. The host node authentication data set may include a second PCR value, which includes a hash register value during the boot process of the host node. The method may also include comparing the received host node authentication data with the authentication policy received in the authentication data set to verify the received host node authentication data by determining whether the first PCR value matches the second PCR value. The method may also include providing a network address to the host node in response to verifying the second endorsement key and the received host node authentication data. The host node may be configured to connect to the cloud infrastructure environment using the network address.

[0009] A second exemplary embodiment relates to a cloud infrastructure node. The cloud infrastructure node may include a processor and a non-transitory computer-readable medium. The non-transitory computer-readable medium may include instructions that, when executed by the processor, cause the processor to obtain, from a console, an authentication data set for authorizing a host node. The authentication data set includes a first endorsement key and an authentication policy that identifies a characteristic of the host node. The instructions may also cause the processor to obtain, from the host node, a request for a network address for connecting to a cloud infrastructure environment.

[0010] The instruction may also cause the processor to send a request for a second endorsement key to the host node. The instruction may also cause the processor to receive the second endorsement key from the host node. The instruction may also cause the processor to compare the second endorsement key with the first endorsement key received in the authentication data set to verify the second endorsement key. The instruction may also cause the processor to send a request for host node authentication data to the host node. The instruction may also cause the processor to receive host node authentication data from the host node.

[0011] The instructions may also cause the processor to compare the received host node authentication data with the authentication policy received in the authentication data set to verify the received host node authentication data. The instructions may also cause the processor to provide a network address to the host node in response to verifying the second endorsement key and the received host node authentication data. The host node may be configured to connect to the cloud infrastructure environment using the network address.

[0012] A third exemplary embodiment relates to a non-transitory computer-readable medium. The non-transitory computer-readable medium may include a sequence of instructions stored thereon, which, when executed by a processor, causes the processor to perform a process. The process may include obtaining, from a console, a set of authentication data for authorizing a host node. The set of authentication data includes a first endorsement key and an authentication policy that identifies a characteristic of the host node. The process may also include obtaining, from the host node, a request for a network address for connecting to a cloud infrastructure environment.

[0013] The process may also include receiving a request for a pre-boot execution environment client from the host node. The process may also include providing the pre-boot execution environment client to the host node, wherein the host node is configured to perform a boot process using the pre-boot execution environment client.

[0014] The process may also include receiving a second endorsement key from the host node. The process may also include comparing the second endorsement key to the first endorsement key received in the authentication data set to verify the second endorsement key. The process may also include receiving, from the host node, a host node authentication data set derived during a boot process using a pre-boot execution environment client.

[0015] The processing may also include comparing the received host node authentication data with the authentication policy received in the authentication data set to verify the received host node authentication data. The processing may also include providing a network address to the host node in response to verifying the second endorsement key and the received host node authentication data. The host node may be configured to connect to the cloud infrastructure environment using the network address. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 is a block diagram of an example network environment in accordance with at least one embodiment.

[0017] Figure 2 is a block diagram of an example cloud infrastructure system in accordance with at least one embodiment.

[0018] Figure 3 is a signaling process illustrating an example edge attestation process in accordance with at least one embodiment.

[0019] Figure 4 is a block diagram illustrating an example method performed by a SmartNIC for performing edge attestation processing in accordance with at least one embodiment.

[0020] Figure 5 is a block diagram illustrating an example method performed by a host node to be authenticated using edge attestation processing in accordance with at least one embodiment.

[0021] Figure 6is a block diagram illustrating one mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0022] Figure 7 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0023] Figure 8 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0024] Fig. 9 is a block diagram illustrating another mode for implementing a cloud infrastructure as a service system according to at least one embodiment.

[0025] Fig.10 is a block diagram illustrating an example computer system in accordance with at least one embodiment. DETAILED DESCRIPTION

[0026] In many cases, multiple computing devices (e.g., servers) and applications / services executed on multiple computing devices can implement a cloud computing infrastructure. In addition, new host nodes can be added to multiple computing devices to increase the computing resources or functionality of the cloud infrastructure. In this case, the new host nodes can be managed by verifying the identity and security features of the new computing devices. This verification can be performed through remote attestation, which can include the computing device providing cryptographically verifiable information to verify the identity and configuration of each computing device. The remote attestation process can be used to manage the security of devices in the network and identify, for example, the status of computing devices.

[0027] Instead of implementing a centralized service to centrally implement remote attestation in a cloud infrastructure, the verification service can be performed by an edge node close to a host node in a cloud infrastructure environment. The attestation verification service can be included as part of a bump-in-the-wire node (e.g., a smart network interface controller (SmartNIC)) in the cloud infrastructure. Implementing the attestation verification service at the SmartNIC can offload processing tasks from the central components of the cloud infrastructure, thereby improving the data processing efficiency of the cloud infrastructure. In addition, in the event of a failure of the attestation verification service, only a few devices / applications may be affected because the attestation verification service is executed on the SmartNIC at the edge of the cloud infrastructure.

[0028] The present embodiment relates to an edge certification service for authentication and authorization of host nodes in a network environment. Before allowing a new host node to access the network, an authentication process can be performed. For example, a console can interact with an edge component (e.g., smartNIC) in a cloud infrastructure to obtain a set of authentication data (e.g., public endorsement key, lease authentication data) for verifying the new host node.

[0029] In some cases, the SmartNIC may provide a pre-boot execution environment (e.g., iPXE) to the host node so that the host node performs a boot process without pre-installing an OS on the host node. For example, an iPXE client may be provided to the host node to allow communication between an iPXE client executed on the host node and an iPXE environment executed on the SmartNIC.

[0030] The SmartNIC may send a request for an endorsement key to the host node, and in response, the host node may generate an endorsement key (e.g., based on a generated public / private key pair). The SmartNIC may obtain the endorsement key and compare it to a public endorsement key received in the authentication data set, and verify whether the endorsement key obtained from the host node corresponds to (e.g., matches) the public endorsement key received in the authentication data set. Verifying the received endorsement key may verify the identity of the host node.

[0031] The SmartNIC may send a request for authentication data to the host node. The authentication data may include data for authenticating the host node, such as a firmware configuration, a device configuration, a platform configuration register (PCR) value, etc. The host node may generate authentication data, and the generated authentication data may be provided to the SmartNIC. The received authentication data may be compared with the authentication policy received in the authentication data set to verify the received authentication data (e.g., by matching the PCR value generated by the host node with the corresponding PCR value provided in the authentication data set).

[0032] The SmartNIC may provide a network address to the host node in response to verifying the authentication data received from the host node and the received endorsement key. Providing a network address (e.g., an Internet Protocol (IP) address) to the host node may allow the host node to access components / applications / services in the cloud infrastructure. This may allow for increased security when providing access to the cloud infrastructure.

[0033] A. System Overview

[0034] Figure 11 is a block diagram of an example network environment 100. The network environment 100 may allow data communication between devices in the environment using one or more networks (e.g., the Internet). Figure 1 As shown in , the network environment 100 may include any one of a console 102 , a cloud infrastructure (CI) system 104 (and corresponding computing devices 106 a - c ), and a host node 108 .

[0035] The console 102 may include a computing device (e.g., a laptop) capable of communicating with the CI system 104. For example, the console 102 may provide instructions to the CI system 104 for creating an instance of the host node 108 (e.g., including a set of authentication data). As another example, the console 102 may instruct the host node 108 to obtain a pre-boot execution environment client (e.g., iPXE) from the CI system 104 or to initiate a session between the host node 108 and the SmartNIC 110.

[0036] As described herein, the CI system 104 may include one or more interconnected computing devices that implement one or more cloud applications or services. For example, the CI system 104 may store database data and provide access to the database data (e.g., via database queries). The computing devices (e.g., 106a-106c) included in the CI system 104 may be located in one or more data center environments (e.g., a hosting center).

[0037] like Figure 1 As shown in FIG. 1 , computing device 106 c may implement SmartNIC 110. SmartNIC 110 may be located on an edge component (e.g., computing device 106 c) in CI system 104. For example, SmartNIC 110 may reside on a server deployed in a data center that serves as an edge access point to CI system 104. SmartNIC 110 may perform remote attestation services as described herein.

[0038] The host node 108 may include a computing device (e.g., a server) or a series of computing devices introduced to the CI system 104. For example, the host node may include a server connected to the CI system 104 at a data center environment (e.g., a hosting center) and requesting access to the CI system 104. The host node 108 may be configured to perform various processing tasks or implement one or more applications / services. As described herein, the host node 108 may request a network address for accessing the CI system 104 and receive the network address in response to the SmartNIC 110 verifying the endorsement key and authentication data provided by the console 102 and the host node 108, respectively.

[0039] Figure 2is a block diagram of an example cloud infrastructure system 104. As described above, the CI system 104 may include one or more interconnected computing devices that implement various applications / services. The CI system 104 may include one or more central computing devices that implement core functions of the CI system 104 and edge devices that maintain SmartNICs 110. SmartNICs 110 may interact with a host node (e.g., 108) to obtain authentication data and verify authentication data, as described herein.

[0040] The CI system 104 may include a pre-boot execution environment 204. The pre-boot execution environment 204 may include an environment (e.g., iPXE) configured to provide a client to a host node, allowing the host node to execute the pre-boot execution environment without an operating system (OS) installed on the host node. For example, the host node may retrieve the iPXE client from the SmartNIC and execute the iPXE client by interacting with the pre-boot execution environment 204 executed in the CI system 104.

[0041] The CI system 104 can include a storage module 206. The storage module 206 can store various data types across devices in the CI system 104 (eg, a mounted boot partition for a verified host node).

[0042] The CI system 104 may include console authentication data 208. The console authentication data 208 may include data for edge certification of a new host node in a set of authentication data obtained from the console. The console authentication data 208 may include a first endorsement key (EK) 210a and a lease authorization policy 212. In some cases, the console authentication data 208 may store authentication data obtained for multiple host nodes introduced to the CI system 104.

[0043] The first EK 210a may include a key (eg, a Trusted Platform Module (TPM) RSA key) provided by the console to identify the host node. The lease authorization policy 212 may include characteristics of the host node, such as firmware version, configuration settings, PCR values, and the like.

[0044] The CI system 104 may also include host authentication data 214. The host authentication data 214 may include information obtained from the host node, such as the second EK 210b and authentication data (or "auth data") 216. The data in the host authentication data 214 may be compared to the console authentication data 208 to identify and authenticate the host node, as described herein.

[0045] The CI system 104 may include an authentication data retrieval module 218. The authentication data retrieval module 218 may obtain authentication data (e.g., console authentication data 208) from a host node and receive host authentication data (e.g., 214), as described herein. In some cases, the authentication data retrieval module 218 may request the host authentication data (e.g., 214) in response to providing a pre-boot execution environment client to the host node and / or receiving a request for a network address from the ten host nodes.

[0046] CI system 104 may include key verification module 220. Key verification module 220 may obtain a key from a host node and verify the key using a key provided by console 102. Verifying the key may include determining whether the received key matches / corresponds to (e.g., includes a number of similarities to) a key provided by the console.

[0047] The CI system 104 may include an authentication (auth) data verification module 222. The auth data verification module 222 may obtain / identify auth data and compare the received auth data to an auth policy received from a console. For example, the auth data may specify a firmware version, a host node configuration, a PCR value (e.g., a series of hash values ​​added in response to a component being identified / activated during a boot process), etc. In this example, the auth data may be compared to a lease auth policy to match values ​​specific to the host node, firmware version, data type, etc. In response to the key and auth data being verified, the host node may be verified and allowed to access the cloud infrastructure (e.g., by providing a network address to the host node).

[0048] B. Example Method for Performing the Edge Proofing Process

[0049] Figure 3 3 is a signaling process 300 illustrating an example edge certification process. Figure 3 As shown in , the console 302 and the host node 308 can interact with the SmartNIC 306 (e.g., executed on an edge computing device in the CI system).

[0050] At 310, console 302 may send a request to create a new host instance to SmartNIC 306. The request to create a new host instance may identify a new host node and may include a first endorsement key and a lease auth policy for verifying the host node.

[0051] At 312, the console 302 may send a request to start a host node instance to the host node 308. The request received by the host node 308 may include instructions to connect to the SmartNIC 306 and initiate a startup process.

[0052] At 314, the host node 308 may send a request for a pre-boot execution environment (e.g., an iPXE client) to the SmartNIC 306. The request may include a request for an iPXE client from the SmartNIC 306. As described herein, the iPXE client may allow the host node 308 to perform a boot process without loading an operating system on the host node 308.

[0053] At 316, the SmartNIC 306 may provide a pre-boot execution environment (e.g., an iPXE client) to the host node. At 318, the host node 308 may execute the pre-boot execution environment (e.g., by interacting with an iPXE instance associated with the SmartNIC 306 executing on the edge device via the iPXE client). Executing the pre-boot execution environment may perform a boot process, including running a boot process, launching services / applications and components, etc.

[0054] In some cases, during the boot process, PCR values ​​may be calculated. The PCR values ​​may include a series of hash values ​​that indicate each component / service initiated by the host node 308. The PCR values ​​may indicate the state of the host node 308 after the boot process.

[0055] At 320, the host node 308 may request a network address from the SmartNIC 306. The network address (eg, IP address) may allow connection to the CI system. The SmartNIC 306 may give out the network address only in response to authenticating the host node, as described herein.

[0056] At 322, the SmartNIC 306 may request a public endorsement key (EK) from the host node 308. At 324, the host node 308 may generate a public / private key pair. At 326, the host node 308 may generate a public endorsement key from the key pair. At 328, the host node 308 may send the public endorsement key to the SmartNIC 306. The public endorsement key may be compared to a key provided during a create instance request provided by the console (e.g., at 310).

[0057] At 330, the SmartNIC 306 may request an auth data set from the host node 308. At 332, the host node 308 may generate the requested auth data set (e.g., detailed information related to the host node, firmware version, configuration settings, PCR values), as specified in the request for the auth data set. At 334, the host node 308 may send the auth data set to the SmartNIC 306 to verify the auth data.

[0058] At 336, the SmartNIC may verify the received public endorsement key and auth data set. This may include comparing the data received from the host node 308 with the data obtained from the console 302 (eg, at 310) in the request to create the instance.

[0059] In response to validating the received data, at 338, SmartNIC 306 can send a network address to host node 308. The network address can allow connection and data communication between host node 308 and CI system. At 340, SmartNIC 306 can install a boot partition specific to the host node at block storage device 304.

[0060] Figure 4 4 is a block diagram illustrating an example method performed by a SmartNIC for performing edge certification processing. At 402, the SmartNIC may obtain an authentication data set for authorizing a host node from a console. The authentication data set may include a first endorsement key and an authentication policy identifying characteristics of the host node.

[0061] At 404, the SmartNIC provides a pre-boot execution environment (e.g., an iPXE client). The SmartNIC may receive a request for a pre-boot execution environment client from a host node. The SmartNIC may provide the pre-boot execution environment client to the host node. The host node may be configured to perform a boot process using the pre-boot execution environment client.

[0062] At 406, the SmartNIC may obtain a request from the host node for a network address for connecting to the cloud infrastructure environment. In some cases, the request for the network address is obtained from the host node in response to the host node connecting to a data center environment including one or more computing devices implementing the cloud infrastructure environment.

[0063] At 408, the SmartNIC may send a request for a second endorsement key to the host node. At 410, the SmartNIC may receive the second endorsement key from the host node. The second endorsement key may include a public attestation identity key (AIK).

[0064] At 412, the SmartNIC may compare the second endorsement key to the first endorsement key received in the authentication data set to verify the second endorsement key. This may include determining that at least one value in the second endorsement key matches a corresponding value in the first endorsement key.

[0065] At 414, the SmartNIC may send a request for host node authentication data to the host node. At 416, the SmartNIC may receive host node authentication data from the host node.

[0066] At 418, the SmartNIC may compare the received host node authentication data with the authentication policy received in the authentication data set to verify the received host node authentication data. This may include identifying a first platform configuration register (PCR) value included in the authentication policy and a second PCR value provided in the received host node authentication data (e.g., generated during the boot process). The second PCR value may include a hash register value during the boot process of the host node, which indicates the state of the host node after the boot process. This may also include determining whether the first PCR value matches the second PCR value. In response to determining that the first PCR value matches the second PCR value, the received host node authentication data may be verified.

[0067] At 420, the SmartNIC may provide a network address to the host node. The host node may be configured to connect to the cloud infrastructure environment using the network address. This may be performed in response to verifying the second endorsement key and the received host node authentication data.

[0068] Figure 5 500 is a block diagram illustrating an example method performed by a host node to be verified using edge proof processing. At 502, the host node may receive a request to launch an instance from a console. The request to launch an instance may include instructions to communicate with a SmartNIC and instructions to implement a boot process.

[0069] At 504, the host node may request a pre-boot execution environment from the SmartNIC. At 506, the host node may receive the pre-boot execution environment from the SmartNIC. At 508, the host node may execute the pre-boot execution environment. The pre-boot execution environment may include an iPXE client that can perform a boot process by interacting with an iPXE instance at the SmartNIC without using an operating system on the host node.

[0070] At 510, the host node may send a request for a network address (e.g., an IP address) from the SmartNIC. At 512, the host node may receive a request for a public endorsement key (EK pub) from the SmartNIC. At 514, the host node may generate the EK pub. The EK pub may be generated from a public / private key pair generated by the host node. At 516, the host node may send the generated EK pub to the SmartNIC. The SmartNIC may verify the received EK pub (e.g., or a second endorsement key) by comparing the received EK pub to the key received by the console.

[0071] At 518, the host node may receive a request for auth data (e.g., host node authentication data). At 520, the host node may generate auth data (e.g., based on a second PCR value of a boot process). At 522, the host node may send the generated auth data to the SmartNIC. The SmartNIC may verify the auth data by comparing the received auth data to an authentication policy.

[0072] At 524, the host node may receive a network address from the SmartNIC. The network address may allow for connection / data transfer with the cloud infrastructure using the network address. The network address may be received in response to the SmartNIC validating the auth data.

[0073] C. IaaS Overview

[0074] As mentioned above, Infrastructure as a Service (IaaS) is a specific type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, IaaS providers can also provide various services to accompany these infrastructure components (e.g., billing, monitoring, logging, load balancing and clustering, etc.). Therefore, since these services may be policy-driven, IaaS users may be able to implement policies to drive load balancing to maintain application availability and performance.

[0075] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet, and can use the cloud provider's services to install the remaining elements of the application stack. For example, a user can log in to the IaaS platform to create a virtual machine (VM), install an operating system (OS) on each VM, deploy middleware such as a database, create storage buckets for workloads and backups, and even install enterprise software into the VM. Customers can then use the provider's services to perform a variety of functions, including balancing network traffic, troubleshooting application problems, monitoring performance, managing disaster recovery, and more.

[0076] In most cases, the cloud computing model will require the involvement of a cloud provider. A cloud provider may, but need not, specialize in providing (e.g., provisioning, renting, selling) third-party IaaS services. An entity may also choose to deploy a private cloud, thereby becoming its own infrastructure service provider.

[0077] In some examples, IaaS deployment is the process of placing a new application or a new version of an application onto a prepared application server, etc. It may also include the process of preparing the server (e.g., installing libraries, daemons, etc.). This is typically managed by the cloud provider, below the hypervisor layer (e.g., servers, storage, network hardware, and virtualization). Thus, the customer may be responsible for handling (OS), middleware, and / or application deployment (e.g., on self-service virtual machines (e.g., that can be started on demand)), etc.

[0078] In some examples, IaaS provisioning can refer to obtaining computers or virtual hosts for use, and even installing required libraries or services on them. In most cases, deployment does not include provisioning, and provisioning may need to be performed first.

[0079] In some cases, there are two different challenges with IaaS provisioning. First, there is the initial challenge of provisioning the initial set of infrastructure before anything is running. Second, once everything has been provisioned, there is the challenge of evolving the existing infrastructure (e.g., adding new services, changing services, removing services, etc.). In some cases, both of these challenges can be addressed by enabling configuration that defines the infrastructure in a declarative manner. In other words, the infrastructure (e.g., which components are required and how they interact) can be defined by one or more configuration files. Therefore, the overall topology of the infrastructure (e.g., which resources depend on which resources, and how they work together) can be described in a declarative manner. In some cases, once the topology is defined, workflows can be generated to create and / or manage the different components described in the configuration files.

[0080] In some examples, the infrastructure can have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., a potential on-demand pool of configurable and / or shared computing resources), also referred to as a core network. In some examples, one or more inbound / outbound service group rules may also be provided to define how the inbound / outbound services of the network and one or more virtual machines (VMs) will be set up. Other infrastructure elements, such as load balancers, databases, etc., may also be provided. The infrastructure may evolve gradually as more and more infrastructure elements are desired and / or added.

[0081] In some cases, continuous deployment techniques can be employed to enable infrastructure code to be deployed across various virtual computing environments. In addition, the described techniques can enable infrastructure management within these environments. In some examples, a service team can write code that is expected to be deployed to one or more but typically many different production environments (e.g., across various different geographic locations, sometimes across the world). However, in some examples, the infrastructure on which the code will be deployed needs to be set up first. In some cases, provisioning can be done manually, resources can be provisioned using provisioning tools, and / or code can be deployed using deployment tools once the infrastructure is provisioned.

[0082] Figure 6 6 is a block diagram 600 illustrating an example mode of an IaaS architecture according to at least one embodiment. A service operator 602 can be communicatively coupled to a secure host lease 604 that can include a virtual cloud network (VCN) 606 and a secure host subnet 608. In some examples, the service operator 602 can use one or more client computing devices (the client computing device can be a portable handheld device (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display), running software (such as Microsoft Windows ) and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc.), and supports Internet, email, short message service (SMS), Alternatively, the client computing device may be a general-purpose personal computer, including, for example, a computer running various versions of Microsoft Apple The client computing device may be a personal computer and / or laptop computer running various commercially available or any workstation computer running any operating system such as UNIX or UNIX-like operating systems, including but not limited to various GNU / Linux operating systems (such as, for example, Google Chrome OS). Alternatively or additionally, the client computing device may be any other electronic device, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without gesture input device), and / or a personal messaging device capable of communicating over a network that can access VCN 606 and / or the Internet.

[0083] VCN 606 may include a local peer gateway (LPG) 610, which may be communicatively coupled to a secure shell (SSH) VCN 612 via the LPG 610 contained in an SSH VCN 612. SSH VCN 612 may include an SSH subnet 614, and SSH VCN 612 may be communicatively coupled to a control plane VCN 616 via the LPG 610 contained in a control plane VCN 616. In addition, SSH VCN 612 may be communicatively coupled to a data plane VCN 618 via the LPG 610. The control plane VCN 616 and the data plane VCN 618 may be contained in a service lease 619, which may be owned and / or operated by an IaaS provider.

[0084] The control plane VCN 616 may include a control plane demilitarized zone (DMZ) layer 620 that acts as a perimeter network (e.g., a portion of a company network between a company's internal network and an external network). DMZ-based servers can assume limited liability and help control violations. In addition, the DMZ layer 620 may include one or more load balancer (LB) subnets 622, a control plane application layer 624 that may include (one or more) application (app) subnets 626, and a control plane data layer 628 that may include (one or more) database (DB) subnets 630 (e.g., (one or more) front-end DB subnets and / or (one or more) back-end DB subnets). The LB subnet(s) 622 included in the control plane DMZ layer 620 may be communicatively coupled to the application subnet(s) 626 included in the control plane application layer 624 and the Internet gateway 634 that may be included in the control plane VCN 616, and the application subnet(s) 626 may be communicatively coupled to the DB subnet(s) 630 included in the control plane data layer 628 as well as the service gateway 636 and the network address translation (NAT) gateway 638. The control plane VCN 616 may include the service gateway 636 and the NAT gateway 638.

[0085] The control plane VCN 616 may include a data plane mirror application layer 640, which may include application subnet(s) 626. The application subnet(s) 626 included in the data plane mirror application layer 640 may include a virtual network interface controller (VNIC) 642 that may execute a compute instance 644. The compute instance 644 may communicatively couple the application subnet(s) 626 of the data plane mirror application layer 640 to the application subnet(s) 626 that may be included in the data plane application layer 646.

[0086] The data plane VCN 618 may include a data plane application layer 646, a data plane DMZ layer 648, and a data plane data layer 650. The data plane DMZ layer 648 may include (one or more) LB subnets 622, which may be communicatively coupled to the (one or more) application subnets 626 of the data plane application layer 646 and the Internet gateway 634 of the data plane VCN 618. The (one or more) application subnets 626 may be communicatively coupled to the service gateway 636 of the data plane VCN 618 and the NAT gateway 638 of the data plane VCN 618. The data plane data layer 650 may also include (one or more) DB subnets 630, which may be communicatively coupled to the (one or more) application subnets 626 of the data plane application layer 646.

[0087] The internet gateway 634 of the control plane VCN 616 and the data plane VCN 618 may be communicatively coupled to a metadata management service 652, which may be communicatively coupled to a public Internet 654. The public Internet 654 may be communicatively coupled to a NAT gateway 638 of the control plane VCN 616 and the data plane VCN 618. The service gateway 636 of the control plane VCN 616 and the data plane VCN 618 may be communicatively coupled to a cloud service 656.

[0088] In some examples, service gateway 636 of control plane VCN 616 or data plane VCN 618 can make application programming interface (API) calls to cloud services 656 without going through public internet 654. API calls from service gateway 636 to cloud services 656 can be one-way: service gateway 636 can make API calls to cloud services 656, and cloud services 656 can send requested data to service gateway 636. However, cloud services 656 may not initiate API calls to service gateway 636.

[0089] In some examples, secure host lease 604 can be directly connected to service lease 619, which can otherwise be isolated. Secure host subnet 608 can communicate with SSH subnet 614 through LPG 610, which can enable two-way communication on otherwise isolated systems. Connecting secure host subnet 608 to SSH subnet 614 can enable secure host subnet 608 to access other entities within service lease 619.

[0090] The control plane VCN 616 may allow a user of the service lease 619 to set up or otherwise provision desired resources. The desired resources provisioned in the control plane VCN 616 may be deployed or otherwise used in the data plane VCN 618. In some examples, the control plane VCN 616 may be isolated from the data plane VCN 618, and the data plane mirror application layer 640 of the control plane VCN 616 may communicate with the data plane application layer 646 of the data plane VCN 618 via the VNIC 642, which may be included in the data plane mirror application layer 640 and the data plane application layer 646.

[0091] In some examples, a user or customer of the system may make a request, such as a create, read, update, or delete (CRUD) operation, through the public internet 654 which may transmit the request to the metadata management service 652. The metadata management service 652 may transmit the request to the control plane VCN 616 through the internet gateway 634. The request may be received by the LB subnet(s) 622 contained in the control plane DMZ layer 620. The LB subnet(s) 622 may determine that the request is valid, and in response to the determination, the LB subnet(s) 622 may transmit the request to the application subnet(s) 626 contained in the control plane application layer 624. If the request is validated and a call to the public internet 654 is required, the call to the public internet 654 may be transmitted to the NAT gateway 638 which may make the call to the public internet 654. The storage that the request may desire to be stored may be stored in the DB subnet(s) 630.

[0092] In some examples, data plane mirror application layer 640 may facilitate direct communications between control plane VCN 616 and data plane VCN 618. For example, it may be desirable to apply changes, updates, or other appropriate modifications to the configuration of resources contained in data plane VCN 618. Control plane VCN 616, via VNIC 642, may communicate directly with the resources contained in data plane VCN 618 and may thereby perform changes, updates, or other appropriate modifications to the configuration of these resources.

[0093] In some embodiments, control plane VCN 616 and data plane VCN 618 may be included in service lease 619. In this case, a user or customer of the system may not own or operate control plane VCN 616 or data plane VCN 618. Alternatively, an IaaS provider may own or operate control plane VCN 616 and data plane VCN 618, both of which may be included in service lease 619. This embodiment may enable isolation of networks that may prevent a user or customer from interacting with the resources of other users or other customers. In addition, this embodiment may allow a user or customer of the system to store databases privately without relying on the public Internet 654, which may not have the desired level of threat protection, for storage.

[0094] In other embodiments, the LB subnet(s) 622 contained in the control plane VCN 616 can be configured to receive signals from the service gateway 636. In this embodiment, the control plane VCN 616 and the data plane VCN 618 can be configured to be called by customers of the IaaS provider without calling the public Internet 654. Customers of the IaaS provider may desire this embodiment because the database(s) used by the customer can be controlled by the IaaS provider and can be stored on the service lease 619, which may be isolated from the public Internet 654.

[0095] Figure 7 700 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 702 (e.g., Figure 6 The service operator 602) can be communicatively coupled to the secure host lease 704 (e.g., Figure 6 The secure host lease 604 may include a virtual cloud network (VCN) 706 (e.g., Figure 6 VCN 606) and secure host subnet 708 (e.g., Figure 6 The VCN 706 may include a local peer gateway (LPG) 710 (e.g., Figure 6 LPG 610), the VCN 706 may be connected to the VCN 712 (e.g., Figure 6 LPG 610 in SSH VCN 612 of the present invention is communicatively coupled to SSH VCN 712. SSH VCN 712 may include SSH subnet 714 (e.g., Figure 6 SSH subnet 614), and SSH VCN 712 can be accessed via control plane VCN 716 (e.g., Figure 6The LPG 710 in the control plane VCN 616 of the embodiment of the present invention is communicatively coupled to the control plane VCN 716. The control plane VCN 716 can be included in the service lease 719 (e.g., Figure 6 service lease 619), and the data plane VCN 718 (e.g., Figure 6 The data plane VCN 618) may be contained in a customer lease 721 which may be owned or operated by a user or customer of the system.

[0096] The control plane VCN 716 may include a control plane DMZ layer 720 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) LB subnets 722 (e.g., Figure 6 (one or more) LB subnets 622), may include (one or more) application subnets 726 (e.g., Figure 6 (one or more) application subnets 626) of the control plane application layer 724 (e.g., Figure 6 The control plane application layer 624 of FIG. 1 may include (one or more) database (DB) subnets 730 (e.g., similar to Figure 6 (one or more) DB subnet 630) of the control plane data layer 728 (e.g., Figure 6 The LB subnet(s) 722 contained in the control plane DMZ layer 720 may be communicatively coupled to the application subnet(s) 726 contained in the control plane application layer 724 and the internet gateway 734 (e.g., Figure 6 634), and the application subnet(s) 726 may be communicatively coupled to the DB subnet(s) 730 and the service gateway 736 (e.g., Figure 6 ) and a network address translation (NAT) gateway 738 (e.g., Figure 6 The control plane VCN 716 may include a service gateway 736 and a NAT gateway 738.

[0097] The control plane VCN 716 may include a data plane mirror application layer 740 (e.g., Figure 6 The data plane image application layer 640). The application subnet(s) 726 included in the data plane image application layer 740 may include a computing instance 744 (e.g., similar to Figure 6The compute instance 744 may facilitate the application subnet(s) 726 of the data plane mirroring application layer 740 and the application subnets 726 that may be included in the data plane application layer 746 (e.g., Figure 6 Communication between (one or more) application subnets 726 in the data plane application layer 646) via the VNIC 742 contained in the data plane mirror application layer 740 and the VNIC 742 contained in the data plane application layer 746.

[0098] The Internet gateway 734 included in the control plane VCN 716 can be communicatively coupled to the metadata management service 752 (e.g., Figure 6 , which can be communicatively coupled to a public Internet 754 (e.g., Figure 6 The public Internet 754 can be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716. The service gateway 736 included in the control plane VCN 716 can be communicatively coupled to cloud services 756 (e.g., Figure 6 Cloud service 656).

[0099] In some examples, the data plane VCN 718 may be contained in a customer lease 721. In this case, the IaaS provider may provide a control plane VCN 716 for each customer, and the IaaS provider may provision each customer with a unique compute instance 744 contained in a service lease 719. Each compute instance 744 may allow communication between a control plane VCN 716 contained in a service lease 719 and a data plane VCN 718 contained in a customer lease 721. The compute instance 744 may allow resources provisioned in a control plane VCN 716 contained in a service lease 719 to be deployed or otherwise used in a data plane VCN 718 contained in a customer lease 721.

[0100] In other examples, a customer of the IaaS provider may have a database that exists in the customer tenancy 721. In this example, the control plane VCN 716 may include a data plane mirror application layer 740, which may include (one or more) application subnets 726. The data plane mirror application layer 740 may reside in the data plane VCN 718, but the data plane mirror application layer 740 may not exist in the data plane VCN 718. In other words, the data plane mirror application layer 740 may access the customer tenancy 721, but the data plane mirror application layer 740 may not exist in the data plane VCN 718 or be owned or operated by the customer of the IaaS provider. The data plane mirror application layer 740 may be configured to make calls to the data plane VCN 718, but may not be configured to make calls to any entity contained in the control plane VCN 716. A customer may desire to deploy or otherwise use resources provisioned in control plane VCN 716 in data plane VCN 718, and data plane mirror application layer 740 may facilitate the customer's desired deployment or other use of resources.

[0101] In some embodiments, a customer of an IaaS provider may apply filters to the data plane VCN 718. In this embodiment, the customer may determine what the data plane VCN 718 may access, and the customer may restrict access to the public Internet 754 from the data plane VCN 718. The IaaS provider may not apply filters or otherwise control access to any external network or database by the data plane VCN 718. The customer applying filters and controls to the data plane VCN 718 contained in the customer lease 721 may help isolate the data plane VCN 718 from other customers and the public Internet 754.

[0102] In some embodiments, cloud services 756 may be called by service gateway 736 to access services that may not exist on public Internet 754, control plane VCN 716, or data plane VCN 718. The connection between cloud services 756 and control plane VCN 716 or data plane VCN 718 may not be real-time or continuous. Cloud services 756 may exist on different networks owned or operated by IaaS providers. Cloud services 756 may be configured to receive calls from service gateway 736 and may be configured not to receive calls from public Internet 754. Some cloud services 756 may be isolated from other cloud services 756, and control plane VCN 716 may be isolated from cloud services 756 that may not be in the same region as control plane VCN 716. For example, control plane VCN 716 may be located in "Region 1", and cloud service "Deployment 6" may be located in Region 1 and "Region 2". If a service gateway 736 contained in a control plane VCN 716 located in region 1 makes a call to deployment 6, the call may be transmitted to deployment 6 in region 1. In this example, control plane VCN 716 or deployment 6 in region 1 may not be communicatively coupled or otherwise in communication with deployment 6 in region 2.

[0103] Figure 8 8 is a block diagram 800 illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 802 (e.g., Figure 6 The service operator 602) can be communicatively coupled to the secure host lease 804 (e.g., Figure 6 The secure host lease 804 may include a virtual cloud network (VCN) 806 (e.g., Figure 6 VCN 606) and secure host subnet 808 (e.g., Figure 6 VCN 806 may include LPG 810 (e.g., Figure 6 The LPG 610 of the VCN 806 can be connected to the VCN 806 via the SSH VCN 812 (e.g., Figure 6 The LPG 810 in the SSH VCN 612 of FIG. 810 is communicatively coupled to the SSH VCN 812. The SSH VCN 812 may include an SSH subnet 814 (e.g., Figure 6 SSH subnet 614), and SSH VCN 812 can be accessed via control plane VCN 816 (e.g., Figure 6 LPG 810 in a control plane VCN 616 of the embodiment of the present invention is communicatively coupled to the control plane VCN 816 and is communicated via a data plane VCN 818 (e.g., Figure 6The control plane VCN 816 and the data plane VCN 818 may be included in a service lease 819 (e.g., Figure 6 of service leasing 619).

[0104] The control plane VCN 816 may include a load balancer (LB) subnet 822 (e.g., Figure 6 The control plane DMZ layer 820 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) application subnets 826 (e.g., similar to Figure 6 (one or more) application subnets 626) of the control plane application layer 824 (e.g., Figure 6 The control plane application layer 624 of the embodiment of the present invention may include a control plane data layer 828 (e.g., Figure 6 The LB subnet(s) 822 contained in the control plane DMZ layer 820 may be communicatively coupled to the application subnet(s) 826 contained in the control plane application layer 824 and the internet gateway 834 (e.g., Figure 6 824), and the application subnet(s) 826 may be communicatively coupled to the DB subnet(s) 830 and the service gateway 836 (e.g., Figure 6 ) and a network address translation (NAT) gateway 838 (e.g., Figure 6 The control plane VCN 816 may include a service gateway 836 and a NAT gateway 838.

[0105] The data plane VCN 818 may include a data plane application layer 846 (e.g., Figure 6 Data plane application layer 646), data plane DMZ layer 848 (e.g., Figure 6 Data plane DMZ layer 648), and data plane data layer 850 (e.g., Figure 6The data plane DMZ layer 848 may include the trusted application subnet(s) 860 and the untrusted application subnet(s) 862 that may be communicatively coupled to the data plane application layer 846 and the LB subnet(s) 822 of the Internet gateway 834 included in the data plane VCN 818. The trusted application subnet(s) 860 may be communicatively coupled to the service gateway 836 included in the data plane VCN 818, the NAT gateway 838 included in the data plane VCN 818, and the DB subnet(s) 830 included in the data plane data layer 850. The untrusted application subnet(s) 862 may be communicatively coupled to the service gateway 836 included in the data plane VCN 818 and the DB subnet(s) 830 included in the data plane data layer 850. The data plane data layer 850 may include the DB subnet(s) 830 that may be communicatively coupled to the service gateway 836 included in the data plane VCN 818.

[0106] The untrusted application subnet(s) 862 may include one or more primary VNICs 864(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 866(1)-(N). Each tenant VM 866(1)-(N) may be communicatively coupled to a respective application subnet 867(1)-(N) that may be contained in a respective container egress VCN 868(1)-(N), which may be contained in a respective customer tenancy 870(1)-(N). A respective secondary VNIC 872(1)-(N) may facilitate communications between the untrusted application subnet(s) 862 contained in the data plane VCN 818 and the application subnets contained in the container egress VCN 868(1)-(N). Each container egress VCN 868(1)-(N) may include a NAT gateway 838 that may be communicatively coupled to the public Internet 854 (e.g., Figure 6 of the public Internet 654).

[0107] The Internet gateway 834 included in the control plane VCN 816 and included in the data plane VCN 818 can be communicatively coupled to the metadata management service 852 (e.g., Figure 6The metadata management service 852 may be communicatively coupled to the public Internet 854. The public Internet 854 may be communicatively coupled to a NAT gateway 838 included in the control plane VCN 816 and included in the data plane VCN 818. The service gateway 836 included in the control plane VCN 816 and included in the data plane VCN 818 may be communicatively coupled to the cloud service 856.

[0108] In some embodiments, the data plane VCN 818 can be integrated with the customer lease 870. In some cases, such integration may be useful or desirable for the customers of the IaaS provider, such as where support may be desired when executing code. A customer may provide code to run that may be destructive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response to this, the IaaS provider may determine whether to run the code given to the IaaS provider by the customer.

[0109] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider and request functionality attached to a data plane layer application 846. Code running the functionality may be executed in a VM 866(1)-(N), and the code may not be configured to run anywhere else on the data plane VCN 818. Each VM 866(1)-(N) may be connected to a customer lease 870. The corresponding container 871(1)-(N) contained in the VM 866(1)-(N) may be configured to run the code. In this case, there may be double isolation (e.g., the container 871(1)-(N) runs code, where the container 871(1)-(N) may be contained at least in the VM 866(1)-(N) contained in the (one or more) untrusted application subnets 862), which can help prevent incorrect or otherwise undesirable code from damaging the IaaS provider's network or damaging the network of a different customer. Containers 871(1)-(N) may be communicatively coupled to customer lease 870 and may be configured to transmit or receive data from customer lease 870. Containers 871(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 818. After running the code is complete, the IaaS provider may terminate or otherwise dispose of containers 871(1)-(N).

[0110] In some embodiments, the trusted application subnet(s) 860 may run code that may be owned or operated by the IaaS provider. In this embodiment, the trusted application subnet(s) 860 may be communicatively coupled to the DB subnet(s) 830 and configured to perform CRUD operations in the DB subnet(s) 830. The untrusted application subnet(s) 862 may be communicatively coupled to the DB subnet(s) 830, but in this embodiment, the untrusted application subnet(s) may be configured to perform read operations in the DB subnet(s) 830. The containers 871(s) (1)-(N) that may be included in each customer's VM 866(1)-(N) and that may run code from the customer may not be communicatively coupled to the DB subnet(s) 830.

[0111] In other embodiments, the control plane VCN 816 and the data plane VCN 818 may not be directly communicatively coupled. In this embodiment, there may be no direct communication between the control plane VCN 816 and the data plane VCN 818. However, communication may occur indirectly through at least one method. The LPG 810 may be established by an IaaS provider, which may facilitate communication between the control plane VCN 816 and the data plane VCN 818. In another example, the control plane VCN 816 or the data plane VCN 818 may make a call to the cloud service 856 via the service gateway 836. For example, the call from the control plane VCN 816 to the cloud service 856 may include a request for a service that can communicate with the data plane VCN 818.

[0112] Fig. 9 900 is a block diagram illustrating another example model of an IaaS architecture according to at least one embodiment. A service operator 902 (e.g., Figure 6 The service operator 602) can be communicatively coupled to the secure host lease 904 (e.g., Figure 6 The secure host lease 904 may include a virtual cloud network (VCN) 906 (e.g., Figure 6 VCN 606) and secure host subnet 908 (e.g., Figure 6 VCN 906 may include LPG 910 (e.g., Figure 6 The LPG 610 of the VCN 906 can be connected to the VCN 906 via the SSH VCN 912 (e.g., Figure 6 LPG 910 in SSH VCN 612 of the present invention is communicatively coupled to SSH VCN 912. SSH VCN 912 may include SSH subnet 914 (e.g., Figure 6SSH subnet 614), and SSH VCN 912 can be accessed via control plane VCN 916 (e.g., Figure 6 The LPG 910 in the control plane VCN 616 of the embodiment of the present invention is communicatively coupled to the control plane VCN 916 and is communicated via a data plane VCN 918 (e.g., Figure 6 The control plane VCN 916 and the data plane VCN 918 may be included in a service lease 919 (e.g., Figure 6 of service leasing 619).

[0113] The control plane VCN 916 may include (one or more) LB subnets 922 (e.g., Figure 6 The control plane DMZ layer 920 (e.g., Figure 6 The control plane DMZ layer 620 may include (one or more) application subnets 926 (e.g., Figure 6 (one or more) application subnets 626) of the control plane application layer 924 (e.g., Figure 6 The control plane application layer 624 of FIG. 1 may include (one or more) DB subnets 930 (e.g., Figure 8 (one or more) DB subnets 830) of the control plane data layer 928 (e.g., Figure 6 The LB subnet(s) 922 contained in the control plane DMZ layer 920 may be communicatively coupled to the application subnet(s) 926 contained in the control plane application layer 924 and the internet gateway 934 (e.g., Figure 6 634), and the application subnet(s) 926 may be communicatively coupled to the DB subnet(s) 930 and the service gateway 936 (e.g., Figure 6 Serving gateway) and network address translation (NAT) gateway 938 (e.g., Figure 6 The control plane VCN 916 may include a service gateway 936 and a NAT gateway 938.

[0114] The data plane VCN 918 may include a data plane application layer 946 (e.g., Figure 6 Data plane application layer 646), data plane DMZ layer 948 (e.g., Figure 6 Data plane DMZ layer 648)), and data plane data layer 950 (e.g., Figure 6The data plane DMZ layer 948 may include (one or more) trusted application subnets 960 (e.g., Figure 8 (one or more) trusted application subnets 860) and (one or more) untrusted application subnets 962 (e.g., Figure 8 The trusted application subnet(s) 960 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918, the NAT gateway 938 contained in the data plane VCN 918, and the DB subnet(s) 930 contained in the data plane data layer 950. The untrusted application subnet(s) 962 may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918 and the DB subnet(s) 930 contained in the data plane data layer 950. The data plane data layer 950 may include the DB subnet(s) 930 that may be communicatively coupled to the service gateway 936 contained in the data plane VCN 918.

[0115] Untrusted application subnet(s) 962 may include primary VNICs 964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N) residing within untrusted application subnet(s) 962. Each tenant VM 966(1)-(N) may run code in a respective container 967(1)-(N) and may be communicatively coupled to application subnet 926 that may be contained in a data plane application layer 946 that may be contained in a container egress VCN 968. Corresponding secondary VNICs 972(1)-(N) may facilitate communications between untrusted application subnet(s) 962 contained in a data plane VCN 918 and application subnets contained in a container egress VCN 968. The container egress VCN may include a primary VNIC 964(1)-(N) that may be communicatively coupled to a public Internet 954 (e.g., Figure 6 NAT gateway 938 of the public Internet 654).

[0116] The Internet gateway 934 included in the control plane VCN 916 and included in the data plane VCN 918 can be communicatively coupled to the metadata management service 952 (e.g., Figure 6The metadata management service 952 may be communicatively coupled to the public Internet 954. The public Internet 954 may be communicatively coupled to a NAT gateway 938 included in the control plane VCN 916 and included in the data plane VCN 918. The service gateway 936 included in the control plane VCN 916 and included in the data plane VCN 918 may be communicatively coupled to the cloud service 956.

[0117] In some examples, Fig. 9 The architecture model shown in block diagram 900 can be considered as Figure 8 800, and may be desirable to customers of the IaaS provider in situations where the IaaS provider cannot communicate directly with customers (e.g., disconnected regions). Customers may access each customer's respective container 967(1)-(N) contained in a VM 966(1)-(N) in real time. Containers 967(1)-(N) may be configured to make calls to respective secondary VNICs 972(1)-(N) contained in application subnet(s) 926 of a data plane application layer 946, which may be contained in a container egress VCN 968. Secondary VNICs 972(1)-(N) may transmit the calls to a NAT gateway 938, which may transmit the calls to the public Internet 954. In this example, the containers 967(1)-(N) that may be accessed by customers in real time may be isolated from the control plane VCN 916 and may be isolated from other entities contained in the data plane VCN 918. Containers 967(1)-(N) may also be isolated from resources of other clients.

[0118] In other examples, a customer may use containers 967(1)-(N) to call cloud service 956. In this example, a customer may run code in container 967(1)-(N) to request a service from cloud service 956. Container 967(1)-(N) may transmit the request to secondary VNIC 972(1)-(N), which may transmit the request to a NAT gateway, which may transmit the request to public Internet 954. Public Internet 954 may transmit the request to LB subnet(s) 922 contained in control plane VCN 916 via Internet gateway 934. In response to determining that the request is valid, LB subnet(s) may transmit the request to application subnet(s) 926, which may transmit the request to cloud service 956 via service gateway 936.

[0119] It should be appreciated that the IaaS architectures 600, 700, 800, 900 depicted in the various figures may have other components in addition to the components depicted. In addition, the embodiments shown in the various figures are merely some examples of cloud infrastructure systems that may be combined with embodiments of the present disclosure. In some other embodiments, the IaaS system may have more or fewer components than shown in the various figures, may combine two or more components, or may have a different arrangement or configuration of components.

[0120] In some embodiments, the IaaS system described herein may include application suites, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such an IaaS system is the Oracle Cloud Infrastructure (OCI) provided by the present assignee.

[0121] Fig.10 An example computer system 1000 is illustrated in which various embodiments of the present disclosure may be implemented. System 1000 may be used to implement any of the computer systems described above. As shown, computer system 1000 includes a processing unit 1004 that communicates with multiple peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing acceleration unit 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. Storage subsystem 1018 includes a tangible computer-readable storage medium 1022 and a system memory 1010.

[0122] The bus subsystem 1002 provides a mechanism for allowing the various components and subsystems of the computer system 1000 to communicate with each other by intention. Although the bus subsystem 1002 is schematically shown as a single bus, an alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 1002 can be any of several types of bus structures, including a memory bus or a memory controller, a peripheral bus, and a local bus using any various bus architectures. For example, this architecture can include an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured by the IEEE P1386.1 standard.

[0123] The processing unit 1004, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 1000. One or more processors may be included in the processing unit 1004. These processors may include single-core or multi-core processors. In certain embodiments, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034, wherein a single-core or multi-core processor is included in each processing unit. In other embodiments, the processing unit 1004 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0124] In various embodiments, the processing unit 1004 can execute various programs in response to the program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 1004 and / or in the storage subsystem 1018. Through appropriate programming, (one or more) processors 1004 can provide the various functions described above. The computer system 1000 may additionally include a processing acceleration unit 1006, which may include a digital signal processor (DSP), a special processor, and the like.

[0125] I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include keyboards, pointing devices such as a mouse or trackball, touch pads or touch screens incorporated into displays, scroll wheels, click wheels, dials, buttons, switches, keyboards, audio input devices with voice command recognition systems, microphones, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices such as Microsoft Motion sensors that enable users to control devices such as 360 game controller. The user interface input device may also include an eye gesture recognition device, such as detecting eye activity from the user (e.g., a "wink" when taking a picture and / or making a menu selection) and translating the eye gesture to an input device (e.g., Google ) In addition, the user interface input device may include a user interface that enables the user to communicate with the voice recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0126] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game panel and a drawing board, and audio / video equipment, such as a speaker, a digital camera, a digital camcorder, a portable media player, a webcam, an image scanner, a fingerprint scanner, a barcode reader 3D scanner, a 3D printer, a laser rangefinder, and a sight tracking device. In addition, the user interface input device may include, for example, a medical imaging input device, such as computer tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound equipment. The user interface input device may also include, for example, an audio input device, such as a MIDI keyboard, a digital musical instrument, etc.

[0127] The user interface output device may include a display subsystem, indicator lights, or a non-visual display such as an audio output device, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD) or a plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 1000 to a user or other computers. For example, the user interface output device may include, but is not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0128] Computer system 1000 may include storage subsystem 1018, which includes software elements, shown presently located within system memory 1010. System memory 1010 may store program instructions that may be loaded and executed on processing unit 1004, as well as data generated during execution of these programs.

[0129] Depending on the configuration and type of computer system 1000, system memory 1010 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated and executed by processing unit 1004. In some embodiments, system memory 1010 may include a variety of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some embodiments, a basic input / output system (BIOS), which contains basic routines that help transfer information between elements within computer system 1000 (such as during startup), may typically be stored in ROM. By way of example and not limitation, system memory 1010 also illustrates application programs 1012, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 1014, and operating system 1016. For example, operating system 1016 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or mobile operating systems (such as iOS, Phone, OS, 10OS and OS operating system).

[0130] The storage subsystem 1018 may also provide a tangible computer-readable storage medium for storing basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the above-described functionality when executed by a processor may be stored in the storage subsystem 1018. These software modules or instructions may be executed by the processing unit 1004. The storage subsystem 1018 may also provide a repository for storing data used in accordance with the present disclosure.

[0131] The storage subsystem 1000 may also include a computer-readable storage media reader 1020 that may also be connected to a computer-readable storage medium 1022. Together with and optionally in conjunction with the system memory 1010, the computer-readable storage medium 1022 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transferring, and retrieving computer-readable information.

[0132] The computer-readable storage medium 1022 containing the code or portions of the code may also include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information. This may include tangible computer-readable storage media, such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or other tangible computer-readable medium. This may also include non-tangible computer-readable media, such as data signals, data transmissions, or any other medium that can be used to transmit the desired information and can be accessed by the computing system 1000.

[0133] By way of example, computer-readable storage media 1022 may include a hard drive that reads from or writes to non-removable nonvolatile magnetic media, a magnetic disk drive that reads from or writes to removable nonvolatile magnetic disks, and a magnetic disk drive that reads from or writes to removable nonvolatile optical disks such as CD ROMs, DVDs, and optical drives. Computer readable storage media 1022 may include, but are not limited to: The computer readable storage medium 1022 may include a solid-state drive (SSD) based on non-volatile memory (such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, etc.), a volatile memory-based SSD (such as a solid-state RAM, dynamic RAM, static RAM, DRAM-based SSD), a magnetoresistive RAM (MRAM) SSD, and a hybrid SSD using a combination of a DRAM-based SSD and a flash memory-based SSD. The disk drive and its associated computer-readable medium may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 1000.

[0134] The communication subsystem 1024 provides an interface to other computer systems and networks. The communication subsystem 1024 is used as an interface for receiving data from other systems and transmitting data from the computer system 1000 to other systems. For example, the communication subsystem 1024 can enable the computer system 1000 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 1024 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular phone technology, advanced data network technology such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof), a global positioning system (GPS) receiver component and / or other components. In some embodiments, the communication subsystem 1024 may provide a wired network connection (e.g., Ethernet) as an addition or replacement of a wireless interface.

[0135] In some embodiments, the communication subsystem 1024 may also receive incoming communications in the form of structured and / or unstructured data feeds 1026 , event streams 1028 , event updates 1030 , and the like on behalf of one or more users who may use the computer system 1000 .

[0136] For example, the communication subsystem 1024 may be configured to receive data feeds 1026 in real time from users of social networks and / or other communication services, such as feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0137] Additionally, the communication subsystem 1024 may also be configured to receive data in the form of a continuous data stream, which may include event streams 1028 and / or event updates 1030, which may be continuous or unbounded in nature, real-time events without explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0138] The communication subsystem 1024 can also be configured to output structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, etc. to one or more databases, which can communicate with one or more streaming data source computers coupled to the computer system 1000.

[0139] Computer system 1000 may be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted display), PC, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0140] Due to the ever-changing nature of computers and networks, the description of the computer system 1000 depicted in the figure is intended only as a specific example. Many other configurations with more or fewer components than the system depicted in the figure are possible. For example, customized hardware may also be used and / or specific elements may be implemented with hardware, firmware, software (including applets) or a combination thereof. In addition, connections to other computing devices such as network input / output devices may also be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0141] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are also included within the scope of this disclosure. Embodiments are not limited to operating within certain specific data processing environments, but can be freely operated within multiple data processing environments. In addition, although embodiments have been described using a specific series of transactions and steps, it should be clear to those skilled in the art that the scope of this disclosure is not limited to the described series of transactions and steps. The various features and aspects of the above-described embodiments may be used alone or in combination.

[0142] In addition, although embodiments have been described using a specific combination of hardware and software, it should be appreciated that other combinations of hardware and software are also within the scope of the present disclosure. Embodiments may be implemented using only hardware, or only software, or using a combination thereof. The various processes described herein may be implemented in any combination on the same processor or on different processors. Thus, where a component or module is described as being configured to perform certain operations, such configuration may be accomplished by, for example, designing an electronic circuit to perform the operation, by programming a programmable electronic circuit (such as a microprocessor) to perform the operation, or by any combination thereof. Processing may communicate using a variety of techniques, including but not limited to conventional techniques for interprocess communication, and different process pairs may use different techniques, or the same process pair may use different techniques at different times.

[0143] The description and drawings are therefore to be regarded in an illustrative rather than a restrictive sense. However, additions, subtractions, deletions and other modifications and changes may be made without departing from the broader spirit and scope set forth in the claims. Therefore, while specific disclosed embodiments have been described, these are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0144] The use of the terms "one" and "an" and "the" and similar references in the context of describing the disclosed embodiments (especially in the context of the following claims) should be interpreted as covering both the singular and the plural, unless otherwise indicated herein or clearly contradictory to the context. Unless otherwise stated, the terms "include", "have", "include" and "contain" should be interpreted as open terms (i.e., meaning "including but not limited to"). The term "connection" should be interpreted as being partially or entirely included, attached to or connected together, even if there is something in the middle. Unless otherwise indicated herein, the description of the value range in this article is only intended to be used as a shorthand method for individually quoting each individual value falling within the range, and each individual value is incorporated into the specification as if it is described separately in this article. Unless otherwise indicated herein or clearly contradictory to the context, all methods described herein can be performed in any suitable order. Unless otherwise stated, the use of any and all examples or exemplary language (e.g., "such as") provided herein is only intended to better illustrate the embodiment and is not intended to limit the scope of the present disclosure. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0145] Unless expressly stated otherwise, disjunctive language (such as the phrase "at least one of X, Y, or Z") is intended to be understood in context as serving generally to indicate that an item, term, etc. may be any one of X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that certain embodiments require that at least one of X, at least one of Y, or at least one of Z each be present.

[0146] Preferred embodiments of the present disclosure are described herein, including the best mode known for implementing the present disclosure. Variations of these preferred embodiments will become apparent to those of ordinary skill in the art after reading the foregoing description. Those of ordinary skill should be able to appropriately adopt such variations and may practice the present disclosure in a manner different from that specifically described herein. Thus, the present disclosure includes all modifications and equivalent forms of the subject matter recorded in the appended claims where permitted by applicable law. In addition, unless otherwise indicated herein, the present disclosure includes any combination of the above-mentioned elements in all possible variations thereof.

[0147] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference was individually and specifically indicated to be incorporated by reference and was set forth in its entirety herein.

[0148] In the foregoing description, various aspects of the present disclosure are described with reference to their specific embodiments, but those skilled in the art will appreciate that the present disclosure is not limited thereto. Each feature and aspect disclosed above can be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiment can be used in any number of environments and applications other than the environment and application described herein. Thus, this specification and the accompanying drawings should be considered illustrative rather than restrictive.

[0149] Additionally, the embodiments may be implemented using a computer program product that includes a computer program / instructions that, when executed by a processor, cause the processor to perform any of the methods / techniques described in this disclosure.

Claims

1. A method for performing edge attestation at an edge node of a cloud infrastructure environment, the method comprising: receiving, at an edge node of a cloud infrastructure environment, a first request from a console associated with the cloud infrastructure environment, wherein the first request includes a first instruction to create a host instance for the host node, wherein the first request includes a set of authentication data for edge attestation processing, The authentication data set includes a first endorsement key and a first state data set, wherein the first state data set indicates a reference state of the host node; receiving, at the edge node, a second request from the host node, wherein the second request includes a second instruction to connect the host node to the cloud infrastructure environment; The edge certification process is performed at least in part via the edge node, wherein the edge certification process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key; receiving, at the edge node, a second set of status data, wherein the second set of status data indicates a status of the host node; verifying the second state data set by at least comparing the second state data set to the first state data set; and In response to verifying the second endorsement key and the second set of state data, sending, from the edge node to the host node, a network address corresponding to a resource of the cloud infrastructure environment, The host node accesses the resource using the network address.

2. The method of claim 1, wherein the first endorsement key comprises a first public key component of a first public proof identity key; or wherein the second endorsement key comprises a second public key component of a second public proof identity key.

3. The method of claim 1, wherein the edge node is a component of an intelligent network interface controller.

4. The method of claim 1 , wherein verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key comprises: It is determined that at least one value of the second endorsement key matches a corresponding value of the first endorsement key.

5. The method of claim 1, wherein the method further comprises: Prior to receiving a second request from the host node: receiving a pre-boot request for a pre-boot execution environment client from the host node; as well as sending the pre-boot execution environment client to the host node, The host node uses the pre-boot execution environment client to execute a boot process.

6. The method of claim 1, wherein the method further comprises: Install the boot partition to the storage module, Wherein the boot partition is specific to the host node, and wherein the network address corresponds to the boot partition.

7. The method of claim 1, wherein the second request comprises a request for the network address, wherein the second request is sent from the host node in response to the host node connecting to a data center environment, the data center environment comprising one or more computing devices implementing the cloud infrastructure environment.

8. A system for performing edge attestation at an edge node of a cloud infrastructure environment, the system comprising: at least one hardware processor; The system is configured to use the at least one hardware processor to perform operations including: receiving, at an edge node of a cloud infrastructure environment, a first request from a console associated with the cloud infrastructure environment, wherein the first request includes a first instruction to create a host instance for the host node, wherein the first request includes a set of authentication data for edge attestation processing, The authentication data set includes a first endorsement key and a first state data set, wherein the first state data set indicates a reference state of the host node; receiving, at the edge node, a second request from the host node, wherein the second request includes a second instruction to connect the host node to the cloud infrastructure environment; The edge certification process is performed at least in part via the edge node, wherein the edge certification process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key; receiving, at the edge node, a second set of status data, wherein the second set of status data indicates a status of the host node; verifying the second state data set by at least comparing the second state data set to the first state data set; and In response to verifying the second endorsement key and the second set of state data, sending, from the edge node to the host node, a network address corresponding to a resource of the cloud infrastructure environment, The host node accesses the resource using the network address.

9. The system of claim 8, wherein the second endorsement key comprises a public key component of a public attestation identity key.

10. The system of claim 8, wherein verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key comprises: It is determined that at least one value of the second endorsement key matches a corresponding value of the first endorsement key.

11. The system of claim 8, wherein the operations further comprise: Prior to receiving a second request from the host node: receiving a pre-boot request for a pre-boot execution environment client from the host node; as well as sending the pre-boot execution environment client to the host node, The host node uses the pre-boot execution environment client to execute a boot process.

12. The system of claim 8, wherein validating the second state data set by at least comparing the second state data set to the first state data set comprises: identifying a first platform configuration register value included in the first state data set; identifying a second platform configuration register value included in the first state data set; and A determination is made that the first platform configuration register value matches the second platform configuration register value.

13. The system of claim 8, wherein the operations further comprise: Install the boot partition to the storage module, Wherein the boot partition is specific to the host node, and wherein the network address corresponds to the boot partition.

14. The system of claim 8, wherein the second request comprises a request for the network address, wherein the second request is sent from the host node in response to the host node connecting to a data center environment, the data center environment comprising one or more computing devices implementing the cloud infrastructure environment.

15. A non-transitory computer readable medium comprising instructions that, when executed by one or more hardware processors, cause operations to be performed, the operations comprising: receiving, at an edge node of a cloud infrastructure environment, a first request from a console associated with the cloud infrastructure environment, wherein the first request includes a first instruction to create a host instance for the host node, wherein the first request includes a set of authentication data for edge attestation processing, The authentication data set includes a first endorsement key and a first state data set, wherein the first state data set indicates a reference state of the host node; receiving, at the edge node, a second request from the host node, wherein the second request includes a second instruction to connect the host node to the cloud infrastructure environment; The edge certification process is performed at least in part via the edge node, wherein the edge certification process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key; receiving, at the edge node, a second set of status data, wherein the second set of status data indicates a status of the host node; verifying the second state data set by at least comparing the second state data set to the first state data set; and In response to verifying the second endorsement key and the second set of state data, sending, from the edge node to the host node, a network address corresponding to a resource of the cloud infrastructure environment, The host node accesses the resource using the network address.

16. The non-transitory computer-readable medium of claim 15, wherein the second endorsement key comprises a public key component of a public attestation identity key.

17. The non-transitory computer-readable medium of claim 15, wherein verifying the second endorsement key by at least comparing the second endorsement key to the first endorsement key comprises: It is determined that at least one value in the second endorsement key matches a corresponding value in the first endorsement key.

18. The non-transitory computer-readable medium of claim 15, wherein validating the second state data set by at least comparing the second state data set to the first state data set comprises: identifying a first platform configuration register value included in the first state data set; identifying a second platform configuration register value included in the first state data set; and A determination is made that the first platform configuration register value matches the second platform configuration register value.

19. The non-transitory computer readable medium of claim 15, wherein the operations further comprise: Install the boot partition to the storage module, Wherein the boot partition is specific to the host node, and wherein the network address corresponds to the boot partition.

20. The non-transitory computer-readable medium of claim 15, wherein the second request comprises a request for the network address, wherein the second request is sent from the host node in response to the host node connecting to a data center environment, the data center environment comprising one or more computing devices implementing the cloud infrastructure environment.

21. The non-transitory computer readable medium of claim 16, The first endorsement key includes a key generated by a trusted platform module.

22. The non-transitory computer readable medium of claim 21, The first endorsement key identifies the host node.

23. The non-transitory computer readable medium of claim 15, wherein the operations further comprise: Prior to receiving a second request from the host node: receiving a pre-start request from the host node, The pre-start request is used by the edge node to send a first pre-start execution environment client to the host node; as well as sending a first pre-boot execution environment client to the host node, The host node uses a first pre-boot execution environment client to execute a boot process.

24. The non-transitory computer readable medium of claim 23, wherein the second set of state data includes one or more hash register values ​​indicating a state of the host node resulting from executing at least a portion of the boot process.

25. The non-transitory computer-readable medium of claim 23, wherein the second set of state data comprises platform configuration register values, wherein the platform configuration register values ​​comprise a plurality of hash register values, wherein each hash register value of the plurality of hash register values ​​indicates a particular state of the host node during the boot process.

26. The non-transitory computer readable medium of claim 25, wherein each hash register value of the plurality of hash register values ​​indicates a specific service or a specific component initiated by the host node.

27. The non-transitory computer readable medium of claim 23, wherein the operations further comprise: After sending the first pre-boot execution environment client to the host node: executing a second pre-boot execution environment; When the host node uses the first pre-boot execution environment client to perform the boot process, information associated with the second pre-boot execution environment is sent to the host node, The information associated with the second pre-boot execution environment includes operating system information, and the operating system information corresponds to an operating system executed in association with the second pre-boot execution environment.

28. The non-transitory computer readable medium of claim 27, wherein the operating system is installed on a computing device of the cloud infrastructure environment.

29. The non-transitory computer readable medium of claim 27, wherein the edge node is a component of an intelligent network interface controller, and wherein the operating system is installed on the intelligent network interface controller.

30. The non-transitory computer readable medium of claim 27, wherein the information associated with a second pre-boot execution environment allows the host node to perform the boot process without installing the operating system on the host node.

31. The non-transitory computer readable medium of claim 23, wherein the host node generates at least a portion of a second set of state data during the boot process.

32. The non-transitory computer readable medium of claim 15, wherein the edge certification process further comprises: sending a third request from the edge node to the host node, The third request is used by the edge node to provide a second endorsement key. The host node receives the third request, and in response to receiving the third request, the host node generates a second endorsement key and sends the second endorsement key to the edge node.

33. The non-transitory computer readable medium of claim 32, in, The host node generates a key pair, and The second endorsement key is generated by the host node based on the key pair.

34. The non-transitory computer-readable medium of claim 33, wherein the key pair comprises a public proof identity key.

35. The non-transitory computer readable medium of claim 15, wherein the edge certification process further comprises: sending a third request from the edge node to the host node, The third request is used for the edge node to provide a second state data set, The host node receives the third request, and in response to receiving the third request, the host node generates a second state data set and sends the second state data set to the edge node.

36. The non-transitory computer readable medium of claim 35, wherein: A third request is sent from the edge node to the host node in response to verifying the second endorsement key.

Images