Edge attestation for authorization of computing nodes in a cloud infrastructure system

Abstract

The present embodiment relates to edge attestation of a host node to access a cloud infrastructure environment. A set of authentication data may be obtained from a console for authorization of the host node. The set of authentication data may include a first endorsement key and an authentication policy that identifies characteristics of the host node. The host node may transmit a request for a network address to connect to the cloud infrastructure environment. The host node may generate a second endorsement key and authentication data that may be verified as corresponding to the set of authentication data received from the console. In response to verifying the second endorsement key and the received host node authentication data, a network address may be provided to the host node that may be used to connect to the cloud infrastructure environment using the network address.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. patent application Ser. No. 17 / 523,789, filed Nov. 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.

[0002] Field The disclosed technology relates to cloud computing authentication, and more particularly, to utilizing edge components of a cloud computing environment for authentication of host nodes that are new to the cloud computing environment, for example, prior to granting network access to the new host node. [Background technology]

[0003] background In a data center environment, a new component (e.g., a server) may be added as a new host device. The new component may be added to a cloud computing environment to increase computing resources in the cloud environment or to provide additional functionality to applications / services running on the components in the cloud environment. The new component may be physically connected to other devices in the data center environment connecting multiple devices implementing the cloud computing environment. For example, a colocation center may provide a data center environment that houses the components implementing the cloud computing environment.

[0004] However, in many cases, a data center environment (e.g., a colocation center) may house computing devices / data centers for other entities. In such cases, another entity may have access to nearby areas of the data center environment that house components that implement the cloud computing environment. For example, another entity may maliciously connect a device to the data center environment without authorization. Without any verification process, the connected device may gain access to data and / or services that are privately managed within the cloud computing environment. Summary of the Invention [Means for solving the problem]

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

[0006] The method may also include obtaining, from the host node, a request for a network address to connect 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 first endorsement key and the second endorsement key received in the set of authentication data to verify the second endorsement key.

[0007] The method may also include receiving a set of host node authentication data from the host node. The set of host node authentication data may include a second PCR value that includes a hashed register value during a boot procedure of the host node. The method may also include comparing the received host node authentication data with an authentication policy received in the set of authentication data to validate 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.

[0008] 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 a set of authentication data from a console for authorization of the host node. The set of authentication data may include a first endorsement key and an authentication policy that identifies characteristics of the host node. The instructions may further cause the processor to obtain, from the host node, a request for a network address to connect to the cloud infrastructure environment.

[0009] The instructions may further cause the processor to transmit a request for a second endorsement key to the host node. The instructions may further cause the processor to receive the second endorsement key from the host node. The instructions may further cause the processor to compare the first and second endorsement keys received in the set of authentication data to verify the second endorsement key. The instructions may further cause the processor to transmit a request for host node authentication data to the host node. The instructions may further cause the processor to receive the host node authentication data from the host node.

[0010] The instructions may further cause the processor to compare the received host node authentication data with an authentication policy received in the set of authentication data to validate the received host node authentication data. The instructions may further 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.

[0011] 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 that, when executed by a processor, causes the processor to perform a process. The process may include obtaining a set of authentication data from a console for authorization of the host node. The set of authentication data may include a first endorsement key and an authentication policy that identifies characteristics of the host node. The process may also include obtaining a request for a network address from the host node to connect to a cloud infrastructure environment.

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

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

[0014] The process may also further include comparing the received host node authentication data with the authentication policy received in the set of authentication data to validate the received host node authentication data. The process may also include providing a network address to the host node in response to validating 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]

[0015] [Figure 1] FIG. 1 is a block diagram of an example network environment according to at least one embodiment. [Diagram 2] FIG. 1 is a block diagram of an example cloud infrastructure system according to at least one embodiment. [Diagram 3] 1 is a signaling process illustrating an example edge attestation process according to at least one embodiment. [Figure 4] FIG. 1 is a block diagram illustrating an example method implemented by a SmartNIC for performing an edge attestation process, according to at least one embodiment. [Diagram 5] FIG. 1 is a block diagram illustrating an example method implemented by a host node to be verified using an edge attestation process, according to at least one embodiment. [Figure 6] FIG. 1 is a block diagram illustrating one pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 7] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 8] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 9] FIG. 1 is a block diagram illustrating another pattern for implementing a cloud infrastructure as a service system according to at least one embodiment. [Figure 10] FIG. 1 is a block diagram illustrating an example computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0016] Detailed Description In many cases, multiple computing devices (e.g., servers) and applications / services running on the multiple computing devices can implement a cloud computing infrastructure. Additionally, new host nodes can be added to the multiple computing devices to increase computing resources or functionality for the cloud infrastructure. In such cases, the new host nodes can be managed by verifying the identity and security characteristics of the new computing devices. Such verification can be performed by remote attestation, which can include computing devices providing cryptographically verifiable information to verify the identity and configuration of each computing device. Remote attestation procedures can be used, for example, to manage the security of devices in a network and identify the status of computing devices.

[0017] Rather than implementing a centralized service to centrally implement remote attestation within the cloud infrastructure, the validation service may be implemented by an edge node within the cloud infrastructure environment near the host node. The attestation validation service may be included as part of a bump-in-the-wire node (e.g., a Smart Network Interface Controller (SmartNIC)) within the cloud infrastructure. Implementing the attestation validation service in a SmartNIC may offload processing tasks from central components of the cloud infrastructure, thereby increasing the data processing efficiency of the cloud infrastructure. Furthermore, if there is a failure within the attestation validation service, the attestation validation service may run on a SmartNIC on the edge of the cloud infrastructure and affect only a small number of devices / applications.

[0018] The present embodiment relates to an edge attestation service for authentication and authorization of a host node in a network environment. Before a new host node is allowed to access the network, an authentication process may be performed. For example, a console may interact with an edge component (e.g., smartNIC) in a cloud infrastructure to obtain a set of authentication data (e.g., public endorsement key, tenancy authentication data) for validation of the new host node.

[0019] In some cases, the SmartNIC may provide a pre-boot execution environment (e.g., iPXE) to the host node to allow the host node to perform a boot procedure without requiring an OS to be previously installed on the host node. For example, an iPXE client may be provided to the host node to enable communication between an iPXE client running on the host node and an iPXE environment running on the SmartNIC.

[0020] The SmartNIC may transmit 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 the generated public / private key pair). The SmartNIC may obtain the endorsement key, compare it to the public endorsement key received in the set of authentication data, and verify that the endorsement key obtained from the host node corresponds to (e.g., matches) the public endorsement key received in the set of authentication data. Verifying the received endorsement key may verify the identity of the host node.

[0021] The SmartNIC may transmit a request for authentication data to the host node. The authentication data may include data that authenticates the host node, such as firmware configuration, device configuration, platform configuration register (PCR) values, etc. The host node may generate the authentication data and provide it to the SmartNIC. The received authentication data may be compared to the authentication policy received in the set of authentication data to validate the received authentication data (e.g., by matching PCR values ​​generated by the host node with corresponding PCR values ​​provided in the set of authentication data).

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

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

[0024] The console 102 may include a computing device (e.g., a laptop computer) capable of communicating with the CI system 104. For example, the console 102 may provide instructions to the CI system 104 to create an instance (e.g., including a set of authentication data) for the host node 108. As another example, the console 102 may instruct the host node 108 to fetch 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.

[0025] A CI system 104 as described herein 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 and provide access to database data (e.g., via queries of the database). The computing devices included in the CI system 104 (e.g., 106a-c) may be located within one or more data center environments (e.g., colocation centers).

[0026] 1, the computing device 106c may implement the SmartNIC 110. The SmartNIC 110 may be located on an edge component (e.g., the computing device 106c) in the CI system 104. For example, the SmartNIC 110 may reside on a server located in a data center that acts as an edge access point to the CI system 104. The SmartNIC 110 may implement a remote attestation service as described herein.

[0027] The host node 108 may include a computing device (e.g., a server) or a set of computing devices deployed in the CI system 104. For example, the host node may include a server connected to the CI system 104 in a data center environment (e.g., a colocation center) and requesting to access 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.

[0028] 2 is 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 the core functionality of the CI system 104 and edge devices that maintain a SmartNIC 110. The SmartNIC 110 may interact with host nodes (e.g., 108) to obtain authentication data and verify authentication data as described herein.

[0029] The CI system 104 may include a preboot execution environment 204. The preboot 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 preboot execution environment without an installed operating system (OS) on the host node. For example, the host node may obtain an iPXE client from a SmartNIC and execute the iPXE client by interacting with the preboot execution environment 204 executing within the CI system 104.

[0030] The CI system 104 may include a storage module 206. The storage module 206 may store various data types across devices in the CI system 104 (e.g., mounted boot partitions for verified host nodes).

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

[0032] The first EK 210a may include a console-provided key that identifies the host node (e.g., a Trusted Platform Module (TPM) RSA key). The tenancy authorization policy 212 may include characteristics of the host node, such as firmware versions, configuration settings, PCR values, etc.

[0033] 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. Data in the host authentication data 214 may be compared to the console authentication data 208 for identification and verification of the host node as described herein.

[0034] The CI system 104 may include an authentication data acquisition module 218. The authentication data acquisition module 218 may obtain authentication data (e.g., console authentication data 208) and receive host authentication data (e.g., 214) from a host node, as described herein. In some cases, the authentication data acquisition 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 host node.

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

[0036] The CI system 104 may include an authentication data validation module 222. The authentication data validation module 222 may obtain / identify authentication data and compare the received authentication data to an authentication policy received from the console. For example, the authentication data may specify a firmware version, a host node configuration, PCR values ​​(e.g., a hashed series of values ​​added in response to components identified / activated during a boot procedure), etc. In this example, the authentication data may be compared to a tenancy authentication policy to match values, firmware versions, data types, etc. specific to the host node. In response to the key and authentication data being verified, the host node may be validated and granted access to the cloud infrastructure (e.g., by providing the host node with a network address).

[0037] B. Example Methods for Conducting Edge Attestation Procedures 3 is a signaling process 300 illustrating an example edge attestation process. As shown in FIG. 3, a console 302 and a host node 308 may interact with a SmartNIC 306 (e.g., running on an edge computing device in a CI system).

[0038] At 310, the console 302 may send a request to create a new host instance to the SmartNIC 306. The request to create a new host instance may identify the new host node and may include a first endorsement key and a tenancy authentication policy for validation of the host node.

[0039] At 312, the console 302 may send a request to start the 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 begin a boot procedure.

[0040] 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 enable a boot procedure to be performed by the host node 308 without an operating system being loaded onto the host node 308.

[0041] 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 the iPXE client interacting with an iPXE instance associated with the SmartNIC 306 executing on the edge device. Executing the pre-boot execution environment may perform boot procedures including executing boot procedures, starting services / applications and components, etc.

[0042] In some cases, PCR values ​​may be calculated during the boot procedure. The PCR values ​​may include a hashed series of values ​​that are indicative of the components / services each initiated by the host node 308. The PCR values ​​may be indicative of the state of the host node 308 after the boot procedure.

[0043] At 320, the host node 308 may request a network address from the SmartNIC 306. The network address (e.g., an IP address) may enable connection to the CI system. The SmartNIC 306 may only grant the network address in response to validating the host node as described herein.

[0044] 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 the key provided in the request to create an instance (e.g., at 310) provided by the console.

[0045] At 330, the SmartNIC 306 may request a set of authentication data from the host node 308. At 332, the host node 308 may generate the requested set of authentication data (e.g., details about the host node, firmware version, configuration settings, PCR values) as specified in the request for the set of authentication data. At 334, the host node 308 may send the set of authentication data to the SmartNIC 306 for validation of the authentication data.

[0046] At 336, the SmartNIC may verify the received public endorsement key and set of authentication data, which may include comparing data received from the host node 308 with data obtained from the console 302 (e.g., at 310) in the request to create the instance.

[0047] In response to verifying the received data, at 338, the SmartNIC 306 may send a network address to the host node 308. The network address may enable connection and data communication between the host node 308 and the CI system. At 340, the SmartNIC 306 may mount a boot partition specific to the host node in the block storage 304.

[0048] 4 is a block diagram 400 illustrating an example method implemented by a SmartNIC for performing an edge attestation process. At 402, the SmartNIC may obtain a set of authentication data from a console for authorization of a host node. The set of authentication data may include a first endorsement key and an authentication policy that identifies characteristics of the host node.

[0049] 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 procedure using the pre-boot execution environment client.

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

[0051] The SmartNIC may transmit a request for a second endorsement key to the host node at 408. The SmartNIC may receive the second endorsement key from the host node at 410. The second endorsement key may include a public attestation identity key (AIK).

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

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

[0054] At 418, the SmartNIC may compare the received host node authentication data with the authentication policy received in the set of authentication data to validate 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 a boot procedure). The second PCR value may include a hashed register value during the boot procedure of the host node indicating a state of the host node after the boot procedure. This may also include determining whether the first PCR value matches the second PCR value. The received host node authentication data may be validated in response to determining that the first PCR value matches the second PCR value.

[0055] 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.

[0056] 5 is a block diagram 500 illustrating an example method performed by a host node to be verified using an edge attestation process. At 502, the host node may receive a request to start an instance from a console. The request to start an instance may include instructions to communicate with a SmartNIC and instructions to perform a boot procedure.

[0057] 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 capable of performing a boot procedure without the use of an operating system on the host node by interacting with an iPXE instance on the SmartNIC.

[0058] At 510, the host node may transmit a request for a network address (e.g., 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 transmit 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 with the key received by the console.

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

[0060] At 524, the host node may receive a network address from the SmartNIC. The network address may enable connection / data transmission to a cloud infrastructure using the network address. The network address may be received in response to the SmartNIC verifying the authentication data.

[0061] C.IaaS overview As noted above, Infrastructure as a Service (IaaS) is one particular type of cloud computing. IaaS may be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider may host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), or the like). In some cases, an IaaS provider may also provide various services (e.g., billing, monitoring, logging, load balancing, clustering, etc.) that accompany those infrastructure components. Thus, because these services may be policy-driven, an IaaS user may be able to implement policies to drive load balancing to maintain application availability and performance.

[0062] In some cases, an IaaS customer may access resources and services over a wide area network (WAN), such as the Internet, and may use the cloud provider's services to install the remaining elements of the application stack. For example, a user may log into an IaaS platform to create virtual machines (VMs), install an operating system (OS) on each VM, deploy middleware such as databases, create storage buckets for workloads and backups, and even install enterprise software on the VMs. The customer may 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 the like.

[0063] In most cases, the cloud computing model requires the participation of a cloud provider. However, a cloud provider may not necessarily be a specialized third-party service providing (e.g., provisioning, renting, selling) IaaS. An entity may also choose to deploy a private cloud, becoming its own provider of infrastructure services.

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

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

[0066] In some cases, there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything can be done. Second, there is the challenge of evolving the existing infrastructure after everything has been provisioned (e.g., adding new services, modifying services, removing services, etc.). In some cases, these two challenges can be solved by allowing the configuration of the infrastructure to be specified declaratively. In other words, the infrastructure (e.g., which components are needed and how they interact) can be specified by one or more configuration files. Thus, the overall topology of the infrastructure (e.g., which resources depend on which and how they each work together) can be described declaratively. In some cases, once the topology is specified, workflows can be generated that create and / or manage the different components described in the configuration files.

[0067] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs), also known as a core network (e.g., possibly an on-demand pool of configurable and / or shared computing resources). In some examples, there may also be one or more inbound / outbound traffic group rules, as well as one or more virtual machines (VMs), that are provisioned to define how the network's inbound and / or outbound traffic is set up. Other infrastructure elements, such as load balancers, databases, or the like, may also be provisioned. The infrastructure may evolve over time as more infrastructure elements are desired and / or added.

[0068] In some cases, continuous deployment techniques may be employed to enable deployment of infrastructure code across various virtual computing environments. Additionally, the described techniques may enable infrastructure management within these environments. In some instances, a service team may write code that is desired to be deployed to one or more, but often many, different production environments (e.g., across a variety of different geographic locations, sometimes across the entire world). However, in some instances, the infrastructure onto which the code can be deployed may first need to be set up. In some cases, provisioning may be done manually, provisioning tools may be utilized to provision resources, and / or deployment tools may be utilized to deploy the code after the infrastructure has been provisioned.

[0069] 6 is a block diagram 600 illustrating an example pattern of an IaaS architecture according to at least one embodiment. A service operator 602 may be communicatively coupled to a secure host tenancy 604, which may include a virtual cloud network (VCN) 606 and a secure host subnet 608. In some examples, the service operator 602 may use one or more client computing devices, which may be portable handheld devices (e.g., iPhone®, mobile phone, iPad®, computing tablet, personal digital assistant (PDA)), or wearable devices (e.g., Google Glass® head mounted display), running software such as Microsoft Windows Mobile®, and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, and the like, and may be enabled with Internet, email, short message service (SMS), Blackberry®, or other communication protocols. Alternatively, the client computing devices may be general purpose personal computers, including, by way of example, personal and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of the various commercially available UNIX or UNIX-like operating systems, including, without limitation, the various GNU / Linux operating systems, such as Google Chrome OS.Alternatively, or in addition, the client computing devices may be any other electronic devices, such as thin-client computers, Internet-enabled gaming systems (e.g., Microsoft Xbox game consoles with or without Kinect® gesture input devices), and / or personal messaging devices, capable of communicating over a network that may access the VCN 606 and / or the Internet.

[0070] VCN 606 may include a local peering gateway (LPG) 610, which may be communicatively coupled to a secure shell (SSH) VCN 612 via an LPG 610 included in the SSH VCN 612. The SSH VCN 612 may include an SSH subnet 614, which may be communicatively coupled to a control plane VCN 616 via an LPG 610 included in the control plane VCN 616. The SSH VCN 612 may also 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 included in a service tenancy 619, which may be owned and / or operated by the IaaS provider.

[0071] The control plane VCN 616 may include a control plane demilitarized zone (DMZ) tier 620 that acts as a perimeter network (e.g., a portion of an enterprise network between an enterprise intranet and an external network). DMZ-based servers may have limited responsibility and help keep violations contained. Additionally, the DMZ tier 620 may include one or more load balancer (LB) subnets 622, a control plane app tier 624 that may include an app subnet 626, a control plane data tier 628 that may include a database (DB) subnet 630 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 622 included in the control plane DMZ tier 620 may be communicatively coupled to the app subnet 626 included in the control plane app tier 624 and an Internet gateway 634 that may be included in the control plane VCN 616, and the app subnet 626 may be communicatively coupled to the DB subnet 630 included in the control plane data tier 628, and a service gateway 636, and a network address translation (NAT) gateway 638. The control plane VCN 616 may include a service gateway 636 and a NAT gateway 638.

[0072] The control plane VCN 616 may include a data plane mirrored app tier 640, which may include an app subnet 626. The app subnet 626 included in the data plane mirrored app tier 640 may include a virtual network interface controller (VNIC) 642 on which a compute instance 644 may run. The compute instance 644 may communicatively couple the app subnet 626 of the data plane mirrored app tier 640 to the app subnet 626 included in the data plane app tier 646.

[0073] The data plane VCN 618 may include a data plane app tier 646, a data plane DMZ tier 648, and a data plane data tier 650. The data plane DMZ tier 648 may include a LB subnet 622 that may be communicatively coupled to an app subnet 626 of the data plane app tier 646 and an Internet gateway 634 of the data plane VCN 618. The app subnet 626 may be communicatively coupled to a service gateway 636 of the data plane VCN 618 and a NAT gateway 638 of the data plane VCN 618. The data plane data tier 650 may also include a DB subnet 630 that may be communicatively coupled to the app subnet 626 of the data plane app tier 646.

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

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

[0076] In some examples, secure host tenancy 604 may be directly connected to service tenancy 619, which may be otherwise isolated. Secure host subnet 608 may communicate with SSH subnet 614 through LPG 610, which may allow bidirectional communication through an otherwise isolated system. Connecting secure host subnet 608 to SSH subnet 614 may grant secure host subnet 608 access to other entities within service tenancy 619.

[0077] The control plane VCN 616 may enable users of the service tenancy 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 app tier 640 of the control plane VCN 616 may communicate with the data plane app tier 646 of the data plane VCN 618 via a VNIC 642 that may be included in the data plane mirror app tier 640 and the data plane app tier 646.

[0078] In some examples, a user, or customer, of the system can issue a request, e.g., create, read, update, or delete (CRUD) operations, through the public Internet 654, which can communicate the request to a metadata management service 652. The metadata management service 652 can communicate the request to the control plane VCN 616 through an Internet gateway 634. The request can be received by a LB subnet 622 included in the control plane DMZ tier 620. The LB subnet 622 can determine that the request is valid, and in response to this determination, the LB subnet 622 can transmit the request to an app subnet 626 included in the control plane app tier 624. If the request is validated and requires a call to the public Internet 654, the call to the public Internet 654 can be transmitted to a NAT gateway 638, which can make the call to the public Internet 654. Memory that may be desired to be stored by the request can be stored in the DB subnet 630.

[0079] In some examples, the data plane mirror app hierarchy 640 may facilitate direct communication between the control plane VCN 616 and the data plane VCN 618. For example, it may be desirable for changes, updates, or other suitable modifications to a configuration to be applied to resources included in the data plane VCN 618. Through the VNIC 642, the control plane VCN 616 can communicate directly with the resources included in the data plane VCN 618 and thereby perform the changes, updates, or other suitable modifications to the configuration thereon.

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

[0081] In another embodiment, the LB subnet 622 included in the control plane VCN 616 may be configured to receive signals from the service gateway 636. In this embodiment, the control plane VCN 616 and the data plane VCN 618 may be configured to be called by the IaaS provider's customers without calling the public Internet 654. The IaaS provider's customers may desire this embodiment because databases used by the customers may be stored in the service tenancy 619, which may be controlled by the IaaS provider and isolated from the public Internet 654.

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

[0083] The control plane VCN 716 may include a control plane DMZ tier 720 (e.g., the control plane DMZ tier 620 of FIG. 6 ) that may include a LB subnet 722 (e.g., the LB subnet 622 of FIG. 6 ), a control plane app tier 724 (e.g., the control plane app tier 624 of FIG. 6 ) that may include an app subnet 726 (e.g., the app subnet 626 of FIG. 6 ), and a control plane data tier 728 (e.g., the control plane data tier 628 of FIG. 6 ) that may include a database (DB) subnet 730 (e.g., similar to the DB subnet 630 of FIG. 6 ). The LB subnet 722 included in the control plane DMZ tier 720 may be communicatively coupled to an app subnet 726 included in the control plane app tier 724 and an Internet gateway 734 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 716, and the app subnet 726 may be communicatively coupled to a DB subnet 730 included in the control plane data tier 728, and a service gateway 736 (e.g., service gateway in FIG. 6 ), and a network address translation (NAT) gateway 738 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 716 may include the service gateway 736 and the NAT gateway 738.

[0084] The control plane VCN 716 may include a data plane mirror app tier 740 (e.g., data plane mirror app tier 640 of FIG. 6 ), which may include an app subnet 726. The app subnet 726 included in the data plane mirror app tier 740 may include a virtual network interface controller (VNIC) 742 (e.g., VNIC 642) on which a compute instance 744 (e.g., similar to compute instance 644 of FIG. 6 ) may run. The compute instance 744 may facilitate communication between the app subnet 726 of the data plane mirror app tier 740 and the app subnet 726 included in the data plane app tier 746 (e.g., data plane app tier 646 of FIG. 6 ) via the VNIC 742 included in the data plane mirror app tier 740 and the VNIC 742 included in the data plane app tier 746.

[0085] An Internet gateway 734 included in the control plane VCN 716 may be communicatively coupled to a metadata management service 752 (e.g., metadata management service 652 of FIG. 6), which may be communicatively coupled to a public Internet 754 (e.g., public Internet 654 of FIG. 6). The public Internet 754 may be communicatively coupled to a NAT gateway 738 included in the control plane VCN 716. A service gateway 736 included in the control plane VCN 716 may be communicatively coupled to cloud services 756 (e.g., cloud services 656 of FIG. 6).

[0086] In some examples, the data plane VCN 718 may be included in the customer tenancy 721. In this case, the IaaS provider may provide a control plane VCN 716 for each customer, and the IaaS provider may set up a unique compute instance 744, included in the service tenancy 719, for each customer. Each compute instance 744 may enable communication between the control plane VCN 716, included in the service tenancy 719, and the data plane VCN 718, included in the customer tenancy 721. The compute instance 744 may enable resources provisioned in the control plane VCN 716, included in the service tenancy 719, to be deployed or otherwise used in the data plane VCN 718, included in the customer tenancy 721.

[0087] In another example, an IaaS provider customer may have a database that resides in customer tenancy 721. In this example, control plane VCN 716 may include a data plane mirror app tier 740 that may include app subnet 726. The data plane mirror app tier 740 may reside in data plane VCN 718, but the data plane mirror app tier 740 may not reside in the data plane VCN 718. That is, the data plane mirror app tier 740 may have access to customer tenancy 721, but the data plane mirror app tier 740 may not reside in the data plane VCN 718 or be owned or operated by the IaaS provider customer. The data plane mirror app tier 740 may be configured to make calls to the data plane VCN 718, but may not be configured to make calls to any entities included in the control plane VCN 716. A customer may desire to deploy or otherwise use resources in the data plane VCN 718 that are provisioned in the control plane VCN 716, and the data plane mirror app tier 740 may facilitate the customer's desired deployment or other use of the resources.

[0088] In some embodiments, the IaaS provider's customer may apply filters to the data plane VCN 718. In this embodiment, the customer may determine which data plane VCNs 718 can access, and the customer may limit access from the data plane VCN 718 to the public Internet 754. The IaaS provider may not be able to apply filters or otherwise control the access of the data plane VCN 718 to any outside networks or databases. Applying filters and controls by the customer to the data plane VCN 718 included in the customer tenancy 721 may help isolate the data plane VCN 718 from other customers and from the public Internet 754.

[0089] In some embodiments, cloud services 756 may be called by service gateway 736 to access services that may not be on the public Internet 754, on the control plane VCN 716, or on the data plane VCN 718. The connection between cloud services 756 and the control plane VCN 716 or data plane VCN 718 may not be live or continuous. Cloud services 756 may be on different networks owned or operated by an IaaS provider. Cloud services 756 may be configured to receive calls from service gateway 736 and may be configured not to receive calls from the 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 call to deployment 6 is made by a service gateway 736 included in a control plane VCN 716 located in region 1, the call may be routed to deployment 6 in region 1. In this example, control plane VCN 716, or deployment 6 in region 1, may not be communicatively coupled to or otherwise in communication with deployment 6 in region 2.

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

[0091] The control plane VCN 816 may include a control plane DMZ tier 820 (e.g., the control plane DMZ tier 620 of FIG. 6 ) that may include a load balancer (LB) subnet 822 (e.g., the LB subnet 622 of FIG. 6 ), a control plane app tier 824 (e.g., the control plane app tier 624 of FIG. 6 ) that may include an app subnet 826 (e.g., similar to the app subnet 626 of FIG. 6 ), and a control plane data tier 828 (e.g., the control plane data tier 628 of FIG. 6 ) that may include a DB subnet 830. The LB subnet 822 included in the control plane DMZ tier 820 may be communicatively coupled to an app subnet 826 included in the control plane app tier 824 and to an Internet gateway 834 (e.g., Internet gateway 634 in FIG. 6 ) that may be included in the control plane VCN 816, which may be communicatively coupled to a DB subnet 830 included in the control plane data tier 828, as well as to a service gateway 836 (e.g., service gateway in FIG. 6 ) and a network address translation (NAT) gateway 838 (e.g., NAT gateway 638 in FIG. 6 ). The control plane VCN 816 may include the service gateway 836 and the NAT gateway 838.

[0092] The data plane VCN 818 may include a data plane app tier 846 (e.g., data plane app tier 646 of FIG. 6), a data plane DMZ tier 848 (e.g., data plane DMZ tier 648 of FIG. 6), and a data plane data tier 850 (e.g., data plane data tier 650 of FIG. 6). The data plane DMZ tier 848 may include a trusted app subnet 860 and an untrusted subnet 862 of the data plane app tier 846, as well as a LB subnet 822 that may be communicatively coupled to an Internet gateway 834 included in the data plane VCN 818. The trusted app subnet 860 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818, a NAT gateway 838 included in the data plane VCN 818, and a DB subnet 830 included in the data plane data tier 850. The untrusted app subnet 862 may be communicatively coupled to a service gateway 836 included in the data plane VCN 818 and a DB subnet 830 included in the data plane data tier 850. The data plane data hierarchy 850 may include a DB subnet 830 that may be communicatively coupled to a service gateway 836 included in the data plane VCN 818.

[0093] The untrusted app subnet 862 may include one or more primary VNICs 864(1)-(N), which 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 app subnet 867(1)-(N), which may be included in a respective container egress VCN 868(1)-(N), which may be included in a respective customer tenancy 870(1)-(N). Each secondary VNIC 872(1)-(N) may facilitate communication between the untrusted app subnet 862 included in the data plane VCN 818 and the app subnet included in the container egress VCN 868(1)-(N). Each container egress VCN 868(1)-(N) may include a NAT gateway 838, which may be communicatively coupled to the public Internet 854 (e.g., public Internet 654 of FIG. 6).

[0094] The Internet gateway 834 included in the control plane VCN 816 and the Internet gateway 834 included in the data plane VCN 818 may be communicatively coupled to a metadata management service 852 (e.g., metadata management system 652 of FIG. 6 ), which 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 the NAT gateway 838 included in the data plane VCN 818. The service gateway 836 included in the control plane VCN 816 and the service gateway 836 included in the data plane VCN 818 may be communicatively coupled to cloud services 856.

[0095] In some embodiments, data plane VCN 818 may be integrated with customer tenancies 870. This integration may be useful or desirable for an IaaS provider's customers in some cases, such as when they may want support when executing code. The customers may provide code to be executed that may be disruptive, may communicate with other customer resources, or may otherwise cause undesirable effects. In response, the IaaS provider may determine whether to execute the code provided to the IaaS provider by the customer.

[0096] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider to request a function associated with data plane tier app 846. The code to execute the function may be executed within VMs 866(1)-(N), and the code may not be configured to execute elsewhere in data plane VCN 818. Each VM 866(1)-(N) may be connected to one customer tenancy 870. Each container 871(1)-(N) contained in a VM 866(1)-(N) may be configured to execute code. In this case, there may be double isolation (e.g., container 871(1)-(N) executing code, in this case container 871(1)-(N) may be contained in at least VMs 866(1)-(N) contained in untrusted app subnet 862), which may help prevent incorrect or otherwise undesirable code from causing damage to the IaaS provider's network or from causing damage to a different customer's network. Containers 871(1)-(N) may be communicatively coupled to customer tenancy 870 and may be configured to transmit or receive data from customer tenancy 870. Containers 871(1)-(N) may not be configured to transmit or receive data from any other entity in data plane VCN 818. Upon completing execution of the code, the IaaS provider may destroy or otherwise dispose of containers 871(1)-(N).

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

[0098] 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 not be 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 that 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 a cloud service 856 through a service gateway 836. For example, a call from the control plane VCN 816 to the cloud service 856 may include a request for a service that may communicate with the data plane VCN 818.

[0099] 9 is a block diagram 900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 902 (e.g., service operator 602 of FIG. 6) may be communicatively coupled to a secure host tenancy 904 (e.g., secure host tenancy 604 of FIG. 6), which may include a virtual cloud network (VCN) 906 (e.g., VCN 606 of FIG. 6) and a secure host subnet 908 (e.g., secure host subnet 608 of FIG. 6). VCN 906 may include an LPG 910 (e.g., LPG 610 of FIG. 6), which may be communicatively coupled to an SSH VCN 912 (e.g., SSH VCN 612 of FIG. 6) via an LPG 910 included in SSH VCN 912. SSH VCN 912 may include an SSH subnet 914 (e.g., SSH subnet 614 in FIG. 6), which may be communicatively coupled to a control plane VCN 916 (e.g., control plane VCN 616 in FIG. 6) via an LPG 910 included in the control plane VCN 916, and to a data plane VCN 918 (e.g., data plane 618 in FIG. 6) via an LPG 910 included in the data plane VCN 918. The control plane VCN 916 and the data plane VCN 918 may be included in a service tenancy 919 (e.g., service tenancy 619 in FIG. 6).

[0100] The control plane VCN 916 may include a control plane DMZ tier 920 (e.g., the control plane DMZ tier 620 of FIG. 6) that may include a LB subnet 922 (e.g., the LB subnet 622 of FIG. 6), a control plane app tier 924 (e.g., the control plane app tier 624 of FIG. 6) that may include an app subnet 926 (e.g., the app subnet 626 of FIG. 6), and a control plane data tier 928 (e.g., the control plane data tier 628 of FIG. 6) that may include a DB subnet 930 (e.g., the DB subnet 830 of FIG. 8). The LB subnet 922 included in the control plane DMZ tier 920 may be communicatively coupled to an app subnet 926 included in the control plane app tier 924 and to an Internet gateway 934 (e.g., Internet gateway 634 of FIG. 6 ) that may be included in the control plane VCN 916, which may be communicatively coupled to a DB subnet 930 included in the control plane data tier 928, as well as to a service gateway 936 (e.g., service gateway of FIG. 6 ) and a network address translation (NAT) gateway 938 (e.g., NAT gateway 638 of FIG. 6 ). The control plane VCN 916 may include the service gateway 936 and the NAT gateway 938.

[0101] The data plane VCN 918 may include a data plane app tier 946 (e.g., data plane app tier 646 of FIG. 6), a data plane DMZ tier 948 (e.g., data plane DMZ tier 648 of FIG. 6), and a data plane data tier 950 (e.g., data plane data tier 650 of FIG. 6). The data plane DMZ tier 948 may include a trusted app subnet 960 (e.g., trusted app subnet 860 of FIG. 8) and an untrusted app subnet 962 (e.g., untrusted app subnet 862 of FIG. 8) of the data plane app tier 946, as well as a LB subnet 922 that may be communicatively coupled to an Internet gateway 934 included in the data plane VCN 918. The trusted app subnet 960 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918, a NAT gateway 938 included in the data plane VCN 918, and a DB subnet 930 included in the data plane data tier 950. The untrusted app subnet 962 may be communicatively coupled to a service gateway 936 included in the data plane VCN 918 and a DB subnet 930 included in the data plane data tier 950. The data plane data tier 950 may include the DB subnet 930, which may be communicatively coupled to a service gateway 936 included in the data plane VCN 918.

[0102] The untrusted app subnet 962 may include primary VNICs 964(1)-(N) that may be communicatively coupled to tenant virtual machines (VMs) 966(1)-(N) that reside in the untrusted app subnet 962. Each tenant VM 966(1)-(N) may execute code within a respective container 967(1)-(N) and may be communicatively coupled to an app subnet 926 that may be included in a data plane app tier 946 that may be included in a container egress VCN 968. Each secondary VNIC 972(1)-(N) may facilitate communication between the untrusted app subnet 962 included in the data plane VCN 918 and the app subnet included in the container egress VCN 968. The container egress VCN may include a NAT gateway 938 that may be communicatively coupled to the public Internet 954 (e.g., public Internet 654 of FIG. 6).

[0103] The internet gateway 934 included in the control plane VCN 916 and the internet gateway 834 included in the data plane VCN 918 may be communicatively coupled to a metadata management service 952 (e.g., metadata management system 652 of FIG. 6 ), which 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 the NAT gateway 938 included in the data plane VCN 918. The service gateway 936 included in the control plane VCN 916 and the service gateway 936 included in the data plane VCN 918 may be communicatively coupled to cloud services 956.

[0104] In some examples, the pattern illustrated by the architecture of block diagram 900 of FIG. 9 may be considered an exception to the pattern illustrated by the architecture of block diagram 800 of FIG. 8 and may be desirable for customers of an IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., in a disconnected area). Each container 967(1)-(N) included in a VM 966(1)-(N) for each customer may be accessed in real time by the customer. The containers 967(1)-(N) may be configured to make calls to each secondary VNIC 972(1)-(N) included in an app subnet 926 of a data plane app tier 946 that may be included in a container egress VCN 968. The secondary VNICs 972(1)-(N) may carry calls to a NAT gateway 938 that may carry calls to the public Internet 954. In this example, containers 967(1)-(N) that may be accessed in real time by customers may be isolated from control plane VCN 916 and may be isolated from other entities included in data plane VCN 918. Containers 967(1)-(N) may also be isolated from resources from other customers.

[0105] In another example, a customer may use container 967(1)-(N) to invoke cloud service 956. In this example, the customer may execute code within container 967(1)-(N) that requests 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 922 included in control plane VCN 916 via Internet gateway 934. In response to determining that the request is valid, the LB subnet may transmit the request to app subnet 926, which may transmit the request to cloud service 956 via service gateway 936.

[0106] It should be understood that the IaaS architectures 600, 700, 800, 900 depicted in the figures may have components other than those depicted. Additionally, the embodiments depicted in the figures are only some examples of cloud infrastructure systems that may incorporate embodiments of the present disclosure. In some other embodiments, the IaaS systems may have more or fewer components than depicted in the figures, may combine two or more components, or may have components in different configurations or arrangements.

[0107] In certain embodiments, the IaaS system described herein may include a suite of application, middleware, and database services 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) offered by the assignee.

[0108] 10 illustrates an example computer system 1000 in which various embodiments may be implemented. System 1000 may be used to implement any of the computer systems described above. As shown in the figure, computer system 1000 includes a processing unit 1004 that communicates with several peripheral subsystems via a bus subsystem 1002. These peripheral subsystems may include a processing accelerator 1006, an I / O subsystem 1008, a storage subsystem 1018, and a communication subsystem 1024. The storage subsystem 1018 includes a tangible computer readable storage medium 1022 and a system memory 1010.

[0109] Bus subsystem 1002 provides a mechanism for allowing the various components and subsystems of computer system 1000 to communicate with one another as intended. Although bus subsystem 1002 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 1002 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a MicroChannel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a Mezzanine bus manufactured to the IEEE P1386.1 standard.

[0110] 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 particular embodiments, the processing unit 1004 may be implemented as one or more independent processing units 1032 and / or 1034 with a single or multi-core processor 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.

[0111] In various embodiments, the processing unit 1004 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 1004 and / or the storage subsystem 1018. Through suitable programming, the processor 1004 may provide various functionality as described above. The computer system 1000 may additionally include a processing accelerator 1006, which may include a digital signal processor (DSP), special purpose processor, and / or the like.

[0112] The I / O subsystem 1008 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a switch, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, a motion sensing and / or gesture recognition device such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices may also include an eye gesture recognition device such as a Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" while taking a picture and / or making a menu selection) and translates the eye gesture as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® navigator) through voice commands.

[0113] User interface input devices may also include, without limitation, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital camcorders, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. Additionally, user interface input devices may include medical imaging input devices, such as, for example, computed tomography, magnetic resonance imaging, position emission tomography, medical ultrasound diagnostic devices, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, and the like.

[0114] User interface output devices may include non-visual displays such as display subsystems, indicator lights, or audio output devices. Display subsystems may be flat panel devices such as those using cathode ray tubes (CRT), liquid crystal displays (LCD) or plasma displays, projection devices, touch screens, and the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 1000 to a user or to another computer. For example, user interface output devices may include various display devices that visually convey text, graphics, and audio / video information, such as, without limitation, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0115] Computer system 1000 may include a storage subsystem 1018 that comprises software elements currently shown as located within system memory 1010. System memory 1010 may store program instructions that are loadable and executable on processing unit 1004, as well as data generated during the execution of these programs.

[0116] Depending on the configuration and type of computer system 1000, the 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 on and executed by the processing unit 1004. In some implementations, the system memory 1010 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS), containing the basic routines that help to transfer information between elements within the computer system 1000, such as during start-up, may typically be stored in ROM. By way of example, and not limitation, the system memory 1010 also illustrates application programs 1012, program data 1014, and an operating system 1016, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like. By way of example, operating system 1016 may include various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, without limitation, various GNU / Linux operating systems, Google Chrome OS, and the like), and / or mobile operating systems such as iOS, Windows Phone, Android OS, BlackBerry 10 OS, and Palm OS operating systems.

[0117] The storage subsystem 1018 may also provide a tangible computer readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. Software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above 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.

[0118] Storage subsystem 1000 may also include a computer-readable storage medium reader 1020 that may be further connected to a computer-readable storage medium 1022. Together, and optionally in combination with the system memory 1010, computer-readable storage medium 1022 may comprehensively represent storage media for containing, storing, transmitting, and retrieving computer-readable information on a temporary and / or more permanent basis, in addition to remote, local, fixed, and / or removable storage devices.

[0119] The computer readable storage medium 1022 containing the code or portions of code may also include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media implemented in any manner or technology for storing and / or transmitting 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, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or other tangible computer readable media. This may also include non-tangible computer readable media, such as data signals, data transmissions, or any other medium that may be used to transmit the desired information and that may be accessed by the computing system 1000.

[0120] As examples, the computer readable storage medium 1022 may include hard disk drives that read from or write to non-removable non-volatile magnetic media, magnetic disk drives that read from or write to removable non-volatile magnetic disks, and optical disk drives that read from or write to removable non-volatile optical disks, such as CD ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer readable storage medium 1022 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer readable storage medium 1022 may also include solid state drives (SSDs) based on non-volatile memory, such as flash memory-based SSDs, enterprise flash drives, solid state ROMs, and the like, SSDs based on volatile memory, such as solid state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. The disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for computer system 1000.

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

[0122] In some embodiments, the communications subsystem 1024 may 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 be using the computer system 1000.

[0123] By way of example, the communications subsystem 1024 may be configured to receive data feeds 1026 in real time from users of social networks and / or other communications services, such as web feeds such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party sources.

[0124] Additionally, the communications subsystem 1024 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 1028 of real-time events, and / or event updates 1030, which may be effectively continuous or infinite without an apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automotive traffic monitoring, and the like.

[0125] The communications subsystem 1024 may also be configured to output structured and / or unstructured data feeds 1026, event streams 1028, event updates 1030, and the like to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 1000.

[0126] The computer system 1000 may be one of a variety of types, including a handheld mobile device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system.

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

[0128] Although specific embodiments have been described, various modifications, variations, alternative constructions, and equivalents are also encompassed within the scope of the disclosure. The embodiments are not limited to operation in one particular data processing environment, but operate freely in multiple data processing environments. Additionally, while the embodiments have been described using a particular sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the disclosure is not limited to the sequence of transactions and steps described. Various features and aspects of the above-described embodiments may be used individually or jointly.

[0129] Furthermore, while the embodiments are described using a particular combination of hardware and software, it should be understood that other combinations of hardware and software are within the scope of the present disclosure. The embodiments may be implemented using only hardware, only software, or a combination thereof. The various processes described herein may be implemented on the same processor, or on different processors in any combination. Thus, when a component or module is described as being configured to perform an operation, such configuration may be achieved, for example, by 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. Processes may communicate using a variety of techniques, including but not limited to conventional techniques for inter-process communication, and different pairs of processes may use different techniques, or the same pair of processes may use different techniques at different times.

[0130] Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. It will be apparent, however, that additions, subtractions, deletions, and other modifications and alterations may be made without departing from the broad spirit and scope as set forth in the claims. Thus, while certain disclosed embodiments have been described, they are not intended to be limiting. Various modifications and equivalents are within the scope of the following claims.

[0131] Use of the terms "a," "an," and "the" and similar referents in the context of describing the disclosed embodiments (particularly in the context of the claims below) shall be construed to cover both the singular and the plural, unless otherwise indicated herein or clearly contradicted by context. The terms "comprising," "having," "including," and "containing" shall be construed as open-ended terms (i.e., meaning "including but not limited to"), unless otherwise indicated. The term "connected" shall be construed as contained within, attached to, or joined together, either partially or wholly, even if there is an intervening material. Recitations of ranges of values ​​within this specification are merely intended to serve as a shorthand method of referring individually to each separate value falling within the range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were individually recited herein. All methods described herein may be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. The use of any and all examples or exemplary language provided herein (e.g., "etc.") is intended merely to clarify the embodiments and does not limit the scope of the disclosure unless otherwise claimed. No language in the specification should be construed as indicating any non-claimed element essential to the practice of the disclosure.

[0132] Disjunctions such as the phrase "at least one of X, Y, or Z" are intended to be understood in context as being commonly used to indicate that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise. Thus, such disjunctions are generally not intended to, and should not, suggest that an embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present.

[0133] Preferred embodiments of the present disclosure, including the best mode known for carrying out the present disclosure, are described herein. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the foregoing description. Those skilled in the art may adopt such variations as appropriate, and the present disclosure may be practiced apart from those specifically described herein. Accordingly, the present disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, any combination of the above-described elements in all possible variations thereof is encompassed by the present disclosure, unless otherwise indicated herein.

[0134] All references cited in this specification, including publications, patent applications, and patents, 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.

[0135] In the foregoing specification, aspects of the disclosure are described with reference to specific embodiments thereof, but those skilled in the art will recognize that the disclosure is not limited thereto. Various features and aspects of the above-described disclosure may be used individually or jointly. Moreover, the embodiments may be utilized in any number of environments and applications beyond those described herein without departing from the broad spirit and scope of the specification. Thus, the specification and drawings should be regarded as illustrative rather than restrictive.

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

Claims

1. 1. A method, comprising: receiving, at an edge node of a cloud infrastructure environment, a first request from a console associated with the cloud infrastructure environment; the first request includes first instructions to create a host instance for a host node; the first request includes a set of authentication data for an edge attestation process; the set of authentication data includes a first endorsement key and a first set of state data; The first set of state data indicates a baseline state of the host node, and the method further comprises: receiving, at the edge node, a second request from the host node; The second request includes second instructions for connecting the host node to the cloud infrastructure environment, and the method further comprises: performing the edge attestation process at least in part via the edge node; The edge attestation process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by comparing at least the second endorsement key with the first endorsement key; and receiving, at the edge node, a second set of state data, the second set of state data indicating a state of the host node, the edge attestation process further comprising: verifying the second set of status data by comparing at least the second set of status data with the first set of status data, the method further comprising: transmitting, from the edge node to the host node, a network address corresponding to a resource in the cloud infrastructure environment in response to verifying the second endorsement key and the second set of state data; The host node accesses the resource using the network address.

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

3. The method of claim 1 or 2, wherein the edge node is a component of a smart network interface controller.

4. The method comprises: before receiving the second request from the host node; receiving a pre-boot request for a pre-boot execution environment client from the host node; transmitting the pre-boot execution environment client to the host node; The method of claim 1 or 2, wherein the host node executes a boot procedure using the pre-boot execution environment client.

5. The method further includes mounting a boot partition on the storage module; The method of claim 1 or 2, wherein the boot partition is specific to the host node, and the network address corresponds to the boot partition.

6. 3. The method of claim 1, wherein the second request includes a request for the network address, and wherein the second request is sent from the host node in response to the host node connecting to a data center environment comprising one or more computing devices that implement the cloud infrastructure environment.

7. 1. A system comprising: the system comprises at least one hardware processor; The system is configured to perform operations using the at least one hardware processor, 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; the first request includes first instructions to create a host instance for a host node; the first request includes a set of authentication data for an edge attestation process; the set of authentication data includes a first endorsement key and a first set of state data; The first set of state data indicates a baseline state of the host node, and the operation further comprises: receiving, at the edge node, a second request from the host node; The second request includes second instructions for connecting the host node to the cloud infrastructure environment, and the operations further include: performing the edge attestation process at least in part via the edge node; The edge attestation process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by comparing at least the second endorsement key with the first endorsement key; and receiving, at the edge node, a second set of state data, the second set of state data indicating a state of the host node, the edge attestation process further comprising: verifying the second set of status data by comparing at least the second set of status data with the first set of status data, the operations further comprising: transmitting, from the edge node to the host node, a network address corresponding to a resource in the cloud infrastructure environment in response to verifying the second endorsement key and the second set of state data; The host node accesses the resource using the network address.

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

9. The operation is before receiving the second request from the host node; receiving a pre-boot request for a pre-boot execution environment client from the host node; transmitting the pre-boot execution environment client to the host node; The system according to claim 7 or 8, wherein the host node executes a boot procedure using the pre-boot execution environment client.

10. Validating the second set of status data by comparing at least the second set of status data with the first set of status data includes: identifying a first platform configuration register value included in the first set of state data; identifying a second platform configuration register value included in the first set of state data; and determining that the first platform configuration register value matches the second platform configuration register value.

11. The operations further include mounting a boot partition on the storage module; 9. The system of claim 7, wherein the boot partition is specific to the host node, and the network address corresponds to the boot partition.

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

13. 1. A computer readable program comprising instructions that, when executed by one or more hardware processors, cause the instructions to perform operations, said operations including: receiving, at an edge node of a cloud infrastructure environment, a first request from a console associated with the cloud infrastructure environment; the first request includes first instructions to create a host instance for a host node; the first request includes a set of authentication data for an edge attestation process; the set of authentication data includes a first endorsement key and a first set of state data; The first set of state data indicates a baseline state of the host node, and the operation further comprises: receiving, at the edge node, a second request from the host node; The second request includes second instructions for connecting the host node to the cloud infrastructure environment, and the operations further include: performing the edge attestation process at least in part via the edge node; The edge attestation process includes: receiving, at the edge node, a second endorsement key from the host node; verifying the second endorsement key by comparing at least the second endorsement key with the first endorsement key; and receiving, at the edge node, a second set of state data, the second set of state data indicating a state of the host node, the edge attestation process further comprising: verifying the second set of status data by comparing at least the second set of status data with the first set of status data, the operations further comprising: transmitting, from the edge node to the host node, a network address corresponding to a resource in the cloud infrastructure environment in response to verifying the second endorsement key and the second set of state data; The host node accesses the resource using the network address.

14. 14. The computer-readable program of claim 13, wherein the second endorsement key comprises a public key component of a public attestation identity key.

15. Validating the second set of status data by comparing at least the second set of status data with the first set of status data includes: identifying a first platform configuration register value included in the first set of state data; identifying a second platform configuration register value included in the first set of state data; and determining that the first platform configuration register value matches the second platform configuration register value.

16. The operations further include mounting a boot partition on the storage module; 15. The computer readable program of claim 13 or 14, wherein the boot partition is specific to the host node, and the network address corresponds to the boot partition.

17. 15. The computer-readable program of claim 13 or 14, wherein the second request includes a request for the network address, and wherein the second request is sent from the host node in response to the host node connecting to a data center environment comprising one or more computing devices implementing the cloud infrastructure environment.

18. 15. The computer readable program of claim 14, wherein the first endorsement key comprises a key generated by a trusted platform module.

19. 20. The computer readable program of claim 18, wherein the first endorsement key identifies the host node.

20. The operations include, before receiving the second request from the host node: receiving a pre-boot request from the host node, the pre-boot request being a request for the edge node to send a first pre-boot execution environment client to the host node, and before receiving the second request from the host node, the operations further include: The computer-readable program of claim 13 or 14, further comprising transmitting the first pre-boot execution environment client to the host node, wherein the host node executes a boot procedure using the first pre-boot execution environment client.

21. 21. The computer-readable program of claim 20, wherein the second set of state data includes one or more hashed register values ​​indicating a state of the host node as a result of executing at least a portion of the boot procedure.

22. 21. The computer-readable program of claim 20, wherein the second set of state data comprises a platform configuration register value, the platform configuration register value comprising a plurality of hashed register values, each hashed register value of the plurality of hashed register values ​​indicating a particular state of the host node during the boot procedure.

23. 23. The computer-readable program of claim 22, wherein each hashed register value in the plurality of hashed register values ​​indicates a particular component or a particular service initiated by the host node.

24. The operation is After transmitting the first pre-boot execution environment client to the host node, executing a second pre-boot execution environment; transmitting information associated with the second pre-boot execution environment to the host node while the host node is executing the boot procedure using the first pre-boot execution environment client; 21. The computer readable program of claim 20, wherein the information associated with the second pre-boot execution environment includes operating system information corresponding to an operating system executing in association with the second pre-boot execution environment.

25. 25. The computer readable program of claim 24, wherein the edge node is a component of a smart network interface controller, and the operating system is installed on the smart network interface controller.

26. 25. The computer-readable program of claim 24, wherein information associated with the second pre-boot execution environment enables the host node to execute the boot procedure without the operating system installed on the host node.

27. 21. The computer readable program of claim 20, wherein the host node generates at least a portion of the second set of state data during the boot procedure.

28. the edge attestation process further includes sending a third request from the edge node to the host node; the third request is a request for the edge node to provide the second endorsement key; 15. The computer-readable program of claim 13 or 14, wherein the host node receives the third request, and in response to receiving the third request, the host node generates the second endorsement key and sends the second endorsement key to the edge node.

29. the edge attestation process further includes sending a third request from the edge node to the host node; the third request is a request for the edge node to provide the second set of state data; 15. The computer-readable program of claim 13 or 14, wherein the host node receives the third request, and in response to receiving the third request, the host node generates the second set of state data and sends the second set of state data to the edge node.

Images