Cloud-based cross-domain system - Virtual data diode

Abstract

In some aspects, a network interface card (NIC) may receive a message destined for the unconnected network and sent using a first communication protocol at a first node of the network interface card associated with the unconnected network. The network interface card may send the message from the first node of the network interface card to a second node of the network interface card using a second communication protocol configured for unidirectional communication. The network interface card may receive the message at the second node. The network interface card may send the message from the second node to a destination node of the unconnected network using a third communication protocol. Many other aspects are described.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a joint venture of U.S. patent application Ser. No. 17 / 534,187, entitled "CLOUD BASED CROSS DOMAIN SYSTEM - VIRTUAL DATA DIODE" (Attorney Docket No. 088325-1259513 (296100US)), filed on November 23, 2021, U.S. patent application Ser. No. 17 / 534,194, entitled "CLOUD BASED CROSS DOMAIN SYSTEM - CDSaaS" (Attorney Docket No. 088325-1259518 (296110US)), filed on November 23, 2021, and U.S. patent application Ser. No. 17 / 534,196, entitled "CLOUD BASED CROSS DOMAIN SYSTEM - CDS WITH DISAGGREGATED PARTS" (Attorney Docket No. 088325-1260117 (US 296120)), the entire disclosure of which is incorporated herein by reference.

[0002] Field The present disclosure relates to network security, and more particularly to cross-domain solutions. [Background technology]

[0003] background Technology exists for hardware-implemented cross-domain solutions that control and inspect data entering a dedicated network, however such technology is difficult to maintain and operate. Summary of the Invention

[0004] Quick Overview Techniques are provided for a software-implemented cloud-based cross-domain system that enables secure one-way traffic to a dedicated network without the need for special hardware.

[0005] In one embodiment, a system of one or more computers can be configured to perform certain operations or actions by installing software, firmware, hardware, or a combination thereof on the system, which, when in operation, causes the system to perform the actions. One or more computer programs can be configured to perform certain operations or actions by including instructions that, when executed by a data processing device, cause the device to perform the actions. One general aspect includes a computer-implemented method. The computer-implemented method also includes receiving, at a first node of a network interface card (NIC) associated with the unconnected network, a message or data destined for the unconnected network and sent using a first communication protocol. The method also includes sending the message or data from the first node of the network interface card to a second node using a second communication protocol configured for unidirectional communication. The method also includes receiving the message or data at the second node. The method also includes sending the message or data from the second node to a destination node of the unconnected network using a third communication protocol. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs stored on one or more computer storage devices, each configured to perform the actions of the methods described above.

[0006] In one general aspect, the second communications protocol is the User Datagram Protocol (UDP).

[0007] In one general aspect, the network interface card comprises a smart network interface card (smart NIC). A smart NIC can process messages or data arriving at one of its interfaces and forward them to another interface. The process can be in the form of software and / or hardware that parses incoming messages and / or transforms them according to rules configurable in the smart NIC.

[0008] In one general aspect, the disconnected network includes a virtual cloud network. In one general aspect, a disconnected network is not connected to the Internet.

[0009] In one general aspect, after a message leaves a second node, it passes through a filter chain before reaching a destination node.

[0010] In one general aspect, the connection between the first node and the second node is established using a network link, such as an Ethernet cable.

[0011] In one general aspect, a connection established using a network link is capable of two-way communication.

[0012] One general aspect includes a computer program product including instructions tangibly embodied in one or more non-transitory machine-readable media and configured to cause one or more data processors to execute instructions, the instructions executed by the one or more data processors including receiving, at a first node of a network interface card (NIC) associated with the unconnected network, a message destined for the unconnected network and sent using a first communication protocol. The method also includes sending the message from the first node of the network interface card to a second node using a second communication protocol configured for unidirectional communication. The method also includes receiving the message at the second node. The method also includes sending the message from the second node to a destination node of the unconnected network using a third communication protocol. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the above methods.

[0013] One general aspect includes a network interface card (NIC) associated with an unconnected network, the network interface card comprising a first node, a second node, a memory storing computer-executable instructions, and one or more processors. The first node, the second node, and the one or more processors configured to access the memory and execute the computer-executable instructions receive, at least at the first node, a message destined for the unconnected network and sent using a first communication protocol. The one or more processors are also configured to send the message from the first node to the second node using a second communication protocol configured for unidirectional communication. The one or more processors are also configured to receive the message at the second node. The one or more processors are also configured to send the message from the second node to a destination node in the unconnected network using a third communication protocol. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the above method.

[0014] Techniques are provided for a cloud-based, cross-domain solution for Software as a Service (SaaS) provisioning that enables secure, one-way traffic to a dedicated network without the need for special hardware.

[0015] In one embodiment, a computing device of the virtual cloud network may select one or more filters from a plurality of filters for the data pipeline. The plurality of filters may include at least one of a malware filter, a content filter, a signature filter, and a content analyzer. The filters may be statically configured or dynamically updated using machine learning and artificial intelligence algorithms. A computing device of the virtual cloud network may determine an order of the one or more selected filters in the data pipeline. A computing device of the virtual cloud network may receive messages in the data pipeline from a network interface card (NIC). The network interface card may be configured as a one-way transmission device. Messages in the data pipeline may be filtered by passing the messages through the one or more selected filters in the determined order. A computing device of the virtual cloud network may provide a log of events occurring in the data pipeline via a logging network. Such an event log may include references to data such as sender and recipient, data type, name in the case of a file or value in the case of structured data, timestamp, and filtering decisions such as pass, reject, warn, etc. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs stored on one or more computer storage devices, each configured to perform the actions of the methods described above.

[0016] In one general aspect, the determined order is determined based at least in part on the source of the messages.

[0017] In one general aspect, the one or more selected filters are selected based at least in part on the source of the message.

[0018] In one general aspect, multiple filters are selected for the same message source.

[0019] In one general aspect, the network interface card includes a software-based one-way communication device.

[0020] In one general aspect, the method further includes modifying the one or more selected filters from the data pipeline after the message has been processed by the one or more selected filters in the determined order.

[0021] In one general aspect, the computing device is a virtual machine running in the cloud.

[0022] One general aspect includes a computer program product tangibly embodied in one or more non-transitory machine-readable media and including instructions configured to cause one or more data processors to execute instructions, the instructions executed by the one or more data processors including selecting one or more filters from a plurality of filters for a data pipeline, the plurality of filters including at least one of a malware filter, a content filter, a signature filter, and a content analyzer.

[0023] The filters are adaptable to be configured by machine learning and artificial intelligence. The models of these filters can be dynamically updated as part of a feedback loop. The feedback loop can be trained with test data sent through the system and marked as such. The test data can include data that is considered good and data that is considered bad. The algorithms can be adjusted based on the test data. In some situations, the data itself is not communicated to the end user, but is merely test data to adjust the machine learning / AI models deployed by the filter logic. Test data can continue to be sent upon discovery of new malware or threats. Test data can be sent from the untrusted network side or injected from the trusted network. Determining whether the sender of the test data is trustworthy can be achieved by cryptographic means. A trusted sender can sign a message containing the test data with a private key. The machine learning system that processes the test data to update the machine learning model can set the corresponding public key and can verify the authenticity of the sender. In some embodiments, the training of the AI ​​model can occur outside of the filtering system of the cross-domain solution. The fully trained model can be uploaded to the filtering system of the cross-domain solution via a secure channel. The model may be used in filtering content passing through the filtering system.

[0024] and determining an order of one or more selected filters in the data pipeline. Also including receiving messages in the data pipeline from a network interface card (NIC) configured as a one-way transmission device. Also including filtering messages in the data pipeline by passing the messages through the determined order of selected filters, and providing, via a logging network, a log of events occurring in the data pipeline. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the above methods.

[0025] One general aspect includes a data pipeline including a network interface card (NIC). The network interface card is configured as a one-way transmission device. The data pipeline also includes a plurality of filters including at least one of a malware filter, a content filter, a signature filter, and a content analyzer. The data pipeline also includes a virtual cloud network configured to include one or more of the plurality of filters. Messages received by the virtual cloud network from a network interface controller are passed sequentially through the one or more filters of the data pipeline in an order determined at configuration. The data pipeline can also include a logging network for providing a log of events occurring in the data pipeline. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the above method.

[0026] Techniques are provided for cross-domain solutions with distributed parts. In one embodiment, an application programming interface (API) configured to expose a set of filter types is generated by a computing device of the non-connected network. A set of one or more filter types from the set of filter types is received via the application programming interface. An order of the selected filter types is received via the application programming interface. A data pipeline including the set of filters in the order is generated by the computing device of the non-connected network in response to the command received via the application programming interface. A message received at the one-way transmission device is parsed by the computing device of the non-connected network by passing the message through the selected filters in the order. A logging network of the non-connected network receives a log of events occurring in the data pipeline. The log of events is exposed via the application programming interface. The data pipeline is terminated upon receiving a quit command via the application programming interface. Other embodiments of this aspect include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the above method.

[0027] In one general aspect, the one or more filter types include one or more of a malware filter, a content filter, a signature filter, and a content analyzer.

[0028] In one general aspect, the method further includes sending the message from the disconnected network to the trusted repository via the one-way transmission device.

[0029] In one general aspect, the one-way transfer device is a software-based one-way transfer device.

[0030] In one general aspect, the log of events includes logs of events occurring at the operating system (OS) level, the application level, and the payload level.

[0031] In one general aspect, the disconnected network includes a virtual cloud network. In one general aspect, the one-way communication device is a smart network interface card (smart NIC).

[0032] One general aspect includes a computer program product including instructions tangibly embodied in one or more non-transitory machine-readable media and configured to cause one or more data processors to execute instructions, the instructions executed by the one or more data processors including generating an application programming interface (API) configured to present a set of filter types; receiving a set of one or more filter types from the set of filter types via the application programming interface; receiving an order of selected filter types via the application programming interface; generating a data pipeline including the set of filters in the order in response to a command received via the application programming interface; parsing a message received at a one-way transmission device by passing the message through the selected filters in the order; receiving a log of events occurring in the data pipeline via a logging network of the non-connected network; presenting the log of events via the application programming interface and terminating the data pipeline upon receiving a command to terminate via the application programming interface.

[0033] One general aspect includes a system comprising a memory configured to store instructions and one or more processors configured to access the memory and execute the instructions, the one or more processors generating an application programming interface (API) configured to present at least a set of filter types; receiving a set of one or more filter types from the set of filter types via the application programming interface; receiving an order of selected filter types; generating a data pipeline including the set of filters in the order in response to a command received via the application programming interface; parsing messages received at a one-way transmission device by passing the messages through the selected filters in the order; receiving a log of events occurring in the data pipeline via a logging network in a non-connected network; presenting the log of events via the application programming interface; and terminating the data pipeline upon receiving a command to terminate via the application programming interface. [Brief description of the drawings]

[0034] [Figure 1] FIG. 1 is a simplified diagram of a hardware implemented non-connected network according to an embodiment. [Diagram 2] FIG. 2 illustrates a process for communication over a hardware-implemented non-connected network according to an embodiment. [Diagram 3] FIG. 2 illustrates a simplified representation of a cloud-based cross-domain solution that can be used to control access between domains, according to one embodiment. [Figure 4] FIG. 1 illustrates a process for controlling access between domains using a cloud-based domain service, according to an embodiment. [Diagram 5] FIG. 1 is a simplified diagram of a User Datagram Protocol (UDP) according to one embodiment. [Figure 6] FIG. 2 illustrates a process for communication over User Datagram Protocol (UDP) according to one embodiment. [Figure 7] FIG. 1 is a diagram of a data pipeline including a software implemented cross-domain solution according to an embodiment. [Figure 8] FIG. 1 illustrates a method for communication using a data pipeline including a software-implemented cross-domain solution according to an embodiment. [Figure 9A] FIG. 1 illustrates a user interface (UI) for configuring a cloud network, according to one embodiment. [Figure 9B] FIG. 1 illustrates a user interface (UI) for configuring a cross-domain solution, according to one embodiment. [Figure 10] FIG. 1 illustrates a methodology for a software implemented cross-domain solution according to an embodiment. [Figure 11] FIG. 1 illustrates a methodology for a Software as a Service (SaaS) based cross-domain solution according to an embodiment. [Figure 12] FIG. 2 illustrates a method for a cross-domain solution with a distributed part, according to an embodiment. [Figure 13] FIG. 1 is a high-level diagram of a distributed environment illustrating a virtual or overlay cloud network hosted by a cloud service provider infrastructure according to one embodiment. [Figure 14] FIG. 2 is a simplified architecture diagram of physical components in a physical network within a CSPI according to one embodiment. [Figure 15] FIG. 2 illustrates an exemplary configuration within CSPI in which a host machine is connected to multiple network virtualization devices (NVDs), according to one embodiment. [Figure 16] FIG. 2 illustrates a connection between a host machine and an NVD to provide I / O virtualization supporting multi-tenancy, according to one embodiment. [Figure 17] FIG. 2 is a simplified block diagram of a physical network provided by CSPI according to one embodiment. [Figure 18] FIG. 1 is a block diagram illustrating a pattern for implementing a service-based cloud infrastructure system in accordance with at least one embodiment. [Figure 19] FIG. 2 is a block diagram illustrating another pattern for implementing a service-based cloud infrastructure system in accordance with at least one embodiment. [Figure 20] FIG. 2 is a block diagram illustrating another pattern for implementing a service-based cloud infrastructure system in accordance with at least one embodiment. [Figure 21] FIG. 2 is a block diagram illustrating another pattern for implementing a service-based cloud infrastructure system in accordance with at least one embodiment. [Figure 22] FIG. 1 is a block diagram illustrating an exemplary computer system according to at least one embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0035] Detailed Description In the following specification, various embodiments are described. For the purpose of explanation, specific configurations and details are described to enable a thorough understanding of the embodiments. However, it will be apparent to those skilled in the art that the embodiments may be realized without these specific details. Furthermore, well-known features may be omitted or simplified so as not to obscure the description of the embodiments.

[0036] Embodiments of the present disclosure provide techniques for implementing a cloud-based cross-domain solution. In some examples, the cross-domain solution can limit access or communication of information between two or more security domains. The proposed system can be implemented with a network interface card (NIC) associated with a non-connected network.

[0037] The unconnected network may be a secure computer network that is isolated from communication with a non-secure network. The unconnected network may be configured to permit inbound traffic while disallowing outbound traffic. In one embodiment, a message sent in a first communication protocol may be received at a first node of a NIC. The received message may be forwarded to a second node of a network interface card using a second communication protocol. The second network communication protocol may be any protocol configured for one-way communication, such as User Datagram Protocol (UDP). The message may be received from the first node at the second node, but the second protocol does not allow traffic in the other direction. Once the traffic is received at the second node, the message is forwarded to a destination node of the unconnected network using a third communication protocol.

[0038] Cross-domain solutions may include non-connected networks that are separated from non-secure networks (e.g., public networks such as the Internet) by physical isolation (e.g., air gaps) or hardware that enforces one-way communication (e.g., bump-in-the-wire / data diodes). While secure, such networks are typically used in limited situations (e.g., military or government networks, industrial control systems, or safety-critical systems) because the systems are cumbersome, expensive to maintain, and involve specialized hardware. Additionally, in the case of cloud networks, neither physical isolation nor hardware-implemented one-way communication is feasible.

[0039] Through the use of software-implemented cross-domain solutions, cloud-based unconnected networks can be created without the inconvenience of physically moving data to the unconnected network (e.g., air gaps) or the need for hardware to physically enforce one-way communication (e.g., data diodes). Traffic entering the NIC of the unconnected region can be intercepted and transmitted within the NIC through the use of a one-way protocol. This protocol makes information in the unconnected network less susceptible to compromise by enforcing one-way traffic. In some situations, the cross-domain solution can include a separate one-way communication path from the unconnected network to a trusted source outside the network.

[0040] A message sent from the second node may pass through a series of filters before reaching a destination node in the non-connected network. The filters may protect the non-connected network from intrusions by analyzing the message. The filters may be configurable via an application programming interface (API) so that a client may select an appropriate set of filters based on security needs. The client may also select the time period of the cloud-based domain system. In some embodiments, the order of the filters or the individual filters used may be changed between messages to combat attempts to intrude into the network.

[0041] Traditional cross-domain solutions are implemented using custom hardware. Hardware can be expensive to design and difficult to maintain. Adding a filter or changing the order of filters in a traditional cross-domain solution requires removing, modifying, and replacing the hardware that contains the filters. Cloud-based cross-domain systems can be fully or partially implemented in the cloud. For example, a cross-domain solution can use hardware-enforced one-way communication, such as a data diode, and cloud-implemented content filters. Alternatively, the cross-domain solution may include software-enforced one-way communication and hardware-implemented content filters. Cloud-based cross-domain solutions allow for flexible configuration of the cross-domain solution.

[0042] A cloud-based cross-domain solution system may provide flexibility, making it adaptable to a variety of use cases. For example, different message settings may be applied to traffic from different sources, allowing fewer filters to be applied to messages from trusted sources. Filter order may be changed between messages or at regular intervals to complicate an attacker's attempt to design messages that can circumvent filters. Also, in some circumstances, one-way communication may be enforced for only a subset of messages received by the cross-domain solution.

[0043] Data about messages received by the cross-domain solution can be used to train an artificial intelligence and / or machine learning (AI / ML) content filter model. The data can include packet origins, characteristics of known viruses or malware, or traffic patterns. The AI / ML content filter can determine whether packets from a source are suspicious or trustworthy based on information provided by other content filters. For example, if traffic from a particular Internet Protocol (IP) address is consistently flagged as containing malware, the AI / ML filter can perform additional filtering on packets from that IP address or the same origin. The AI / ML filter can use information obtained from packets flagged by the content filter as containing malware or viruses to identify known or unknown viruses so that the cross-domain solution can adapt to new threats. The AI / ML filter can also use traffic patterns to identify threats. For example, a substantial increase in traffic from a source can indicate a potential threat.

[0044] AI / ML models can be continuously trained by data marked as "test or learning data" sent from trusted sources. Test data can include reference data that should be blocked or allowed to pass. Thus, if new malware or unauthorized content is detected, the test data can include malware signatures or other characteristics such as origins as well as hints to learning algorithms that would block such data if it were to be transmitted to the trusted network as a real payload. Test data can indicate malware patterns or specify specific attributes in structured data (e.g., data ranges for MQTT data that exceed a certain range).

[0045] In some situations, the source of the training data needs to be trusted. The authenticity of the source (sender) of the test data can be established by using cryptography. In one embodiment, the test data can be encrypted using the public key of the AI / ML algorithm and then signed with a private key known only to the sender. The AI / ML algorithm associated with the filter can be configured with the corresponding public key of the source of the test data, allowing it to verify the signature of the training data after decrypting the data itself using its private key. AI / ML learning can be extended to content filtering on payloads such as images to restrict resolution, metadata, or content to known patterns. Additionally, the AI / ML algorithm can instruct the filter to modify or re-encode the image to remove hidden malware or undesirable content.

[0046] An advantage of a cloud-implemented cross-domain solution is that the cross-domain solution can be exposed as a service to clients. The cross-domain solution can enable monitoring or oversight of the cloud domain service by a customer (e.g., a client). A customer can configure the cross-domain solution to select filters and / or the order of filters, and can specify the traffic that passes through the cross-domain solution. For example, a customer can whitelist a source to enable two-way communication between a non-connected network and a whitelisted source. A cloud-based cross-domain solution can provide flexibility of use that is not possible with a hardware-based cross-domain solution. Also, a cloud-based cross-domain solution can be realized without expensive and inflexible specialized hardware.

[0047] In one example, a customer is presented with an API for configuring a cloud-based cross-domain solution and selects a time period and a set of filters for the cloud-based cross-domain solution, where the customer selects a one-month time period and a malware filter followed by a content filter for the cloud-based distributed network.

[0048] Once configured, a message is sent from the source node destined for a destination node inside the unconnected network. The message is sent via Transmission Control Protocol / Internet Protocol (TCP / IP) and is received at a first node of the NIC. To pass through the NIC, the message may be converted from TCP / IP to a protocol suitable for one-way communication, and the communication protocol may be modified to be configured only for one-way communication. At the first node, the NIC converts the message to a one-way communication protocol, in this case User Datagram Protocol (UDP), and forwards the message to a second node of the NIC.

[0049] In situations where a message is sent via a streaming protocol (e.g., Real-Time Messaging Protocol (RTMP)), the entire message is intercepted at the first node as if the first node were the destination node before the message is forwarded to the second node. In this case, the message is not streamed, and as message packets are received, they are accepted, stored, and forwarded to the second node via a connectionless protocol such as UDP.

[0050] At the second node, the message is forwarded to the destination node inside the secure network using the network protocol employed in the secure network, which in this case uses TCP / IP, but may also use third protocols for internal communications, such as File Transfer Protocol (FTP), TCP / IP, User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), Post Office Protocol (POP3), Internet Message Access Protocol (IMAP), Simple Mail Transfer Protocol (SMTP), etc.

[0051] After the message leaves the second node, it passes through a series of configurable filters before it reaches the destination node, where malware filters scan the message to ensure it does not contain any malware that may infect the network, and content filters ensure that messages arriving on the network are of the appropriate type of content. After the message has passed all the filters, it is forwarded to its destination node.

[0052] 1 is a simplified diagram 100 of a hardware-implemented non-connected network, according to some embodiments. Non-connected networks can be computer networks that are physically isolated from other networks by removing physical and wireless network connections. Data travels between these air-gapped networks by physical storage media, such as thumb drives. While these networks are secure, transmitting data by thumb drive is cumbersome. Other non-connected networks use data diodes that allow one-way traffic into the non-connected network, but prevent the broadcast of sensitive information from the non-connected network.

[0053] The simplified diagram 100 shows a computing device A connected to a router A 104, according to some embodiments. The computing device A 102 can be a personal computer, a server computer, a virtual machine, a tablet device, a mobile phone, or any other computing device. The computing device A 104 can be physically connected to the router A 104, for example, by a network cable, or can be connected to the router A 104 wirelessly (e.g., WiFi). In some embodiments, the computing device A 102 can be connected to the Internet or a private network through the router A.

[0054] Computer A 102 can be connected to computer device B 106 via communication between router A 104 and router B 110. A network cable 112 including a data diode 108 can connect router A 104 and router B 110. A hardware data diode can enforce unidirectionality by physical means (e.g., an optical link consisting of an optical transmitter (often a laser or light-emitting diode (LED)) and a receiver, a photosensitive semiconductor such as a phototransistor) (e.g., data diode 108). Other unidirectional systems can be used to achieve the functionality of a unidirectional transmission device. In a unidirectional transmission system, a message received at a first terminal 114 of the data diode 108 can be passed to a second terminal 116 of the diode, while no message is sent from the second terminal 116 to the first terminal 114.

[0055] In some embodiments, the non-connected network is behind the second terminal 116 of the data diode 108. Messages may be sent to the non-connected network through the data diode 108, but the messages do not leave the non-connected terminal through the data diode. In these embodiments, the router B 110 and the computing device B 106 are isolated from the outside network, but the computing device B 106 can still connect to other devices inside the non-connected network through the router B 110. For example, computer B may be part of a network that contains sensitive information, and being able to send information outside the network may pose a security threat.

[0056] In other embodiments, the unconnected network resides behind the first terminal 114 of the data diode 108. In these embodiments, messages may be sent from the unconnected network to the outside network through the data diode 108, but the unconnected network does not receive the messages. Such networks may also be used in electronic voting systems where the system must be able to provide results to the public without being subject to inbound attacks.

[0057] FIG. 2 illustrates a process for communication over a hardware-implemented non-connected network, according to one embodiment. The process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions that are stored on one or more computer-readable storage media and that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The described order of operations is not intended to be construed in any way as a limitation, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0058] Describing process 200 in more detail, in block 202, a message is generated by computing device A102. The message may be sent from computing device A102 to a router A104 that can forward the message to its destination. Computing device A102 may be a personal computer, a mobile device, a tablet, or a server computer. Router A104 may be physically connected to computing device A102 by a cable (e.g., an Ethernet cable) that allows for transmission of the message. Alternatively, the message may be sent from computing device A102 to router A104 via radio waves (e.g., WiFi).

[0059] In block 204, the message sent by computing device A 102 is sent to a second computing device B 106 after passing through a data diode 108. The message may be forwarded from router A 104 to router B 110 via a network cable 112 (e.g., an Ethernet cable) that includes a data diode 108 (e.g., a BITW). The data diode 108 may allow one-way transmission of data, so that data including the message sent by router A 104 may pass through the data diode 108 to reach router B 110. Router B 110 may forward the message received from router A 104 to computing device B 106.

[0060] In block 206, the response generated by computing device B 106 is blocked by data diode 108. Although messages from router A 104 to router B 110 may pass through data diode 108, messages from router B 110 to router A 104 are blocked due to the one-way propagation restriction imposed by data diode 108. In this manner, computing device B 106 may be isolated from other computing devices because it cannot send outgoing messages.

[0061] 3 illustrates a simplified representation of a cloud-based cross-domain solution 300 that can be used to control access between domains, according to one embodiment. The cross-domain solution may include implementations that allow limited two-way communication between networks or implementations that include non-connected networks.

[0062] FIG. 4 illustrates a process for controlling access between domains using a cloud-based domain service, according to an embodiment. The process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions that are stored on one or more computer-readable storage media and that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order of the described operations is not intended to be construed as limiting in any way, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0063] Describing process 400 in more detail, in block 402, a message may be sent from domain A 302 to a restricted gateway 304 over a network 306. The message may be generated at a customer premises 308 within domain A 302. The restricted gateway 304 may be a smart network interface card (smart NIC) and the network 306 may be a private network or the Internet.

[0064] In block 404, analysis of the message by the restriction gateway may determine whether the message from domain A 302 should be allowed access to domain B 310. The restriction gateway 304 may use predefined access policies to determine whether the message should be allowed access.

[0065] The restriction gateway 304 may also use filters to analyze messages before allowing access to Domain B 310. The filters may include malware filters that check for malware and viruses in messages. The restriction gateway 304 may also include a signature filter that determines if the message has a cryptographically verifiable signature that proves the origin of the message. The filters may also include a content analyzer that determines the validity of the message. The content analyzer may check, for example, a checksum received out-of-band or in-band with the apparent associated payload. The data in the message may include a checksum that proves the validity of the data. The checksum may accompany the data itself. The checksum may also be conveyed as part of the data in a separate message. The filters may also include artificial intelligence or machine learning filters trained to determine if a message should be allowed access to Domain B 310.

[0066] In block 406, after the restriction gateway 304 determines that the message should be granted access, it may forward the message to domain B 310. The second domain may be a virtual cloud network 312. In some embodiments, the destination node of the message may be a workload 314 in the virtual cloud network 312. The workload 314 may include virtual machines, databases, containers, and applications.

[0067] Figure 5 is a simplified diagram 500 of the User Datagram Protocol (UDP), according to one embodiment. A communication protocol may allow one-way or two-way communication, but a non-connected network may use hardware to enforce one-way communication. In the example of Figure 5, a protocol such as UDP may enforce one-way communication.

[0068] To explain diagram 500 in more detail, the transmitter 506 and the receiver 502 can be computing devices capable of network communication. The transmitter 506 and the receiver 502 can be personal computers, server computers, mobile devices, tablet devices, etc. The transmitter 506 and the receiver 502 can include a cross-domain solution. The transmitter 506 can be a first domain of the cross-domain solution, and the receiver 502 can be a second domain of the cross-domain solution. The receiver 502 can be part of an unconnected region 508. The unconnected region 508 can be a network that is isolated from other networks. The devices in the unconnected region 508 can be configured to receive traffic from other networks, but cannot send traffic from the unconnected region 508 to other networks.

[0069] The transmitter 506 and the receiver 502 can be connected by any communication link, including a physical connection (e.g., a network cable or a fiber optic cable). The transmitter 506 and the receiver 502 can be connected wirelessly (e.g., by WiFi). The messages 504a-504c can be traffic sent between the transmitter 506 and the receiver 502. Traffic sent via UDP (including messages 508a-508c) can be sent without a handshaking dialogue. The transmitter 506 can send messages 504a-504c to the receiver 502 without a request from the receiver 502.

[0070] FIG. 6 illustrates a process for communication over User Datagram Protocol (UDP), according to one embodiment. The process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions that are stored on one or more computer-readable storage media and that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order of the described operations is not intended to be construed as limiting in any way, and any number of the described operations can be combined in any order and / or in parallel to implement the process.

[0071] Describing process 600 in more detail, in block 602, a sender 506 can initiate a UDP stream. A stream can consist of a series of packets sent from the sender 506 to the receiver 502. The sender 506 can initiate a transmission without receiving a request from the receiver 502. The receiver 502 can be configured to receive the packets sent by the sender 506. The receiver 502 can be configured not to send messages to the sender 506. A UDP stream can be a stream of messages sent in any communication protocol that can be configured for one-way communication.

[0072] In block 604, messages 508a-508c sent by the transmitter 506 are received by the receiver 502. The receiver 502 can receive messages 508a-508c without responding to the transmitter 506. The messages 508a-508c can be packets that include a source port number, a destination port number, and a checksum for error checking and security. The transmitter 506 can send messages 508a-508c in a continuous stream starting with response 1 508a without communication from the receiver 502. Once the transmitter 506 has sent the response, it can stop transmitting without receiving confirmation that the message reached the receiver 502. The transmitter 506 can be configured not to receive any messages.

[0073] FIG. 7 is a diagram 700 of a data pipeline including a software implemented cross-domain solution according to one embodiment.

[0074] Explaining diagram 700 in more detail, a smart network interface card (smart NIC) 706 includes two sets of nodes (first nodes 704a-704c and second nodes 708a-708c) as part of a data pipeline. Communication between the first nodes 704a-704b may occur using a communication protocol (e.g., UDP) configured for one-way traffic. Messages 702a-702c received at the first nodes 704a-704c may be passed on to the second nodes 708a-708c, while the first nodes 704a-704c may be configured to ignore messages sent from the second nodes 708a-708c.

[0075] In some embodiments, the smart NIC 706 may include a secure path for communication from the smart NIC 706 to the trusted repository 722. A message received at the secure first node 726 from the host machine 718 may be passed to the secure second node 728 by use of a one-way communication protocol. Once the message is received at the secure second node 728, it may be forwarded to the trusted repository 722 by use of a one-way or two-way communication protocol.

[0076] The host machine 718 may include one or more filters, including a malware filter 710, a content analyzer 714, a content filter 730, a content playback filter 732, a verifier 734, an artificial intelligence / machine learning filter 716, and a signature filter 712. The filters may be arranged in a chain through which messages received from the second nodes 708a-708c pass in sequence. The host machine 718 may be a virtual or bare metal computing device. In some circumstances, a message may pass through one or more filters before reaching the first node. One or more filters may be arranged between the first node and the second node. A message traveling from the first node to the second node may pass through one or more of these filters.

[0077] The malware filter 710 can check for malware or viruses in messages passing through the data pipeline. Messages containing malware or viruses can be rejected before reaching the disconnected network. The content filter 730 can check for prohibited words, prohibited byte sequences, file fragments, or other content prohibited by the logic of the content filter. The content filter 730 can remove prohibited content from messages before forwarding the message or can reject the message. The signature filter 712 can check messages to determine if they have a cryptographically verifiable signature that proves the origin of the message. The content analyzer 714 can analyze messages to determine the validity of the message. For example, the content analyzer 714 can check the checksums received out-of-band or in-band with the associated message. The artificial intelligence / machine learning filter 716 can be a filter that uses trained machine learning algorithms to determine if a message should be allowed to pass through the data pipeline.

[0078] In a hardware-implemented cross-domain solution, filters as included in the host machine 718 may have a fixed order that is difficult to rearrange. In a software-implemented cross-domain solution, the order of individual filters may change depending on the type of message and the message origin. Messages from trusted sources may pass through fewer filters, while messages from untrusted sources may pass through more filters. In some circumstances, the order of the filters, i.e., the list of filters in the filter chain, may change between messages.

[0079] The host machine 718 can also include a logging network 720 that provides information about events occurring in the data pipeline between the smart NIC 706 and the host machine 718. In the smart NIC 706, information can be provided to the logging network from the second nodes 708a-708c or the secure first node 726. In the host machine 718, information can be provided to the logging network about events occurring in the filters.

[0080] The logging network can be a network bus for sending logs from components to a Security Information and Event Management (SIEM) system that accepts logs of events occurring in the data pipeline at the operating system (OS) level, application level, and payload level. The SIEM system can use the logs to perform analysis, generate alerts about potential malware in the data stream, and take remedial action such as isolating problematic data.

[0081] The host machine 718 may also include a separate reverse pipeline that provides messages through the smart NIC 706 (via a secure first node 726 and a secure second node 728) to a trusted repository 722. Messages for the reverse pipeline are provided from the filter to a secure hash algorithm (SHA) validation system 724 of the host machine 718. The secure hash algorithm validation system 724 may provide messages through the smart NIC 706 to the trusted repository 722.

[0082] The separate reverse pipeline is separate from the data pipeline and can be used to help trusted systems using the trusted repository 722 learn about messages that are filtered out. Information provided by the reverse pipeline can also be used to learn about valid messages that are improperly filtered out. The trusted system can use the information about the improperly filtered out messages to improve throughput by correcting the problems that caused the improper filtering.

[0083] FIG. 8 illustrates a process for communication using a data pipeline including a software-implemented cross-domain solution, according to an embodiment. The process is illustrated as a logical flow diagram, each operation of which may be implemented in hardware, computer instructions, or a combination thereof. In the context of computer instructions, the operations may represent computer-executable instructions that are stored on one or more computer-readable storage media and that, when executed by one or more processors, perform the described operations. Generally, computer-executable instructions include routines, programs, objects, components, data structures, etc. that perform a particular function or implement a particular data type. The order of the described operations is not intended to be construed as limiting in any way, and any number of the described operations may be combined in any order and / or in parallel to implement the process.

[0084] Explaining the method 800 in more detail, at block 802, messages 702a-702c may be received from a first domain at a first node 704a-704c of a smart network interface card 706 (smart NIC). A smart NIC device may include two logical and / or physical interfaces and a processing system configured with hardware that processes data entering one of the interfaces and forwards it to the other interface. Processing the data may mean that the data is parsed, reformatted, aggregated, etc. The hardware may include a microprocessor that executes software-based algorithms invoked by the data. The messages 702a-702c are sent using a first communication protocol, and in some embodiments, the first nodes 704a-704c may be configured to receive messages sent in more than one communication protocol. In some embodiments, the first nodes 704a-704c may be configured to receive all incoming traffic.

[0085] In block 804, messages 702a-702c may be sent from the first nodes 704a-704c to the second nodes 708a-708c by a one-way communication protocol (e.g., UDP). The smart NIC 706 may provide a cross-domain solution because messages 702a-702c may be received by the first nodes 704a-704c from the first domain and forwarded from the second nodes 708a-708c to the second domain.

[0086] In some embodiments, the one-way communication protocol allows messages in the data pipeline to be sent from the first nodes 704a-704c to the second nodes 708a-708c, while no messages are sent from the second nodes 708a-708c to the first nodes 704a-704c. In some embodiments, no messages are accepted from the second nodes 708a-708c to the first nodes 704a-704c. Messages 702a-702c received at the second nodes 708a-708c as packets sent using the one-way communication protocol can be disassembled and reassembled as forwardable payloads that can be sent to destination nodes in the second domain.

[0087] Non-streaming messages received at a first node 704a-704c may be accepted, stored, and forwarded to a second node 708a-708c upon receipt of the message. Streaming messages may be intercepted at a first node 704a-704c as if the first node 704a-704c were the destination node. Streaming messages may be reconstructed into a format prescribed by a one-way communication protocol and forwarded to a second node 708a-708c. Streaming messages may be reconstructed and forwarded from a second node 708a-708c to a destination node as if the second node 708a-708c were the origin.

[0088] At block 806, as part of the data pipeline, the message may pass through a series of filters before reaching the second domain. The filters may include a malware filter 710 that checks for malware and viruses in the message, a signature filter 712 that determines if the message has a cryptographically verifiable signature that proves the origin of the message, a content analyzer 714 that determines the validity of the message, and an artificial intelligence / machine learning filter 716 that is trained to determine if the message should be allowed access to the second domain. The content filters 710-716 are hosted on a host machine 718, which may be a virtual machine or a bare metal server. The filters may be modules that may accept the message payload, reject the message payload, or convert the message payload to a different format.

[0089] In some embodiments, an application programming interface (API) may be provided to a client to allow the client to generate a data pipeline. The data pipeline may include a set of content filters that can be used to parse a message. The client may select the set of content filters via the API. As part of the generation of the data pipeline, the client may specify cross-domain solution (CDS) attributes via the API. The data pipeline may be configurable based at least in part on the specified attributes. In an additional embodiment, the client may select an order for the set of content filters through use of the API. The order of the content filters is variable and may change between messages. The client may also select multiple sets of content filters, and the set of filters for a given message may change based on an indicator of the trustworthiness of the message. For example, messages from known Internet Protocol (IP) addresses may be parsed by fewer content filters.

[0090] In some embodiments, events generated by the content filters 710-716 may be provided to a logging network 720 as part of a data pipeline. Events received on the logging network 720 may be provided by a host machine 718 as a log of events occurring in the data pipeline. The log of events may be received by a security information and event management (SIEM) system, and the log or information about the log may be provided to clients via an API.

[0091] At block 808, the message in the data pipeline may be forwarded to a destination node in the second domain. In some embodiments, after receiving the message, the client may use the API to terminate the data pipeline. In some embodiments, the client may create and terminate the data pipeline for each individual message.

[0092] In some embodiments, information about the message may be provided to the trusted repository 722 by a secure pipeline. In one embodiment, information about the message (in this case, information from the secure hash algorithm verification system 724) may be provided in a secure pipeline to a secure first node 726. The secure first node 726 may be configured as a first node 704a-704c, and a message may be sent from the secure first node 726 to a secure second node 728 by use of a one-way communication protocol. The message may be received at a secure second node 728, which may be configured as a second node 708a-708c. The message received at the secure second node 728 may be forwarded to the trusted repository 722.

[0093] 9A illustrates a user interface (UI) 900 for configuring a cloud network, according to one embodiment. A user can configure the cloud network by accessing the user interface on a computing device. The cloud network can be configured to include a cross-domain solution gateway. A user can select the cross-domain solution gateway menu by selecting the cross-domain solution gateway button 902.

[0094] FIG. 9B illustrates a user interface (UI) 901 for configuring a cross-domain solution, according to one embodiment. The cross-domain solution can be a virtual cross-domain solution. The virtual cross-domain solution can be an appliance generated via an application programming interface (API). A user can generate a cross-domain solution gateway by selecting a "Generate Cross-Domain Solution Gateway" button 904. A user can configure the gateway by using the user interface 901. For example, a user can select a direction of the cross-domain solution. A user can also select a network or sub-network that is connected by the cross-domain solution. A user can also select, through the UI, one or more filters that can scan messages received at the cross-domain system. A user can provide a filter sequence through the UI.

[0095] FIG. 10 illustrates a method for a software implemented cross-domain solution, according to an embodiment. In some embodiments, one or more process blocks of FIG. 10 may be performed by a network interface card. In some embodiments, the network interface card may be a smart network interface card (e.g., a smart NIC). In some embodiments, one or more process blocks of FIG. 10 may be performed by another device or devices that are separate from or include the network interface card.

[0096] Describing process 1000 in more detail, at block 1010, a message destined for the unconnected network and sent using a first communication protocol is received at a first node in a network interface card (NIC) associated with the unconnected network. The first node is similar to first nodes 404a-404c of Figure 4, and the message may be received from a private network or a public network such as the Internet. The first node is configurable to not receive messages sent by a second node.

[0097] At block 1020, the message is sent from the first node to the second node of the network interface card by use of a second communication protocol. The second communication protocol can be configured for unidirectional (e.g., one-way) communication. In some embodiments, the second communication protocol can be User Datagram Protocol (UDP). The second communication protocol can be any communication protocol that can be configured to allow for one-way, exclusive communication. The second node can be similar to second nodes 708a-708c described above with respect to FIG. 7.

[0098] The first node and the second node may be connected by a network cable, such as an Ethernet cable or a fiber optic cable. In some embodiments, the network cable connecting the first node and the second node does not include a diode. In some embodiments, the second communication protocol may be the same as the first communication protocol. In some embodiments, the first node and the second node are wirelessly connected. The first node and the second node may be located in separate devices.

[0099] At block 1030, the message is received at the second node. In some embodiments, the second node is configured to prevent the message from being sent from the second node to the first node. In some embodiments, the first node and the second node may be located on different devices. The first node and the second node may communicate via a wireless connection.

[0100] At block 1040, the message is sent from the second node to a destination node in the non-connected network by using a third communication protocol. In some embodiments, the non-connected network may be isolated from a public network (e.g., the Internet). In some embodiments, the non-connected network is configured to only receive messages and cannot send messages to destination nodes outside the non-connected network. In some embodiments, the non-connected network includes a virtual cloud network. In some embodiments, the message passes through a filter chain after leaving the second node before reaching the destination node. The filter chain may include one or more of a malware filter, a content filter, a signature filter, and a content analyzer. The aforementioned filters are adaptable to new malware or attacks through the use of artificial intelligence and / or machine learning (AI / ML). In some embodiments, training or test data is sent inline from the trusted source. In other embodiments, filtering is performed by uploading from the trusted source a pre-trained AI / ML model generated elsewhere. In some embodiments, the third communication protocol may be the same protocol as the first or second communication protocol.

[0101] Process 1000 may include additional embodiments, such as any single embodiment or any combination of the embodiments described below and / or in conjunction with one or more other processes described elsewhere herein.

[0102] Although Figure 10 illustrates example blocks of process 1000, in some embodiments, process 1000 may include more, fewer, different, or differently organized blocks than those illustrated in Figure 10. Additionally or alternatively, two or more of the blocks of process 1000 may be performed in parallel.

[0103] FIG. 11 illustrates a method for a Software as a Service (SaaS) based cross-domain solution, according to an embodiment. In some embodiments, one or more of the process blocks of FIG. 11 may be performed by a computing device of a virtual cloud network. In some embodiments, one or more of the process blocks of FIG. 11 may be performed by a separate device or devices that are separate from or include a network interface card.

[0104] In the selection of block 1110, a computing device of the virtual cloud network selects one or more filters from a plurality of filters for the data pipeline. The plurality of filters may include at least one of a malware filter, a content filter, a signature filter, a content analyzer, and an AI / ML, and may be exposed to the customer via an API as being updatable. The customer may send marked training (test) data through the system. In another embodiment, other sources, such as a cloud service provider, an owner of an unconnected network, a security analyst, or other trusted sources, may send learning and training data to the AI / ML system. The customer may select the source and may define criteria such as frequency, applicable filters, and / or monitoring period. The customer (e.g., a client or user) may select multiple filters for the data pipeline. In some other embodiments, the customer may pre-train an AI / ML model and send the trained model instead of the training data. In some embodiments, the virtual cloud network is a virtual machine. In some embodiments, the one or more selected filters are selected based at least in part on the source of the message. In some embodiments, multiple filters are selected for the same message source.

[0105] At block 1120, an order of the one or more selected filters in the data pipeline is determined. A customer (e.g., a client or a user) can determine the order. In some embodiments, the determined order is determined at least in part based on the origin of the message. In some embodiments, the order of the one or more selected filters is determined at least in part based on the origin of the message. The filters can include artificial intelligence and / or machine learning (AI / ML) filters. The AI / ML filters can use pre-trained artificial intelligence or machine learning models. The AI / ML filters can also use artificial intelligence or machine learning models trained with training data obtained from the non-connected network. The training data can include packet origins, characteristics of known viruses or malware, or traffic patterns of traffic received on the non-connected network. The AI / ML filters can be trained with training data that includes packets flagged by the content filter. The flagged packets can be packets identified as containing malware or viruses. The AI / ML filters can be trained to identify packets containing malware or viruses using the flagged packets.

[0106] At block 1130, a message in the data pipeline is received from a network interface card (NIC) configured as a one-way transmission device. In some embodiments, the network interface card includes a software-based one-way transmission device. The network interface card can be a single device or one or more devices.

[0107] At block 1140, messages in the data pipeline are filtered by passing the messages through one or more selected filters in a determined order. The order may vary based on the origin of the message. In some situations, the number of filters may depend on the message. Also, the order of the filters may vary between messages. Also, the number of filters may vary from message to message.

[0108] At block 1150, a log of events occurring in the data pipeline is provided via a logging network. The logs may be provided to a set of trusted repositories, but in some embodiments information from the logs may be provided to clients via an application programming interface (API).

[0109] Process 1100 may include additional embodiments, such as any single embodiment or any combination of the embodiments described below and / or in conjunction with one or more other processes described elsewhere herein.

[0110] In some embodiments, the process 1100 includes removing the one or more selected filters from the data pipeline after the message has been processed by the one or more selected filters in the determined order.

[0111] Although Figure 11 illustrates example blocks of process 1100, in some embodiments, process 1100 may include more, fewer, different, or differently organized blocks than those illustrated in Figure 11. Additionally or alternatively, two or more of the blocks of process 1100 may be performed in parallel.

[0112] Figure 12 illustrates a process 1200 for a cross-domain solution with a distributed portion, according to one embodiment. In some embodiments, one or more of the process blocks of Figure 12 may be performed by a computing device in a non-connected network. In some embodiments, one or more of the process blocks of Figure 12 may be performed by another device or devices that are separate from or include a network interface card.

[0113] In block 1210, an application programming interface (API) configured to expose a set of filter types is generated by a computing device of the non-connected network. In some embodiments, the API can be a user interface (e.g., a console), such as the user interface described above with respect to FIG. 9. The filter types can include one or more of a malware filter, a content filter, a signature filter, a content analyzer, a machine learning filter, or an artificial intelligence filter. The API can be part of a service-based cross-domain solution offering. The filters can include one or more artificial intelligence and / or machine learning (AI / ML) filters. The AI / ML filters can use pre-trained artificial intelligence and / or machine learning models. The AI / ML filters can also use artificial intelligence and / or machine learning models trained with training data obtained from the non-connected network. The training data can include packet origins, characteristics of known viruses or malware, or traffic patterns of traffic received on the non-connected network. The AI / ML filters can be trained with training data that includes packets flagged by the content filter. The flagged packets can be packets identified as containing malware or viruses. An AI / ML filter can be trained to identify packets that contain malware or viruses using the flagged packets.

[0114] In block 1220, a set of one or more filter types from a set of filter types is received via an application programming interface. The set of one or more filter types may be provided by a customer (e.g., a client or a user). The one or more filter types may be selected as part of the configuration of the cross-domain solution. The cross-domain solution is configurable via an application programming interface (API). The API may be provided to a user through a web service (e.g., cross-domain solution as a service (CDSaaS)). The API may be used to configure, create, or modify one or more cross-domain solution instances. In some embodiments, the set of filter types may change between messages. In some embodiments, the set of filter types may be based in part on the origin of the message.

[0115] At block 1230, a selected filter type order is received via the application programming interface. The filter type order or orders may be provided by a customer (e.g., a client or a user). The filter type order or orders may be selected as part of a configuration of the cross-domain solution. The cross-domain solution may be provided as a service-based cross-domain solution. In some embodiments, the filter type order may vary between messages. In some embodiments, the filter type order may be based in part on the origin of the message.

[0116] In block 1240, a data pipeline including the ordered set of filters is generated by a computing device of the non-connected network in response to a command received via the application programming interface. In some embodiments, the non-connected network can be a virtual cloud network. A customer (e.g., a client or user) can configure the virtual cloud network as part of a service-based cross-domain solution offering.

[0117] In block 1250, the non-connected network computing device analyzes the message received at the one-way transmission device by passing the message through the selected filters in the order. The one-way transmission device can be a software-based one-way transmission device. In some embodiments, the one-way transmission device can be a smart network interface card (smart NIC).

[0118] At block 1260, a log of events occurring in the data pipeline is received by a logging network of the non-connected network. The log of events may include events occurring at the operating system (OS) level, the application level, and the payload level.

[0119] At block 1270, the log of events is presented via an application programming interface.

[0120] At block 1280, the data pipeline terminates upon receiving a terminate command via the application programming interface.

[0121] Process 1200 may include additional implementations, such as any single implementation or any combination of implementations described below and / or in conjunction with one or more other processes described elsewhere herein.

[0122] In some embodiments, the process 1200 includes sending a message from an unconnected network to a trusted repository via a one-way transmission device.

[0123] Although Figure 12 illustrates example blocks of process 1200, in some embodiments, process 1200 may include more, fewer, different, or differently organized blocks than those illustrated in Figure 12. Additionally or alternatively, two or more of the blocks of process 1200 may be performed in parallel.

[0124] The term cloud service is generally used to describe services made available on demand (e.g., through a subscription model) by a cloud service provider (CSP) to a user or customer through the use of systems and infrastructure (cloud infrastructure) provided by the CSP. Typically, the servers and systems that make up the CSP's infrastructure are separate from the customer's own on-premise servers and systems. This allows the customer to use the cloud services provided by the CSP without having to purchase separate hardware and software resources for the service. Cloud services are designed to provide easy and scalable access to applications and computing resources to subscribing customers, without the customer having to invest in procuring the infrastructure used to provide the service.

[0125] There are multiple cloud service providers offering different types of cloud services. Cloud services come in a variety of different types or models, such as Software as a Service (SaaS), Platform as a Service (PaaS), and Infrastructure as a Service (IaaS).

[0126] A customer may sign up for one or more cloud services offered by a CSP. A customer may be any entity, such as an individual, an organization, or a business. When a customer signs up or subscribes to a service offered by a CSP, a tenancy or account is created for the customer. The account allows the customer to access one or more registered cloud resources that are associated with the account.

[0127] As mentioned above, Infrastructure as a Service (IaaS) is a particular type of cloud computing service. In the IaaS model, the CSP provides infrastructure (called cloud service provider infrastructure or CSPI) that customers can use to build their own customizable networks and deploy customer resources. In this way, customer resources and networks are hosted in a distributed environment by the CSP-provided infrastructure. This differs from traditional computing, where customer resources and networks are hosted by customer-provided infrastructure.

[0128] CSPI may include interconnected high performance compute resources including various host machines, memory resources, and network resources that make up a physical network, also referred to as an infrastructure network or base network. CSPI resources may be distributed across one or more data centers that may be geographically distributed across one or more geographic regions. These physical resources may run virtualization software to provide a virtualized distributed environment. Virtualization creates an overlay network (also known as a software-based network, software-defined network, or virtual network) on the physical network. The CSPI physical network is the basis for creating one or more overlay or virtual networks on the physical network. The virtual or overlay network may include one or more virtual cloud networks (VCNs). A virtual network is realized through the use of software virtualization technologies (e.g., hypervisors, functions performed by network virtualization devices (NVDs) (e.g., smart NICs), top-of-rack (TOR) switches, smart TORs that realize one or more functions performed by the NVDs, and other mechanisms) to create a network abstraction layer that may operate on the physical network. A virtual network can be in many forms including peer-to-peer networks, IP networks, etc. The virtual network is typically a Layer 3 IP network or a Layer 2 VLAN. This method of virtual or overlay networking is often referred to as virtual or overlay Layer 3 networking.Examples of protocols developed for virtual networks include IP-in-IP (or Generic Routing Encapsulation (GRE)), VXLAN-IETF RFC 7348 (Virtual Extensible LAN), VPN (Virtual Private Network) (e.g., MPLS Layer-3 Virtual Private Networks (RFC 4364)), VMware's NSX, GENEVE (Generic Network Virtualization Encapsulation), etc.

[0129] In the case of IaaS, the CSP-provided infrastructure (CSPI) can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In the IaaS model, a cloud computing service provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, the IaaS provider may also provide various services (e.g., billing, monitoring, logging, security, load balancing, clustering, etc.) that accompany these infrastructure components. Thus, these services can be policy-driven, allowing IaaS users to maintain application availability and performance through the implementation of policies that drive load balancing. CSPI provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a hosted, highly available, distributed environment. CSPI provides high-performance compute resources and capabilities, as well as storage capacity, in a flexible virtual network that can be securely accessed from various network locations, such as the customer's on-premise network. When a customer registers or subscribes to an IaaS service offered by a CSP, a tenancy is created for that customer, which is an isolated and secure partition within CSP where the customer may create, organize, and manage their cloud resources.

[0130] Customers can build their own virtual networks using compute, memory, and network resources provided by CSPI. One or more customer resources or workloads, such as compute instances, can be deployed onto these virtual networks. For example, customers can build one or more customizable private virtual networks (referred to as Virtual Cloud Networks (VCNs)) using resources provided by CSPI. Customers can deploy one or more customer resources, such as compute instances, into the customer VCNs. Compute instances can be in the form of virtual machines, bare metal instances, etc. In this way, CSPI provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a hosted, highly available virtual environment. Customers do not manage or control the underlying physical resources provided by CSPI, but do control the operating system, storage, and deployed applications. There may be limited control over some networking components (e.g., firewalls).

[0131] The CSP may provide a console that allows customers and network administrators to use CSPI resources to configure, access, and manage resources deployed in the cloud. In some embodiments, the console provides a web-based user interface that can be used to access and manage the CSPI. In some implementations, the console is a web-based application provided by the CSP.

[0132] CSPI may support single tenancy or multi-tenancy architectures. In a single tenancy architecture, software (e.g., applications, databases) or hardware components (e.g., host machines or servers) serve a single customer or tenant. In a multi-tenancy architecture, software or hardware components serve multiple customers or tenants. Thus, in a multi-tenancy architecture, CSPI resources are shared among multiple customers or tenants. In a multi-tenancy situation, precautions are taken and safeguards are implemented within CSPI to ensure that each tenant's data is isolated and not visible to other tenants.

[0133] In a physical network, a network endpoint ("endpoint") represents a computing device or system that is connected to the physical network and communicates with the connected network. A network endpoint of a physical network may be connected to a local area network (LAN), a wide area network (WAN), or other types of physical networks. Examples of traditional endpoints in a physical network include modems, hubs, bridges, switches, routers, and other networking devices, physical computers (or host machines), and the like. Each physical device of a physical network has a fixed network address that can be used to communicate with the device. This fixed network address can be a layer 2 address (e.g., a MAC address), a fixed layer 3 address (e.g., an IP address), and the like. In a virtualized environment or virtual network, the endpoints can include various virtual endpoints, such as virtual machines hosted by components of the physical network (e.g., hosted by a physical host machine). These virtual network endpoints are addressed by overlay addresses, such as overlay layer 2 addresses (e.g., an overlay MAC address) and overlay layer 3 addresses (e.g., an overlay IP address). Network overlays provide flexibility by allowing network administrators to use software management (e.g., via software implementing the virtual network's control plane) to move overlay addresses associated with network endpoints. Thus, unlike physical networks, in a virtual network, overlay addresses (e.g., overlay IP addresses) may be moved from one endpoint to another through the use of network management software. Because virtual networks are built on top of physical networks, communication between components of a virtual network involves both the virtual network and the underlying physical network.To facilitate such communications, the CSPI components are configured to learn and store mappings from overlay addresses in the virtual network to actual physical addresses in the underlying network and vice versa, and to use these mappings to facilitate communications and to facilitate routing in the virtual network by encapsulating customer traffic.

[0134] Thus, physical addresses (e.g., physical IP addresses) are associated with components of a physical network, and overlay addresses (e.g., overlay IP addresses) are associated with entities of a virtual network. Both physical and overlay IP addresses are types of real IP addresses. They are distinct from virtual IP addresses, which are mapped to multiple real IP addresses. A virtual IP address provides a one-to-many mapping between the virtual IP address and multiple real IP addresses.

[0135] The cloud infrastructure or CSPI is physically hosted in one or more data centers in one or more regions around the world. The CSPI may include physical or infrastructure network components as well as virtualized components (e.g., virtual networks, compute instances, virtual machines, etc.) in a virtual network built on the physical network components. In one embodiment, the CSPI is organized and hosted in realms, regions, and availability domains. A region is a local geographic area that typically includes one or more data centers. Regions are generally independent of each other and may be separated by large distances, e.g., across countries or continents. For example, a first region may be in Australia, another region in Japan, and yet another region in India. CSPI resources are divided between regions such that each region has its own independent subset of CSPI resources. Each region may provide a set of core infrastructure services and resources, such as compute resources (e.g., bare metal servers, virtual machines, containers, and related infrastructure), storage resources (e.g., block volume storage, file storage, object storage, archival storage), networking resources (e.g., virtual cloud networks (VCNs), load balancing resources, connections to on-premises networks), database resources, edge networking resources (e.g., DNS), and access management and monitoring resources. Each region typically has multiple paths connecting it to other regions in the realm.

[0136] Typically, applications are deployed (i.e., deployed to the infrastructure associated with) the region where they are most heavily used because using nearby resources is faster than using resources that are farther away. Applications may also be deployed to different regions for a variety of reasons, such as redundancy to reduce the risk of a region-wide event, such as a large weather system or earthquake, or to meet various requirements, such as jurisdictions, tax areas, and other business or societal standards.

[0137] Datacenters within a region may be further organized and subdivided into availability domains (ADs). An availability domain may correspond to one or more datacenters located within a region. A region may be composed of one or more availability domains. In such a distributed environment, CSPI resources are region-specific, such as a virtual cloud network (VCN), or availability domain-specific, such as a compute instance.

[0138] ADs in a region are isolated from each other, fault-tolerant, and configured to have a very low probability of simultaneous failure. This is achieved by ADs not sharing critical infrastructure resources such as networks, physical cables, cable paths, and cable entry points. Therefore, a failure in one AD in a region is unlikely to affect the availability of other ADs in the same region. ADs in the same region can be connected to each other by low-latency, high-bandwidth networks, allowing for highly available connections to other networks (e.g., the Internet, customer on-premise networks, etc.), and replica systems can be built in multiple ADs for both high availability and disaster recovery. Cloud services use multiple ADs to ensure high availability and to protect against resource failures. As the infrastructure offered by an IaaS provider grows, capacity can be added to more regions and ADs. Traffic between availability domains is also typically encrypted.

[0139] In one embodiment, regions are grouped into realms. A realm is a logical collection of regions. Realms are isolated from each other and do not share any data. Regions in the same realm can communicate with each other, but regions in different realms cannot. A customer's tenancy or account using a CSP exists in a single realm and can be distributed across one or more regions that belong to that realm. Typically, when a customer signs up for an IaaS service, a tenancy or account for that customer is created in a customer-specific region (called the "home" region) within a realm. A customer can extend their tenancy across one or more other regions within the realm. A customer cannot access regions that are not in the realm in which the customer's tenancy exists.

[0140] An IaaS provider can offer multiple realms, each corresponding to a particular set of customers or users. For example, a commercial realm may be offered for commercial customers. As another example, for a particular country, a realm may be offered for customers within that country. As yet another example, for a government, a government realm may be offered, and so on. For example, the government realm may cater to a particular government and provide a higher level of security than the commercial realm. For example, OCI (Oracle Cloud Infrastructure) currently offers one realm for commercial regions and two realms for government cloud regions (e.g., FedRAMP and IL5 certified).

[0141] In one embodiment, an AD may be subdivided into one or more fault domains. A fault domain is a group of infrastructure resources within an AD that provides anti-affinity. Fault domains can distribute compute instances so that they are not on the same physical hardware within a single AD. This is known as anti-affinity. A fault domain represents a set of hardware components (computers, switches, etc.) that share a single point of failure. A compute pool is logically divided into fault domains. Thus, a hardware failure or compute hardware maintenance event that affects one fault domain does not affect instances in other fault domains. Depending on the embodiment, the number of fault domains per AD may vary. For example, in one embodiment, each AD includes three fault domains. Fault domains act as logical data centers within an AD.

[0142] When a customer subscribes to an IaaS service, resources from CSPI are provisioned for the customer and associated with the customer's tenancy. The customer can use these provisioned resources to build private networks and deploy resources on these networks. A customer network hosted in the cloud by CSPI is called a Virtual Cloud Network (VCN). A customer can set up one or more Virtual Cloud Networks (VCNs) using the allocated CSPI resources. A VCN is a virtual or software-defined private network. The customer resources deployed in a customer's VCN can include compute instances (e.g., virtual machines, bare metal instances) and other resources. These compute instances can represent various customer workloads such as applications, load balancers, databases, etc. Compute instances deployed in a VCN can communicate with public endpoints ("public endpoints") accessible over a public network such as the Internet, other instances in the same VCN or other VCNs (e.g., other VCNs of the customer or VCNs not belonging to the customer), the customer's on-premise data center or network, and service endpoints and other types of endpoints.

[0143] CSPs can use CSPI to provide various services. In some cases, CSPI customers themselves can act as service providers and provide services using CSPI resources. Service providers can expose service endpoints characterized by identifying information (e.g., IP addresses, DNS names, and ports). Customer resources (e.g., compute instances) can consume a particular service by accessing the service endpoints that the service exposes for that service. These service endpoints are generally publicly accessible by users over a public communications network, such as the Internet, using a public IP address associated with the endpoint. Publicly accessible network endpoints may also be referred to as public endpoints.

[0144] In some embodiments, a service provider may expose a service through a service endpoint (sometimes referred to as a service endpoint). A customer of the service may then access the service using the service endpoint. In some embodiments, a given service endpoint for a service may be accessible by multiple customers intending to consume the service. In other embodiments, a customer may be given a dedicated service endpoint such that only that customer may access the service using the dedicated service endpoint.

[0145] In one embodiment, when a VCN is created, it is associated with a private overlay Classless Inter-Domain Routing (CIDR) address space that is a broad private overlay IP address that is assigned to the VCN (e.g., 10.0 / 16). A VCN includes associated subnets, route tables, and gateways. A VCN exists within a single region but may span one, more, or all availability domains in the region. A gateway is a virtual interface configured for a VCN that allows traffic to communicate between the VCN and one or more endpoints outside the VCN. One or more different types of gateways may be configured for a VCN to allow communication between different types of endpoints.

[0146] A VCN may be subdivided into one or more subnetworks, such as one or more subnets. A subnet is thus a configuration unit or subdivision that may be created within a VCN. A VCN may have one or more subnets. Each subnet in a VCN is associated with a contiguous range of overlay IP addresses that do not overlap with other subnets in that VCN and that represent a subset of address space within the VCN's address space (e.g., 10.0.0.0 / 24 and 10.0.1.0 / 24).

[0147] Each compute instance is associated with a virtual network interface card (VNIC) that allows the compute instance to participate in a subnet of a VCN. A VNIC is a logical representation of a physical network interface card (NIC). In general, a VNIC is an interface between an entity (e.g., a compute instance, a service) and a virtual network. A VNIC resides in a subnet and has one or more associated IP addresses and associated security rules or policies. A VNIC corresponds to a layer 2 port on a switch. A VNIC is attached to a compute instance and a subnet in a VCN. A VNIC associated with a compute instance allows the compute instance to be part of a subnet of a VCN and allows the compute instance to communicate (e.g., send and receive packets) with endpoints on the same subnet as the compute instance, endpoints in a different subnet of the VCN, or endpoints outside the VCN. Thus, a VNIC associated with a compute instance determines how the compute instance is connected to endpoints inside and outside the VCN. A VNIC for a compute instance is created and associated with the compute instance when the compute instance is created and added to a subnet in a VCN. For a subnet that contains a set of compute instances, the subnet contains VNICs corresponding to the set of compute instances, and each VNIC is associated with a compute instance in the set of compute instances.

[0148] Each compute instance is assigned a private overlay IP address through the VNIC associated with the compute instance. When a compute instance is created, the private overlay IP address is assigned to the VNIC associated with the compute instance and is used to route traffic to the compute instance. For a given subnet, all VNICs use the same route table, security list, and DHCP options. As described above, each subnet in a VCN is associated with a contiguous range of overlay IP addresses that do not overlap with other subnets in the VCN and that represent a subset of address space within the VCN's address space (e.g., 10.0.0.0 / 24 and 10.0.1.0 / 24). For a VNIC on a particular subnet of a VCN, the private overlay IP address assigned to the VNIC is an address from the contiguous range of overlay IP addresses assigned to the subnet.

[0149] In one embodiment, a compute instance may be assigned a private overlay IP address, as well as optional additional overlay IP addresses, such as one or more public IP addresses in the case of a public subnet. These addresses are assigned to the same VNIC or VNICs associated with the compute instance. However, each instance has a primary VNIC that is created at instance launch time and associated with an overlay private IP address assigned to the instance (this primary VNIC cannot be deleted). Additional VNICs, called secondary VNICs, can be added to an existing instance in the same availability domain as the primary VNIC. All VNICs are in the same availability domain as the instance. The secondary VNICs can be in the same subnetwork as the primary VNIC, or in a different subnetwork in the same or a different VCN.

[0150] If a compute instance resides in a public subnet, it may optionally be assigned a public IP address. A subnet may be designated as a public or private subnet at the time of creation. A private subnet means that resources in the subnet (e.g., compute instances) and associated VNICs may not have public overlay IP addresses. A public subnet means that resources in the subnet and associated VNICs may have public IP addresses. Customers can specify a subnet to reside in a single availability domain or multiple availability domains of a region or realm.

[0151] As mentioned above, a VCN may be subdivided into one or more subnets. In one embodiment, a virtual router (VR) (referred to as VCN VR or simply VR) configured for a VCN allows communication between subnets of the VCN. For a subnet in a VCN, the VR represents a logical gateway for the subnet that allows that subnet (i.e., compute instances on that subnet) to communicate with endpoints on other subnets in the VCN and with other endpoints outside the VCN. A VCN VR is a logical entity that is configured to route traffic between VNICs in a VCN and a virtual gateway ("gateway") associated with the VCN. Gateways are discussed separately below with respect to FIG. 1. A VCN VR is a layer 3 / IP layer concept. In one embodiment, there is one VCN VR for a VCN, which potentially has a limited number of ports that are addressed by IP addresses, one port for each subnet of the VCN. Thus, a VCN VR has a different IP address for each subnet of the VCN to which the VCN VR is attached. The VRs are also connected to the various gateways configured for the VCN. In one embodiment, a particular overlay IP address in an overlay IP address range for a subnet is reserved for a port in the VCN VR for that subnet. For example, a VCN has two subnets, each with associated address ranges 10.0 / 16 and 10.1 / 16. For a first subnet in a VCN with address range 10.0 / 16, an address in this range is reserved for a port in the VCN VR for that subnet. In some cases, the first IP address in the range may be reserved for a VCN VR. For example, for a subnet with overlay IP address range 10.0 / 16, IP address 10.0.0.1 may be reserved for a port in the VCN VR for that subnet. For a second subnet in the same VCN with address range 10.1 / 16, the VCN VR may have a port with IP address 10.1.0.1 for the second subnet.A VCN VR has a different IP address for each of the VCN's subnets.

[0152] In some other embodiments, each subnet in a VCN may have its own associated VR, which is addressable by the subnet through use of a reserved or default IP address associated with the VR. The reserved or default IP address may be, for example, the first IP address in a range of IP addresses associated with the subnet. VNICs in a subnet can communicate (e.g., send and receive packets) with the VR associated with the subnet using the default or reserved IP address. In such embodiments, the VR is the ingress / egress point for the subnet. VRs associated with a subnet in a VCN can communicate with other VRs associated with other subnets in the VCN. The VRs can also communicate with gateways associated with the VCN. The VR functions of a subnet are running on or performed by one or more NVDs that perform the VNIC functions of the VNICs in the subnet.

[0153] A VCN may be configured with route tables, security rules, and DHCP options. A route table is a virtual route table for a VCN and contains rules that route traffic from subnets within the VCN to destinations outside the VCN via gateways or specially configured instances. A VCN's route table can be customized to control how packets are forwarded / routed to the VCN. DHCP options represent configuration information that is automatically given to an instance when it is launched.

[0154] Security rules configured for a VCN represent the overlay firewall rules for the VCN. Security rules can include ingress and egress rules and specify the type of traffic (e.g., based on protocol and port) that can enter and leave instances in the VCN. Customers can choose whether a given rule is stateful or stateless. For example, a customer can allow ingress SSH traffic from anywhere to a set of instances by configuring a stateful ingress rule with source CIDR 0.0.0.0 / 0 and destination TCP port 22. Security rules can be implemented using network security groups or security lists. A network security group consists of a set of security rules that apply only to the resources in that group. A security list, on the other hand, contains rules that apply to all resources in any subnet that uses the security list. A VCN can be provided with a default security list that contains default security rules. DHCP options configured for a VCN provide configuration information that is automatically given to instances in the VCN when they are launched.

[0155] In one embodiment, configuration information for a VCN is determined and stored by a VCN control plane. The configuration information for a VCN may include, for example, information about address ranges associated with the VCN, subnets and related information within the VCN, one or more VRs associated with the VCN, compute instances and associated VNICs in the VCN, NVDs performing various virtualized network functions (e.g., VNICs, VRs, gateways) associated with the VCN, state information for the VCN, and other VCN-related information. In one embodiment, a VCN distribution service publishes the configuration information stored by the VCN control plane or a portion thereof to the NVD. The distributed information may be stored by the NVD and used to update information (e.g., forwarding tables, routing tables, etc.) used to forward packets to compute instances in the VCN.

[0156] In one embodiment, the creation of VCNs and subnets is handled by a VCN control plane (CP), and the launch of compute instances is handled by the compute control plane. The compute control plane is responsible for allocating physical resources for the compute instances, and then calls the VCN control plane to create and attach VNICs to the compute instances. The VCN CP also sends VCN data mappings to a VCN data plane that is configured to perform packet forwarding and routing functions. In one embodiment, the VCN VP provides a distribution service that is responsible for providing updates to the VCN data plane. Examples of the VCN control plane are also shown in Figures 18, 19, 20, and 21 (see reference numbers 1816, 1916, 2016, and 2116) and described below.

[0157] Customers can create one or more VCNs using CSPI-hosted resources. Compute instances deployed in a Customer VCN can communicate with various endpoints. These endpoints can include CSPI-hosted endpoints and endpoints external to CSPI.

[0158] Various architectures for implementing cloud-based services using CSPI are shown in Figures 13, 14, 15, 16, 17, 18, 19, 20, and 22 and described below. Figure 13 is a high-level diagram of a distributed environment 1300 showing an overlay or customer VCN hosted by CSPI, according to an embodiment. The distributed environment shown in Figure 13 includes multiple components of an overlay network. The distributed environment 1300 shown in Figure 13 is only an example and is not intended to unduly limit the scope of the claimed embodiments. Many variations, alternatives, and modifications are possible. For example, in some implementations, the distributed environment shown in Figure 13 may include more or fewer systems or components than those shown in Figure 1, may combine two or more systems, or may have different configurations or arrangements of systems.

[0159] As shown in the example of FIG. 13, the distributed environment 1300 includes a CSPI 1301 that provides services and resources that customers can use to sign up and build their virtual cloud networks (VCNs). In one embodiment, the CSPI 1301 provides IaaS services to its customers. Data centers in the CSPI 1301 may be organized as one or more regions. One exemplary region, “Region US” 1302, is shown in FIG. 13. The customer has configured a customer VCN 1304 for the region 1302. The customer may deploy various compute instances into the VCN 1304, which may include virtual machines or bare metal instances. Examples of instances include applications, databases, load balancers, etc.

[0160] In the embodiment shown in FIG. 13, customer VCN 1304 includes two subnets, "Subnet 1" and "Subnet 2," each with its own CIDR IP address range. In FIG. 13, the overlay IP address range of Subnet 1 is 16.0 / 16, and the address range of Subnet 2 is 16.1 / 16. VCN virtual router 1305 represents the logical gateway of the VCN that allows communication between the subnets of VCN 1304 and with other endpoints outside the VCN. VCN VR 1305 is configured to route traffic between VNICs in VCN 1304 and the gateway associated with VCN 1304. VCN VR 1305 provides a port to each subnet of VCN 1304. For example, VR 1305 may provide a port with IP address 10.0.0.1 to Subnet 1 and a port with IP address 10.1.0.1 to Subnet 2.

[0161] Multiple compute instances may be deployed in each subnet, and the compute instances may be virtual machine instances and / or bare metal instances. The compute instances in a subnet may be hosted by one or more host machines in CSPI1301. A compute instance joins a subnet via a VNIC associated with the compute instance. For example, as shown in FIG. 13, a compute instance C1 is part of subnet 1 via a VNIC associated with the compute instance. Similarly, a compute instance C2 is part of subnet 1 via a VNIC associated with C2. Similarly, multiple compute instances (which may be virtual machine instances or bare metal instances) may be part of subnet 1. Each compute instance is assigned a private overlay IP address and a MAC address via its associated VNIC. 13, compute instance C1 has an overlay IP address of 10.0.0.2 and a MAC address of M1, while compute instance C2 has a private overlay IP address of 10.0.0.3 and a MAC address of M2. Each compute instance in Subnet 1 (including compute instances C1 and C2) has a default route to VCN VR 6 1305 using IP address 10.0.0.1, which is the IP address of a port in VCN VR 6 1305 for Subnet 1.

[0162] Subnet 2 may have multiple compute instances deployed, including virtual machine instances and / or bare metal instances. For example, as shown in FIG. 13, compute instances D1 and D2 are part of subnet 2 via a VNIC associated with each of the compute instances. In the embodiment shown in FIG. 13, compute instance D1 has an overlay IP address of 10.1.0.2 and a MAC address of MM1, while compute instance D2 has a private overlay IP address of 10.1.0.3 and a MAC address of MM2. Each compute instance in subnet 2 (including compute instances D1 and D2) has a default route to VCN VR 6 1305 using IP address 10.1.0.1, which is the IP address of a port in VCN VR 1305 for subnet 2.

[0163] VCN A 1304 may also include one or more load balancers. For example, a load balancer may be provided for a subnet and configured to load balance traffic among multiple compute instances on the subnet. A load balancer may also be provided to load balance traffic among subnets of the VCN.

[0164] A particular compute instance deployed in VCN 1304 can communicate with a variety of different endpoints. These endpoints can include endpoints hosted by CSPI 1600 and endpoints outside of CSPI 1600. Endpoints hosted by CSPI 1301 can include endpoints on the same subnet as the particular compute instance (e.g., communication between two compute instances in subnet 1), endpoints on different subnets in the same VCN (e.g., communication between a compute instance in subnet 1 and a compute instance in subnet 2), endpoints in different VCNs in the same region (e.g., communication between a compute instance in subnet 1 and an endpoint in a VCN in the same region 1306 or 1310, communication between a compute instance in subnet 1 and an endpoint in a service network 1310 in the same region), or endpoints in a VCN in a different region (e.g., communication between a compute instance in subnet 1 and an endpoint in a VCN in a different region 1308). Additionally, compute instances in a subnet hosted by CSPI 1301 may communicate with endpoints not hosted by CSPI 1301 (i.e., external to CSPI 1301). These external endpoints include endpoints in a customer's on-premise network 1316, endpoints in other hosted remote cloud networks 1318, public endpoints 1314 accessible via a public network such as the Internet, and other endpoints.

[0165] Communication between compute instances on the same subnet is facilitated through the use of VNICs associated with the source and destination compute instances. For example, compute instance C1 on Subnet 1 may want to send a packet to compute instance C2 on Subnet 1. For a packet originating from the source compute instance and destined for another compute instance in the same subnet, the packet is first processed by the VNIC associated with the source compute instance. The processing performed by the VNIC associated with the source compute instance may include determining the packet's destination information from the packet header, identifying any policies (e.g., security lists) configured on the VNIC associated with the source compute instance, determining the next hop for the packet, performing encapsulation / decapsulation functions on the packet as necessary, and forwarding / routing the packet to the next hop to facilitate communication of the packet to its intended destination. If the destination compute instance is in the same subnet as the source compute instance, the VNIC associated with the source compute instance is configured to identify the VNIC associated with the destination compute instance and forward the packet to that VNIC for processing, and then forward the packet to the destination compute instance by running the VNIC associated with the destination compute instance.

[0166] When a packet is sent from a compute instance in one subnet to an endpoint in a different subnet of the same VCN, the communication is facilitated by the VNICs associated with the source and destination compute instances and the VCN VRs. For example, if compute instance C1 in subnet 1 in FIG. 13 wants to send a packet to compute instance D1 in subnet 2, the packet is first processed by the VNIC associated with compute instance C1. The VNIC associated with compute instance C1 is configured to route the packet to VCN VR using a default route or port 10.0.0.1 of VCN VR1305. VCN VR1305 is configured to route the packet to subnet 2 using port 10.1.0.1. Once the packet is received and processed by the VNIC associated with D1, the VNIC forwards the packet to compute instance D1.

[0167] When a packet is sent from a compute instance in VCN 1304 to an endpoint outside VCN 1304, the communication is facilitated by the VNIC associated with the source compute instance, VCN VR 1305, and a gateway associated with VCN 1304. One or more types of gateways may be associated with VCN 1304. A gateway is an interface between a VCN and another endpoint outside the VCN. A gateway is a Layer 3 / IP layer concept that allows a VCN to communicate with endpoints outside the VCN. In this way, a gateway facilitates the flow of traffic between a VCN and other VCNs or networks. A variety of different types of gateways may be configured for a VCN to facilitate different types of communication with different types of endpoints. The communication may be over a public network (e.g., the Internet) or a private network, depending on the gateway. A variety of communication protocols may be used for these communications.

[0168] For example, compute instance C1 may want to communicate with an endpoint outside VCN 1304. The packet may first be processed by a VNIC associated with source compute instance C1. The VNIC processing determines that the packet's destination is outside of Subnet 1 of C1. The VNIC associated with C1 may forward the packet to VCN VR 1305 in VCN 1304. VCN VR 1305 then processes the packet and, as part of that processing, determines a particular gateway associated with VCN 1304 as the next hop for the packet based on the packet's destination. VCN VR 1305 may then forward the packet to the particular gateway identified. For example, if the destination is an endpoint in a customer's on-premise network, the packet may be forwarded by VCN VR 1305 to a Dynamic Routing Gateway (DRG) gateway 1322 configured for VCN 1304. Forwarding of the packet from the gateway to the next hop can then facilitate delivery of the packet to its ultimate intended destination.

[0169] A variety of different types of gateways may be configured for a VCN. Examples of gateways that may be configured for a VCN are shown in FIG. 13 and described below. Examples of gateways associated with a VCN are also shown in FIG. 18, FIG. 19, FIG. 20, and FIG. 21 (e.g., gateways referenced by reference numbers 1834, 1836, 1838, 1934, 1936, 1938, 2034, 2036, 2038, 2134, 2136, and 2138) and described below. As shown in the embodiment of FIG. 13, a dynamic routing gateway (DRG) 1322 may be added or associated with the customer VCN 1304 to provide a path for private network traffic communication between the customer VCN 1304 and another endpoint, which may be the customer's on-premise network 1316, a VCN 1308 in a different region of CSPI 1301, or another remote cloud network 1318 not hosted by CSPI 1301. The customer on-premise network 1316 may be a customer network built using customer resources or may be a customer data center. Access to the customer on-premise network 1316 is generally highly restricted. When a customer has both the on-premise network 1316 and one or more VCNs 1304 deployed or hosted in the cloud by CSPI 1301, they may want the on-premise network 1316 and the cloud-based VCN 1304 to be able to communicate with each other. This allows the customer to build an extended hybrid environment that includes the customer's VCN 1304 and the on-premise network 1316 hosted by CSPI 1301. This communication is made possible by the DRG 1322. To make such communication possible, a communication channel 1324 is set up such that one endpoint of the channel is in the customer on-premise network 1316 and the other endpoint is in CSPI 1301 and connected to the customer VCN 1304. The communication channel 1324 may be via a public communication network such as the Internet or a private communication network.A variety of different communication protocols may be used, such as IPsec VPN technology over a public communication network such as the Internet, Oracle's FastConnect technology using a private network instead of a public network, etc. The device or equipment in the customer on-premise network 1316 that constitutes one end point of the communication channel 1324 is referred to as customer premises equipment (CPE), such as CPE 1326 shown in Figure 13. On the CSPI 1301 side, the end point may be a host machine running DRG 1322.

[0170] In one embodiment, remote peering connections (RPCs) can be added to a DRG, allowing a customer to peer one VCN with another VCN in a different region. Using such RPCs, a customer VCN 1304 can connect to a VCN 1308 in another region using a DRG 1322. The DRG 1322 can also be used to communicate with other remote cloud networks 1318 not hosted by CSPI 1301, such as Microsoft Azure cloud, Amazon AWS cloud, etc.

[0171] As shown in Figure 13, an Internet Gateway (IGW) 1320 may be configured for a customer VCN 1304 such that compute instances on the VCN 1304 can communicate with public endpoints 1314 accessible over a public network, such as the Internet. The IGW 1320 is a gateway that connects a VCN to a public network, such as the Internet. The IGW 1320 allows a public subnet in a VCN, such as VCN 1304, to directly access a public endpoint 1312 on a public network 1314, such as the Internet, if the resources in that public subnet have public overlay IP addresses. Using the IGW 1320, connections can be initiated from a subnet in the VCN 1304 or from the Internet.

[0172] A network address translation (NAT) gateway 1328 may be configured for a customer's VCN 1304 to allow cloud resources in the customer's VCN that do not have dedicated public overlay IP addresses to access the Internet, without exposing these resources to a direct inbound Internet connection (e.g., L4-L7 connection). This allows private subnets in the VCN (such as private subnet 1 of VCN 1304) to privately access public endpoints on the Internet. A NAT gateway only allows connections to be initiated from the private subnet to the public Internet, not from the Internet to the private subnet.

[0173] In one embodiment, a service gateway (SGW) 1326 may be configured for the customer VCN 1304, which provides a path for private network traffic between the VCN 1304 and service endpoints supported in the service network 1310. In one embodiment, the service network 1310 may be provided by a CSP and may provide a variety of services. One example of such a service network is Oracle's Services Network, which provides a variety of services that customers can use. For example, a compute instance (e.g., a database system) in a private subnet of the customer VCN 1304 can back up data to a service endpoint (e.g., Object Storage) without needing a public IP address or access to the Internet. In one embodiment, a VCN may have only one SGW, and connections may only be initiated from subnets within the VCN, not from the service network 1310. When a VCN is peered with another VCN, resources in the other VCN typically do not have access to the SGW. Also, resources in an on-premise network connected to a VCN with FastConnect or VPN Connect can use a service gateway configured for that VCN.

[0174] In one embodiment, the SGW 1326 uses the concept of a Service Classless Inter-Domain Routing (CIDR) label, which is a string that represents all of the regional public IP address ranges for a service or services of interest. A customer uses the service CIDR label when configuring the SGW and associated routing rules to control traffic to the service. A customer can optionally use the label when configuring security rules without the need for adjustments, even if the service's public IP address changes in the future.

[0175] A local peering gateway (LPG) 1332 is a gateway that can be added to a customer VCN 1304 to allow the VCN 1304 to peer with another VCN in the same region. Peering means that the VCNs communicate using private IP addresses, but without traffic traversing a public network such as the Internet or routing traffic to the customer's on-premises network 1316. In a preferred embodiment, a VCN has a separate LPG for each peering it establishes. Local peering or VCN peering is a common method used to establish network connections between different applications or infrastructure management functions.

[0176] A service provider (such as a provider of services in service network 1310) can provide access to services using various access models. According to a public access model, the service may be exposed as a public endpoint publicly accessible by a compute instance in the customer VCN over a public network such as the Internet, and / or may be privately accessible through SGW 1326. According to a specific private access model, the service is accessible as a private IP endpoint in a private subnet of the customer's VCN. This is called private endpoint (PE) access, and the service provider can expose each service as an instance in the customer's private network. A private endpoint resource represents a service in the customer's VCN. Each PE is seen as a VNIC in a customer-selected subnet in the customer's VCN (called a PE-VNIC and has one or more private IPs). Thus, the PE provides a way to expose services in a private customer VCN subnet using a VNIC. Because the endpoints are exposed as VNICs, all the functionality associated with a VNIC, such as routing rules, security lists, etc., is available to the PE VNIC.

[0177] Service providers may enable access through PEs by registering their respective services. Providers can associate policies with services that restrict the visibility of the service to the customer tenancy. Providers can register multiple services under a single virtual IP address (VIP), especially for multi-tenant services. There may be multiple such private endpoints (in multiple VCNs) representing the same service.

[0178] A compute instance in the private subnet can then access the service using the private IP address of the PE VNIC or the service DNS name. A compute instance in the customer VCN can access the service by sending traffic to the private IP address of the PE in the customer VCN. A private access gateway (PAGW) 1330 is a gateway resource that can be attached to a service provider VCN (e.g., a VCN in service network 1310) that acts as an ingress / egress point for all traffic to customer subnet private endpoints. The PAGW 1330 allows a provider to scale the number of PE connections without using its internal IP address resources. A provider only needs to configure one PAGW for any number of services registered in a single VCN. A provider can represent services as private endpoints in multiple VCNs for one or more customers. From the customer's perspective, the PE VNIC does not appear to be attached to a customer's instance, but rather to the service the customer wants to interact with. Traffic destined for the private endpoint is routed to the service through the PAGW 1330. These are called Customer-to-Service Private Connections (C2S Connections).

[0179] The use of the PE concept also allows traffic to flow across FastConnect / IPsec links and private endpoints in the customer VCN, extending private access of services to the customer's on-premise networks and datacenters, and allows traffic to flow between LPG1332 and PEs in the customer VCN, extending private access of services to the customer's peering VCN.

[0180] Customers can control VCN routing at the subnet level, allowing them to specify which subnets in the customer's VCN (such as VCN 1304) use each gateway. The VCN's route table is used to determine which traffic is allowed from the VCN through a particular gateway. For example, in a particular instance, the route table for a public subnet in customer VCN 1304 may send non-local traffic through IGW 1320. The route table for a private subnet in the same customer VCN 1304 may send traffic destined for CSP services through SGW 1326. All other traffic may be sent through NAT gateway 1328. The route table only controls traffic leaving the VCN.

[0181] The security lists associated with the VCN are used to control traffic that enters the VCN through the gateway via an inbound connection. All resources in a subnet use the same route table and security lists. Security lists can be used to control the specific types of traffic that can enter and leave instances in a subnet of a VCN. Security list rules can include input (inbound) and output (outbound) rules. For example, an input rule can specify an allowed source address range, while an output rule can specify an allowed destination address range. Security rules can specify a particular protocol (e.g., TCP, ICMP), a particular port (e.g., 22 for SSH, 3389 for Windows RDP), etc. In some implementations, the instance's operating system can enforce its own firewall rules aligned with the security list rules. Rules can be stateful (e.g., connections are tracked and responses are automatically allowed without an explicit security list rule for the response traffic) or stateless.

[0182] Access from a customer VCN (i.e., by resources or compute instances deployed in VCN 1304) can be categorized as public access, private access, or dedicated access. Public access represents an access model in which public IP addresses or NATs are used to access public endpoints. Private access allows customer workloads (e.g., resources in a private subnet) in VCN 1304 with private IP addresses to access services without traversing a public network such as the Internet. In one embodiment, CSPI 1301 enables customer VCN workloads with private IP addresses to access (public service endpoints of) services using a service gateway. Thus, the service gateway provides a private access model by establishing a virtual link between the customer's VCN and the public endpoints of the services that reside outside the customer's private network.

[0183] CSPI may also provide dedicated public access by using technologies such as FastConnect public peering, where customer on-premises instances may use a FastConnect connection to access one or more services in the customer VCN without traversing a public network such as the Internet. CSPI may also provide dedicated private access by using FastConnect private peering, where customer on-premises instances with private IP addresses may use a FastConnect connection to access customer VCN workloads. FastConnect is an alternative network connection to connect a customer on-premises network to CSPI and its services using the public Internet. FastConnect provides an easy, flexible, and economical way to create a dedicated private connection with higher bandwidth options, higher reliability, and a consistent networking experience compared to Internet-based connections.

[0184] FIG. 13 and the accompanying description above describe various virtualized components in an exemplary virtual network. As mentioned above, a virtual network is built on an underlying physical or infrastructure network. FIG. 14 is a simplified architecture diagram of physical components in a physical network in a CSPI 1400 that is the basis of a virtual network, according to an embodiment. As shown, CSPI 1400 provides a distributed environment including components and resources (e.g., compute, memory, and network resources) provided by a cloud service provider (CSP). These components and resources are used to provide cloud services (e.g., IaaS services) to subscribing customers, i.e., customers who have signed up for one or more services provided by the CSP. Customers are provisioned with a subset of resources (e.g., compute, memory, and network resources) of CSPI 1400 based on the services for which they have signed up. Customers can then use the physical compute, memory, and network resources provided by CSPI 1400 to build their own cloud-based (i.e., CSPI-hosted) customizable private virtual networks. As mentioned above, these customer networks are referred to as Virtual Cloud Networks (VCNs). Customers can deploy one or more customer resources, such as compute instances, into these customer VCNs. The compute instances can be in the form of virtual machines, bare metal instances, etc. CSPI 1400 provides infrastructure and a set of complementary cloud services that enable customers to build and run a wide range of applications and services in a hosted, highly available environment.

[0185] In the exemplary embodiment shown in FIG. 14, the physical components of CSPI 1400 include one or more physical host machines or servers (e.g., 1402, 1406, 1408), network virtualization devices (NVDs) (e.g., 1410, 1412), top-of-rack (TOR) switches (e.g., 1414, 1416), and physical networks (e.g., 1418) and switches of physical networks 1418. The physical host machines or servers can host and run various compute instances that participate in one or more subnets of the VCN. The compute instances can include virtual machine instances and bare metal instances. For example, the various compute instances shown in FIG. 13 may be hosted by the physical host machines shown in FIG. 14. The virtual machine compute instances in the VCN may be run by one host machine or by multiple different host machines. The physical host machines can also host virtual host machines, container-based hosts or functions, and the like. The VNICs and VCN VRs shown in Figure 13 may be implemented by the NVD shown in Figure 14. The gateways shown in Figure 13 may be implemented by the host machines and / or NVDs shown in Figure 14.

[0186] A host machine or server may run a hypervisor (also referred to as a virtual machine monitor or VMM) that creates and makes available a virtualized environment on the host machine. Virtualization or a virtualized environment facilitates cloud-based computing. The hypervisor on a host machine may allow one or more compute instances to be created, executed, and managed on the host machine. The hypervisor on a host machine enables sharing of the host machine's physical computing resources (e.g., compute, memory, and network resources) among the various compute instances that the host machine runs.

[0187] For example, as shown in FIG. 14, host machines 1402 and 1408 execute hypervisors 1460 and 1466, respectively. These hypervisors may be implemented in software, firmware, hardware, or a combination thereof. Typically, a hypervisor is a process or software layer that resides on the operating system (OS) of a host machine and executes on the hardware processor of the host machine. A hypervisor provides a virtualized environment by enabling sharing of the host machine's physical computing resources (e.g., processing resources such as processors / cores, memory resources, networking resources, etc.) among various virtual machine compute instances that the host machine executes. For example, in FIG. 14, hypervisor 1460 may reside on the OS of host machine 1402 and enable sharing of the host machine's computing resources (e.g., processing, memory, and networking resources) among the compute instances (e.g., virtual machines) that the host machine 1402 executes. A virtual machine may have its own operating system (referred to as a guest operating system), which may be the same as or different from the host machine's OS. The operating system of a virtual machine executed by a host machine may be the same as or different from the operating system of another virtual machine executed by the same host machine. In this manner, the hypervisor allows multiple operating systems to run in parallel with each other while sharing the same computing resources of the host machine. The host machines shown in FIG. 14 may have the same type of hypervisor or different types of hypervisors.

[0188] A compute instance can be a virtual machine instance or a bare metal instance. In Figure 14, compute instance 1468 on host machine 1402 and compute instance 1474 on host machine 1408 are examples of virtual machine instances. Host machine 1406 is an example of a bare metal instance provided to a customer.

[0189] In some cases, an entire host machine is provisioned for a single customer, and one or more compute instances (virtual machine or bare metal instances) that it hosts all belong to that same customer. In other cases, a host machine may be shared among multiple customers (i.e., multiple tenants). In such a multi-tenancy scenario, a host machine may host virtual machine compute instances that belong to different customers. These compute instances may be part of different VCNs for different customers. In some embodiments, bare metal compute instances are hosted by bare metal servers that do not include a hypervisor. When bare metal compute instances are provisioned, a single customer or tenant maintains control of the physical CPU, memory, and network interfaces of the host machine that hosts the bare metal instance, and the host machine is not shared with other customers or tenants.

[0190] As previously discussed, each compute instance that is part of a VCN is associated with a VNIC that may make the compute instance a member of a subnet of the VCN. The VNIC associated with a compute instance facilitates communication of packets or frames to the compute instance. The VNIC is associated with the compute instance when the compute instance is created. In one embodiment, for a compute instance that is executed by a host machine, the VNIC associated with the compute instance is executed by an NVD connected to the host machine. For example, in FIG. 14, host machine 1402 executes virtual machine compute instance 1468 that is associated with VNIC 1476, which is executed by NVD 1410 that is connected to host machine 1402. In another example, host machine 1406 hosts bare metal instance 1472 that is associated with VNIC 1480 that is executed by NVD 1412 that is connected to host machine 1406. In yet another example, the VNIC 1484 is associated with a compute instance 1474 executed by the host machine 1408 , and the VNIC 1484 is executed by a NVD 1412 connected to the host machine 1408 .

[0191] For compute instances hosted by a host machine, the NVD connected to that host machine also runs VCN VRs corresponding to the VCNs of which the compute instances are elements. For example, in the embodiment shown in Figure 14, NVD 1410 runs VCN VR 1477 corresponding to the VCN of which compute instance 1468 is an element. NVD 1412 may also run one or more VCN VRs 1483 corresponding to the VCNs corresponding to the compute instances hosted by host machines 1406 and 1408.

[0192] A host machine may include one or more network interface cards (NICs) that allow the host machine to be connected to other devices. The NICs on a host machine may provide one or more ports (or interfaces) that allow the host machine to be communicatively connected to other devices. For example, a host machine may be connected to an NVD by one or more ports (or interfaces) provided on the host machine and the NVD. A host machine may also be connected to other devices, such as another host machine.

[0193] 14, host machine 1402 is connected to NVD 1410 by using link 1420 extending between port 1434 provided by NIC 1432 of host machine 1402 and port 1436 of NVD 1410. Host machine 1406 is also connected to NVD 1412 by using link 1424 extending between port 1446 provided by NIC 1444 of host machine 1406 and port 1448 of NVD 1412. Host machine 1408 is also connected to NVD 1412 by using link 1426 extending between port 1452 provided by NIC 1450 of host machine 1408 and port 1454 of NVD 1412.

[0194] The NVDs, in turn, are connected via communication links to top-of-rack (TOR) switches, which are connected to a physical network 1418 (also referred to as a switch fabric). In one embodiment, the links between the host machines and the NVDs and between the NVDs and the TOR switches are Ethernet links. For example, in FIG. 14, NVDs 1410 and 1412 are connected to TOR switches 1414 and 1416, respectively, using links 1428 and 1430. In one embodiment, links 1420, 1424, 1426, 1428, and 1430 are Ethernet links. The collection of host machines and NVDs connected to a TOR may be referred to as a rack.

[0195] The physical network 1418 provides a communications fabric that allows the TOR switches to communicate with each other. The physical network 1418 can be a multi-layer network. In one embodiment, the physical network 1418 is a multi-layer Clos network of switches, with the TOR switches 1414 and 1416 representing leaf-level nodes of the multi-layer multi-node physical switching network 1418. Various Clos network configurations are possible, including, but not limited to, a two-layer network, a three-layer network, a four-layer network, a nine-layer network, and generally an "n"-layer network. An example of a Clos network is shown in FIG. 17 and described below.

[0196] A variety of different connection configurations are possible between host machines and NVDs, including one-to-one, many-to-one, and one-to-many. In one embodiment of a one-to-one configuration, each host machine is connected to its own separate NVD. For example, in FIG. 14, host machine 1402 is connected to NVD 1410 via NIC 1432 of host machine 1402. In a many-to-one configuration, multiple host machines are connected to one NVD. For example, in FIG. 14, host machines 1406 and 1408 are connected to the same NVD 1412 via NICs 1444 and 1450, respectively.

[0197] In a one-to-many configuration, one host machine is connected to multiple NVDs. FIG. 15 shows an example in CSPI 1500 in which a host machine is connected to multiple NVDs. As shown in FIG. 15, a host machine 1502 includes a network interface card (NIC) 1504 including multiple ports 1506 and 1508. The host machine 1502 is connected to a first NVD 1510 via port 1506 and link 1520, and is connected to a second NVD 1512 via port 1508 and link 1522. The ports 1506 and 1508 may be Ethernet ports, and the links 1520 and 1522 between the host machine 1502 and the NVDs 1510 and 1512 may be Ethernet links. The NVD 1510 is connected to a first TOR switch 1514, and the NVD 1512 is connected to a second TOR switch 1516. The links between the NVDs 1510 and 1512 and the TOR switches 1514 and 1516 may be Ethernet links. The TOR switches 1514 and 1516 represent layer 0 switching devices of a multi-layer physical network 1518.

[0198] The configuration shown in Figure 15 provides two separate physical network paths from the physical switch network 1518 to the host machine 1502: a first path through the TOR switch 1514 to the NVD 1510 and the host machine 1502, and a second path through the TOR switch 1516 to the NVD 1512 and the host machine 1502. These separate paths may increase the availability of the host machine 1502 (referred to as high availability). If there is a problem with one of the paths (e.g., if a link on one of the paths goes down) or one of the devices (e.g., if a particular NVD is not functioning), the other path may be used to communicate with the host machine 1502.

[0199] In the configuration shown in Figure 15, the host machine is connected to two different NVDs by using two different ports provided by the host machine's NIC. In other embodiments, the host machine may have multiple NICs allowing connection to multiple NVDs.

[0200] Referring again to Figure 14, the NVD is a physical device or component that performs one or more network and / or storage virtualization functions. The NVD may be any device that has one or more processing units (e.g., a CPU, a network processing unit (NPU), an FPGA, a packet processing pipeline, etc.), memory including cache, and ports. Various virtualization functions may be performed by software / firmware executed by one or more processing units of the NVD.

[0201] The NVD may be implemented in a variety of different forms. For example, in one embodiment, the NVD is implemented as an interface card with an embedded processor, called a smart NIC or intelligent NIC. The smart NIC is a separate device from the NIC on the host machine. In FIG. 14, the NVDs 1410 and 1412 may be implemented as smart NICs connected to the host machine 1402 and the host machines 1406 and 1408, respectively.

[0202] However, the smart NIC is only one example of an implementation of the NVD. Various other implementations are possible. For example, in some other implementations, the NVD or one or more functions performed by the NVD may be incorporated in or performed by one or more host machines, one or more TOR switches, and other components of the CSPI 1400. For example, the NVD may be embodied in a host machine and the functions performed by the NVD may be performed by the host machine. As another example, the NVD may be part of a TOR switch, and the TOR switch may be configured to perform the functions performed by the NVD that enable the TOR switch to perform various complex packet transformations used in public clouds. A TOR that performs the functions of the NVD may be referred to as a smart TOR. In still other implementations, when virtual machine (VM) instances are provided to customers instead of bare metal (BM) instances, the functions performed by the NVD may be realized inside the hypervisor of the host machine. In some other implementations, some of the functions of the NVD may be offloaded to a centralized service running on a group of host machines.

[0203] In some embodiments, such as when implemented as a smart NIC as shown in FIG. 14, the NVD may have multiple physical ports that allow connection to one or more host machines and one or more TOR switches. Ports on the NVD may be classified as host-side ports (also referred to as "south ports") or network-side or TOR-side ports (also referred to as "north ports"). The host-side ports of the NVD are the ports used to connect the NVD to the host machines. Examples of host-side ports in FIG. 14 include port 1436 on NVD 1410 and ports 1448 and 1454 on NVD 1412. The network-side ports of the NVD are the ports used to connect the NVD to the TOR switches. Examples of network-side ports in FIG. 14 include port 1456 on NVD 1410 and port 1458 on NVD 1412. 14, the NVD 1410 is connected to the TOR switch 1414 by a link 1428 that extends from a port 1456 of the NVD 1410 to the TOR switch 1414. Similarly, the NVD 1412 is connected to the TOR switch 1416 by a link 1430 that extends from a port 1458 of the NVD 1412 to the TOR switch 1416.

[0204] An NVD can receive packets and frames from a host machine (e.g., packets and frames generated by a compute instance hosted by the host machine) via a host-side port, perform necessary packet processing, and then forward the packets and frames to a TOR switch via a network-side port of the NVD. An NVD can receive packets and frames from a TOR switch via a network-side port of the NVD, perform necessary packet processing, and then forward the packets and frames to a host machine via a host-side port of the NVD.

[0205] In some embodiments, there may be multiple ports and associated links between the NVD and the TOR switch. These ports and links may be aggregated to form a link aggregator group (referred to as a LAG) of multiple ports or links. Link aggregation allows multiple physical links between two endpoints (e.g., between the NVD and the TOR switch) to be treated as a single logical link. All physical links in a given LAG may operate in full duplex mode at the same speed. LAGs help increase the bandwidth and reliability of the connection between the two endpoints. If one of the physical links in the LAG goes down, traffic is dynamically and transparently reassigned to one of the other physical links in the LAG. The aggregated physical link provides more bandwidth than each individual link. Multiple ports associated with a LAG are treated as a single logical port. Traffic may be load balanced across the multiple physical links in the LAG. One or more LAGs may be configured between two endpoints. The two endpoints may be, for example, between the NVD and the TOR switch, or between a host machine and the NVD.

[0206] The NVD implements or executes network virtualization functions. These functions are executed by software / firmware executed by the NVD. Examples of network virtualization functions include, but are not limited to, packet encapsulation and decapsulation functions, functions for creating VCN networks, functions for implementing network policies such as VCN security list (firewall) functions, functions for facilitating routing and forwarding of packets to compute instances in the VCN, and the like. In one embodiment, upon receipt of a packet, the NVD is configured to execute a packet processing pipeline for processing the packet and determining how to forward or route the packet. As part of this packet processing pipeline, the NVD may execute one or more virtual functions associated with the overlay network, such as implementing VNICs associated with cis in the VCN, implementing virtual routers (VRs) associated with the VCN, encapsulating and decapsulating packets to facilitate forwarding or routing in the virtual network, implementing certain gateways (e.g., local peering gateways), implementing security lists, network security groups, network address translation (NAT) functions (e.g., public IP to private IP translation on a per-host basis), throttling functions, and other functions.

[0207] In one embodiment, the NVD's packet processing data path may include multiple packet pipelines, each consisting of a series of packet transformation stages. In one embodiment, upon receipt of a packet, the packet is parsed and classified into a single pipeline. The packet is then processed linearly, one stage at a time, until it is either discarded or sent out through the NVD's interface. These stages provide the basic functional packet processing building blocks (e.g., header validation, throttling enforcement, new layer 2 header insertion, L4 firewall enforcement, VCN encapsulation / decapsulation, etc.), so that new pipelines are constructed by assembling existing stages, and new functionality can be added by creating and inserting new stages into existing pipelines.

[0208] The NVD may perform both control plane and data plane functions corresponding to the control and data planes of the VCN. Examples of the VCN control plane are also shown in Figures 18, 19, 20, and 21 (see reference numbers 1816, 1916, 2016, and 2116) and described below. Examples of the VCN data plane are also shown in Figures 18, 19, 20, and 21 (see reference numbers 1818, 1918, 2018, and 2118) and described below. The control plane functions include functions used to configure the network (e.g., configure routing and route tables, configure VNICs, etc.) and control how data is forwarded. In one embodiment, a VCN control plane is provided that centrally computes and exposes all overlay-to-foundation mappings to the NVD and virtual network edge devices (e.g., various gateways such as DRGs, SGWs, IGWs, etc.). Firewall rules may also be exposed by the same mechanism. In one embodiment, the NVD retrieves only mappings that are relevant to the NVD. The data plane functions include functionality for the actual routing / forwarding of packets based on the configuration set using the control plane. The VCN data plane is achieved by encapsulating customer network packets before they traverse the underlying network. The encapsulation / decapsulation functionality is achieved on the NVD. In one embodiment, the NVD is configured to intercept all network packets entering and leaving the host machine to perform network virtualization functions.

[0209] As mentioned above, the NVD performs various virtualization functions including VNICs and VCN VRs. The NVD may perform VNICs associated with compute instances hosted by one or more host machines connected to the VNICs. For example, as shown in FIG. 14, the NVD 1410 performs functions of a VNIC 1476 associated with a compute instance 1468 hosted by a host machine 1402 connected to the NVD 1410. As another example, the NVD 1412 performs VNIC 1480 associated with a bare metal compute instance 1472 hosted by a host machine 1406 and performs VNIC 1484 associated with a compute instance 1474 hosted by a host machine 1408. The host machines may host compute instances belonging to different VCNs belonging to different customers, and the NVDs connected to the host machines may perform VNICs (i.e., perform VNIC-related functions) corresponding to these compute instances.

[0210] The NVD also runs a VCN virtual router corresponding to the VCN of the compute instance. For example, in the embodiment shown in FIG. 14, NVD 1410 runs VCN VR 1477 corresponding to the VCN to which compute instance 1468 belongs. NVD 1412 runs one or more VCN VRs 1483 corresponding to one or more VCNs to which compute instances hosted by host machines 1406 and 1408 belong. In one embodiment, the VCN VR corresponding to the VCN is run by all NVDs connected to a host machine that hosts at least one compute instance that belongs to the VCN. If a host machine hosts compute instances that belong to a different VCN, the NVD connected to the host machine may run a VCN VR corresponding to the different VCN.

[0211] In addition to VNICs and VCN VRs, the NVD may run various software (e.g., daemons) and may include one or more hardware components that facilitate various network virtualization functions performed by the NVD. For simplicity, these various components are grouped together as a "packet processing component" shown in FIG. 14. For example, the NVD 1410 includes a packet processing component 1486, and the NVD 1412 includes a packet processing component 1488. For example, the packet processing component of the NVD may include a packet processor configured to interact with the ports and hardware interfaces of the NVD to monitor all packets received and communicated using the NVD and to store network information. The network information may include, for example, network flow information and per-flow information (e.g., per-flow statistics) that identify various network flows processed by the NVD. In an embodiment, the network flow information may be stored per VNIC. The packet processor may perform per-packet operations as well as implement stateful NAT and L4 firewall (FW). As another example, the packet processing component may include a replication agent configured to replicate information stored by the NVD to one or more distinct replication target stores. As yet another example, the packet processing component may include a logging agent configured to perform logging functions for the NVD. The packet processing component may also include software for monitoring the performance and health of the NVD, and possibly the status and health of other components connected to the NVD.

[0212] FIG. 13 illustrates components of an exemplary virtual or overlay network, including a VCN, a subnet in the VCN, compute instances deployed in the subnet, VNICs associated with the compute instances, VRs of the VCN, and a set of gateways configured for the VCN. The components of the overlay illustrated in FIG. 13 may be executed or hosted by one or more of the physical components illustrated in FIG. 14. For example, the compute instances in the VCN may be executed or hosted by one or more host machines illustrated in FIG. 14. For a compute instance hosted by a host machine, the VNICs associated with the compute instance are typically executed by the NVD connected to the host machine (i.e., the VNIC functionality is provided by the NVD connected to the host machine). The VCN VR functionality of the VCN is executed by all NVDs connected to the host machines that host or execute the compute instances that are part of the VCN. The gateways associated with the VCN may be executed by one or more different types of NVDs. For example, one gateway may be executed by a smart NIC, while another gateway may be executed by one or more host machines or other implementations of NVDs.

[0213] As mentioned above, a compute instance in a customer VCN can communicate with a variety of different endpoints, which can be in the same subnet as the source compute instance, in a different subnet but within the same VCN as the source compute instance, or outside the VCN of the source compute instance. These communications are facilitated through the use of VNICs associated with the compute instance, VCN VRs, and Gateways associated with the VCN.

[0214] For communication between two compute instances on the same subnet in a VCN, this communication is facilitated by the use of VNICs associated with the source and destination compute instances. The source and destination compute instances may be hosted by the same host machine or different host machines. A packet originating from a source compute instance may be forwarded from the host machine hosting the source compute instance to an NVD connected to that host machine. On the NVD, the packet is processed using a packet processing pipeline, which may include running the VNIC associated with the source compute instance. Because the destination endpoint of the packet is in the same subnet, the VNIC associated with the source compute instance forwards the packet to an NVD running the VNIC associated with the destination compute instance. The NVD then processes the packet and forwards it to the destination compute instance. The VNICs associated with the source and destination compute instances may run on the same NVD (e.g., if both the source and destination compute instances are hosted by the same host machine) or on different NVDs (e.g., if the source and destination compute instances are hosted by different host machines that are connected to different NVDs). The VNICs may use the routing / forwarding tables stored by the NVD to determine the next hop for a packet.

[0215] When a packet is sent from a compute instance in one subnet to an endpoint in a different subnet of the same VCN, the packet originating from the source compute instance is sent from the host machine hosting the source compute instance to the NVD connected to the host machine. On the NVD, the packet is processed using a packet processing pipeline, which may include the execution of one or more VNICs and VRs associated with the VCN. For example, as part of the packet processing pipeline, the NVD executes or invokes a function (also referred to as executing a VNIC) that corresponds to the VNIC associated with the source compute instance. The function executed by the VNIC may include checking the VLAN tag on the packet. Because the packet's destination is outside the subnet, the NVD then invokes and executes a VCN VR function. The VCN VR then routes the packet to the NVD that executes the VNIC associated with the destination compute instance. The VNIC associated with the destination compute instance then processes the packet and forwards it to the destination compute instance. The VNICs associated with the source and destination compute instances may be running on the same NVD (e.g., if both the source and destination compute instances are hosted by the same host machine) or may be running on different NVDs (e.g., if the source and destination compute instances are hosted by different host machines that are connected to different NVDs).

[0216] If the packet's destination is outside the VCN of the source compute instance, the packet originating from the source compute instance is sent from the host machine hosting the source compute instance to the NVD connected to the host machine. The NVD runs the VNIC associated with the source compute instance. Because the packet's destination endpoint is outside the VCN, the packet is then processed by the VCN VR of the VCN. The NVD invokes a VCN VR function, which forwards the packet to an NVD running an appropriate gateway associated with the VCN. For example, if the destination is an endpoint in a customer's on-premises network, the packet may be forwarded by the VCN VR to an NVD running a DRG gateway configured for the VCN. The VCN VR may be running on the same NVD as the NVD running the VNIC associated with the source compute instance, or it may be running on a different NVD. The gateway may be running on the NVD, which may be a smart NIC, a host machine, or another implementation of the NVD. The packet is then processed by the gateway and forwarded to a next hop that facilitates delivery of the packet to the intended destination endpoint. For example, in the embodiment shown in FIG. 14, a packet originating from compute instance 1468 may be sent from host machine 1402 to NVD 1410 over link 1420 (through the use of NIC 1432). In NVD 1410, VNIC 1476 is invoked because it is associated with source compute instance 1468. VNIC 1476 is configured to examine information encapsulated in the packet, determine a next hop to forward the packet to facilitate delivery of the packet to the intended destination endpoint, and then forward the packet to the determined next hop.

[0217] Compute instances deployed in a VCN can communicate with a variety of different endpoints. These endpoints can include endpoints hosted by CSPI1400 and endpoints outside CSPI1400. CSPI1400-hosted endpoints can include instances in the same VCN or other VCNs (which can be customer VCNs or VCNs not belonging to the customer). Communications between CSPI1400-hosted endpoints can be performed over physical network 1418. Compute instances can also communicate with endpoints not hosted by CSPI1400 (i.e., outside CSPI1400). Examples of such endpoints include endpoints in a customer's on-premise network or datacenter or public endpoints accessible over a public network such as the Internet. Communications with endpoints outside CSPI1400 can be performed over a public network (e.g., the Internet) (not shown in FIG. 14) or over a private network (not shown in FIG. 14) using a variety of communication protocols.

[0218] The architecture of CSPI1400 shown in FIG. 14 is an example only and is not intended to be limiting. In alternative embodiments, variations, substitutions, and improvements are possible. For example, in some implementations, CSPI1400 may have more or fewer systems or components than those shown in FIG. 14, may combine two or more systems, or may have different configurations or arrangements of systems. The systems, subsystems, and other components shown in FIG. 14 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processors, cores) of the respective systems, may be implemented using hardware, or may be implemented in a combination thereof. The software may be stored in a non-transitory storage medium (e.g., a memory device).

[0219] FIG. 16 illustrates a connection between a host machine and an NVD to provide I / O virtualization to support multitenancy, according to one embodiment. As shown in FIG. 16, a host machine 1602 runs a hypervisor 1604 that provides a virtualization environment. The host machine 1602 runs two virtual machine instances, VM1 1606 belonging to customer / tenant #1 and VM2 1608 belonging to customer / tenant #2. The host machine 1602 includes a physical NIC 1610 that is connected to an NVD 1612 via link 1614. Each compute instance is associated with a VNIC that the NVD 1612 runs on. In the embodiment of FIG. 16, VM1 1606 is associated with VNIC-VM1 1620, and VM2 1608 is associated with VNIC-VM2 1622.

[0220] As shown in FIG. 16, NIC 1610 includes two logical NICs, logical NIC A 1616 and logical NIC B 1618. Each virtual machine is configured to associate with and work with its own logical NIC. For example, VM1 1606 is associated with logical NIC A 1616, and VM2 1608 is associated with logical NIC B 1618. Although host machine 1602 includes only one physical NIC 1610 that is shared by multiple tenants, because of the logical NICs, each tenant's virtual machine sees that it has its own host machine and NIC.

[0221] In one embodiment, each logical NIC is assigned its own VLAN ID. Thus, a particular VLAN ID is assigned to logical NIC A 1616 for tenant #1, and a separate VLAN ID is assigned to logical NIC B 1618 for tenant #2. When a packet is sent from VM1 1606, the hypervisor attaches a tag assigned to tenant #1 to the packet, which is then sent from host machine 1602 to NVD 1612 via link 1614. Similarly, when a packet is sent from VM2 1608, the hypervisor attaches a tag assigned to tenant #2 to the packet, which is then sent from host machine 1602 to NVD 1612 via link 1614. Thus, a packet 1624 sent from host machine 1602 to NVD 1612 has an associated tag 1626 that identifies the particular tenant and associated VM. On the NVD, for a packet 1624 received from a host machine 1602, a tag 1626 associated with the packet is used to determine whether the packet should be processed by VNIC-VM1 1620 or VNIC-VM2 1622. The packet is then processed by the corresponding VNIC. With the configuration shown in FIG. 16, each tenant's compute instance can be recognized as having its own host machine and NIC. The configuration shown in FIG. 16 provides I / O virtualization to support multi-tenancy.

[0222] FIG. 17 is a simplified block diagram of a physical network 1700, according to an embodiment. The embodiment shown in FIG. 17 is structured as a Clos network. A Clos network is a particular type of network topology designed to provide connection redundancy while maintaining a wide bisection bandwidth and maximum utilization of resources. A Clos network is a type of non-blocking multi-stage or multi-layer switching network, with the number of stages or layers being possible as two, three, four, five, etc. The embodiment shown in FIG. 17 is a three-layer network, including layers 1, 2, and 3. A TOR switch 1704 represents a layer 0 switch in a Clos network. One or more NVDs are connected to the TOR switch. A layer 0 switch is also referred to as an edge device of the physical network. The layer 0 switch is connected to a layer 1 switch, also referred to as a leaf switch. In the embodiment shown in FIG. 17, a set of "n" layer 0 TOR switches are connected to a set of "n" layer 1 switches, which together form a pod. Each layer 0 switch in a pod is interconnected to all layer 1 switches in the pod, but there are no switch connections between pods. In one embodiment, two pods are referred to as a block. Each block is served or connected to a set of "n" layer 2 switches (sometimes referred to as spine switches). There may be multiple blocks in a physical network topology. The layer 2 switches are then connected to "n" layer 3 switches (sometimes referred to as super spine switches). Communication of packets through the physical network 1700 is typically performed using one or more layer 3 communication protocols. Typically, all layers of the physical network except the TOR layer are n-way redundant, thus enabling high availability. To enable scaling of the physical network, policies on pods and blocks may be specified to control the visibility of switches to each other in the physical network.

[0223] A feature of Clos networks is that they have a fixed maximum hop count from one tier 0 switch to another tier 0 switch (or from an NVD connected to a tier 0 switch to another NVD connected to a tier 0 switch). For example, in a three-tier Clos network, a packet needs at most seven hops to reach from one NVD to another, with the source and destination NVDs connected to the leaf layers of the Clos network. Similarly, in a four-tier Clos network, a packet needs at most nine hops to reach from one NVD to another, with the source and destination NVDs connected to the leaf layers of the Clos network. Thus, the Clos network architecture maintains consistent latency throughout the network, which is important for intra- and inter-datacenter communications. Clos topologies are horizontally scalable and cost-effective. The bandwidth / throughput capacity of the network can be easily increased by adding more switches (e.g., more leaf and spine switches) to the various layers as well as by increasing the number of links between switches in adjacent layers.

[0224] In one embodiment, each resource in CSPI is assigned a unique identifier called a Cloud Identifier (CID). This identifier is included as part of the resource's information and can be used to manage the resource, for example, through the Console or API. An exemplary syntax for a CID is as follows: ocid1.<RESOURCE TYPE> . <realm>.[REGION][.FUTURE USE].<UNIQUE ID> Where: ocid1 is a string indicating the version of the CID, RESOURCE TYPE is the type of resource (for example, instance, volume, VCN, subnet, user, group, etc.), REALM is the realm in which the resource resides (example values ​​are "c1" for a commercial realm, "c2" for a government cloud realm, or "c3" for a federal cloud realm, etc.; each realm may have its own domain name); REGION is the region in which the resource resides (this may be blank if region is not applicable to the resource), FUTURE USE is a reservation for future use, The UNIQUE ID is the unique part of the ID (the format can vary depending on the type of resource or service).

[0225] As mentioned above, infrastructure as a service (IaaS) is a particular type of cloud computing. IaaS can be configured to provide virtualized computing resources over a public network (e.g., the Internet). In an IaaS model, a cloud computing provider can host infrastructure components (e.g., servers, storage devices, network nodes (e.g., hardware), deployment software, platform virtualization (e.g., hypervisor layer), etc.). In some cases, an IaaS provider may also provide various services (e.g., billing, monitoring, logging, load balancing, clustering, etc.) that are associated with these infrastructure components. Thus, since these services can be policy-driven, an IaaS user can maintain application availability and performance by implementing policies that drive load balancing.

[0226] In some cases, IaaS customers can access resources and services over a wide area network (WAN) such as the Internet and use the cloud provider's services to install other elements of their application stack. For example, a user can log into an IaaS platform to create virtual machines (VMs), install operating systems (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 can then use the provider's services to perform a variety of functions, such as distributing network traffic, troubleshooting application issues, monitoring performance, and managing disaster recovery.

[0227] In most cases, the cloud computing model requires the participation of a cloud provider, which may be, but need not be, a third-party service dedicated to providing IaaS (e.g., providing, renting, selling), or an entity may deploy a private cloud and become its own infrastructure service provider.

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

[0229] In some instances, IaaS provisioning may refer to obtaining a computer or virtual host to use and even installing the necessary libraries or services on them. In most cases, deployment does not include provisioning, which may need to be performed first.

[0230] Sometimes there are two different challenges in IaaS provisioning. First, there is the initial challenge of provisioning an initial set of infrastructure before anything works. Second, there is the challenge of evolving the existing infrastructure after all the provisioning (e.g. adding new services, modifying services, removing services, etc.). Sometimes these two challenges can be addressed by allowing the configuration of the infrastructure to be defined declaratively. In other words, the infrastructure (e.g. the components required and how they interact) can be specified by one or more configuration files. Thus, the overall topology of the infrastructure (e.g. resource dependencies and how they work together) can be described declaratively. Sometimes, once the topology is specified, workflows can be generated that configure and / or manage the various components described in the configuration files.

[0231] In some examples, the infrastructure may have many interconnected elements. For example, there may be one or more virtual private clouds (VPCs) (e.g., potential on-demand pools of configurable and / or shared computing resources), also known as a core network. Also, in some examples, there may be one or more inbound / outbound traffic group rules provisioned to define how the network inbound and / or outbound traffic is configured and one or more virtual machines (VMs). Other infrastructure elements such as load balancers, databases, etc. may also be provisioned. If there is a desire and / or addition of more infrastructure elements, the infrastructure may evolve in increments.

[0232] In some cases, the employment of continuous deployment techniques may enable deployment of infrastructure code across various virtual computing environments. The described techniques may also enable infrastructure management within these environments. In some instances, a service team may write code that is desirable to deploy to one or more (but often many) different production environments (e.g., across various geographic locations, possibly across the globe). In some instances, however, the infrastructure into which the code will be deployed must first be set up. In some cases, provisioning may be performed manually, provisioning tools may be used to provision resources, and / or deployment tools may be used to deploy the code after the infrastructure has been provisioned.

[0233] 18 is a block diagram 1800 illustrating an example pattern of an IaaS architecture according to at least one embodiment. A service operator 1802 may be communicatively coupled to a secure host tenancy 1804, which may include a virtual cloud network (VCN) 1806 and a secure host subnet 1808. In some examples, the service operator 1802 may employ one or more client computing devices, which may be portable handheld devices (e.g., iPhones, mobile phones, iPads, computing tablets, personal digital assistants (PDAs)) or wearable devices (e.g., Google Glass head-mounted displays, etc.) running software such as Microsoft Windows Mobile and / or a variety of mobile operating systems such as iOS, Windows Phone, Android, BlackBerry 8, Palm OS, etc., and capable of using the Internet, email, short message service (SMS), BlackBerry, or other communications protocols. Alternatively, the client computing devices may be general purpose personal computers, examples of which include personal computers and / or laptop computers running various versions of the Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS.Alternatively or additionally, the client computing device may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox gaming console with or without a Kinect® gesture input device), and / or a personal messaging device, capable of communicating over a network that can access the VCN 1806 and / or the Internet.

[0234] VCN 1806 may include a local peering gateway (LPG) 1810 that may be communicatively coupled to a secure shell (SSH) VCN 1812 via an LPG 1810 that is included in the SSH VCN 1812. The SSH VCN 1812 may include an SSH subnet 1814, and the SSH VCN 1812 may be communicatively coupled to a control plane VCN 1816 via an LPG 1810 that is included in the control plane VCN 1816. The SSH VCN 1812 may also be communicatively coupled to a data plane VCN 1818 via the LPG 1810. The control plane VCN 1816 and the data plane VCN 1818 may be included in a service tenancy 1819, which may be owned and / or operated by the IaaS provider.

[0235] The control plane VCN 1816 may include a control plane demilitarized zone (DMZ) tier 1820 that serves as a perimeter network (e.g., a portion of an enterprise network between the enterprise intranet and an external network). DMZ-based servers may help limit liability and limit intrusions. The DMZ tier 1820 may also include one or more load balancer (LB) subnets 1822, a control plane app tier 1824 that may include app subnets 1826, a control plane data tier 1828 that may include database (DB) subnets 1830 (e.g., a front-end DB subnet and / or a back-end DB subnet). The LB subnet 1822 included in the control plane DMZ tier 1820 is communicatively coupled to an app subnet 1826 included in the control plane app tier 1824 and an Internet gateway 1834 that may be included in the control plane VCN 1816, which may be communicatively coupled to a DB subnet 1830, a service gateway 1836, and a network address translation (NAT) gateway 1838 included in the control plane data tier 1828. The control plane VCN 1816 may include the service gateway 1836 and the NAT gateway 1838.

[0236] The control plane VCN 1816 may include a data plane mirrored app layer 1840 that may include an app subnet 1826. The app subnet 1826 included in the data plane mirrored app layer 1840 may include a virtual network interface controller (VNIC) 1842 that may run a compute instance 1844. The compute instance 1844 may communicatively couple the app subnet 1826 of the data plane mirrored app layer 1840 to the app subnet 1826 that may be included in the data plane app layer 1846.

[0237] The data plane VCN 1818 may include a data plane app layer 1846, a data plane DMZ layer 1848, and a data plane data layer 1850. The data plane DMZ layer 1848 may include a LB subnet 1822, which may be communicatively coupled to an app subnet 1826 of the data plane app layer 1846 and an Internet gateway 1834 of the data plane VCN 1818. The app subnet 1826 may be communicatively coupled to a service gateway 1836 of the data plane VCN 1818 and a NAT gateway 1838 of the data plane VCN 1818. Additionally, the data plane data layer 1850 may include a DB subnet 1830, which may be communicatively coupled to the app subnet 1826 of the data plane app layer 1846.

[0238] The internet gateways 1834 of the control plane VCNs 1816 and the data plane VCNs 1818 may be communicatively coupled to a metadata management service 1852, which may be communicatively coupled to the public internet 1854. The public internet 1854 may be communicatively coupled to a NAT gateway 1838 of the control plane VCNs 1816 and the data plane VCNs 1818. The service gateways 1836 of the control plane VCNs 1816 and the data plane VCNs 1818 may be communicatively coupled to cloud services 1856.

[0239] In some examples, the service gateways 1836 of the control plane VCN 1816 and the data plane VCN 1818 can make application programming interface (API) calls to the cloud services 1856 without going through the public Internet 1854. The API calls from the service gateways 1836 to the cloud services 1856 can be unidirectional. The service gateways 1836 can make API calls to the cloud services 1856, and the cloud services 1856 can send the requested data to the service gateways 1836. However, the cloud services 1856 do not have to initiate the API calls to the service gateways 1836.

[0240] In some examples, secure host tenancy 1804 may be directly connected to an otherwise isolated service tenancy 1819. Secure host subnet 1808 may communicate with SSH subnet 1814 through LPG 1810, which may allow bidirectional communication through an otherwise isolated system. By connecting secure host subnet 1808 to SSH subnet 1814, secure host subnet 1808 may be accessible to other entities in the service tenancy 1819.

[0241] The control plane VCN 1816 may enable configuration or provisioning of desired resources by users of the service tenancy 1819. The desired resources provisioned in the control plane VCN 1816 may be deployed or used in the data plane VCN 1818. In some examples, the control plane VCN 1816 may be isolated from the data plane VCN 1818, and a data plane mirror app layer 1840 of the control plane VCN 1816 may communicate with a data plane app layer 1846 of the data plane VCN 1818 via a VNIC 1842 that may be included in the data plane mirror app layer 1840 and the data plane app layer 1846.

[0242] In some examples, a user or customer of the system may make a request (e.g., create, read, update, or delete (CRUD) operations) through the public Internet 1854, which may send the request to the metadata management service 1852. The metadata management service 1852 may send the request to the control plane VCN 1816 through the Internet Gateway 1834. The request may be received by the LB subnet 1822 in the control plane DMZ tier 1820. The LB subnet 1822 may determine that the request is valid, and in response to this determination, the LB subnet 1822 may send the request to the app subnet 1826 in the control plane app tier 1824. If the request is validated and a call to the public Internet 1854 is required, the call to the public Internet 1854 may be sent to the NAT Gateway 1838, which may make the call to the public Internet 1854. Metadata that may be desirable to store with the request may be stored in the DB subnet 1830.

[0243] In some examples, the data plane mirror app layer 1840 may facilitate direct communication between the control plane VCN 1816 and the data plane VCN 1818. For example, a configuration change, update, or other suitable modification may be desirable to apply to resources included in the data plane VCN 1818. The control plane VCN 1816 may perform the configuration change, update, or other suitable modification of the resources by communicating directly with the resources included in the data plane VCN 1818 via the VNIC 1842.

[0244] In some embodiments, the control plane VCN 1816 and the data plane VCN 1818 may be included in the service tenancy 1819. In this case, the user or customer of the system may not own or operate either the control plane VCN 1816 or the data plane VCN 1818. Alternatively, the IaaS provider may own or operate both the control plane VCN 1816 and the data plane VCN 1818, and both may be included in the service tenancy 1819. This embodiment may allow for network isolation that may prevent users or customers from interacting with the resources of other users or customers. This embodiment may also allow for private storage of databases by users or customers of the system without having to rely on the public Internet 1854, which may not have the desired level of threat prevention for storage.

[0245] In another embodiment, the LB subnet 1822 included in the control plane VCN 1816 can be configured to receive signals from the service gateway 1836. In this embodiment, the control plane VCN 1816 and the data plane VCN 1818 can be configured to be called by the IaaS provider's customers without calling the public Internet 1854. The IaaS provider's customers may desire this embodiment because databases they use can be stored in a service tenancy 1819 that is controlled by the IaaS provider and can be isolated from the public Internet 1854.

[0246] 19 is a block diagram 1900 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 1902 (e.g., service operator 1802 of FIG. 18 ) may be communicatively coupled to a virtual cloud network (VCN) 1904 (e.g., secure host tenancy 1804 of FIG. 18 ), which may include a virtual cloud network (VCN) 1906 (e.g., VCN 1806 of FIG. 18 ) and a secure host subnet 1908 (e.g., secure host subnet 1808 of FIG. 18 ). The VCN 1906 may include a local peering gateway (LPG) 1910, which may be communicatively coupled to a secure shell (SSH) VCN 1912 via an LPG 1810 (e.g., LPG 1810 of FIG. 18 ) included in the SSH VCN 1912 (e.g., SSH VCN 1812 of FIG. 18 ). SSH VCN 1912 can include an SSH subnet 1914 (e.g., SSH subnet 1814 in FIG. 18), and SSH VCN 1912 can be communicatively coupled to a control plane VCN 1916 via an LPG 1910 that is included in a control plane VCN 1916 (e.g., control plane VCN 1816 in FIG. 18). The control plane VCN 1916 can be included in a service tenancy 1919 (e.g., service tenancy 1819 in FIG. 18), and data plane VCN 1918 (e.g., data plane VCN 1818 in FIG. 18) can be included in a customer tenancy 1921, which can be owned or operated by a user or customer of the system.

[0247] The control plane VCN 1916 may include a control plane DMZ tier 1920 (e.g., control plane DMZ tier 1820 of FIG. 18 ) that may include a LB subnet 1922 (e.g., LB subnet 1822 of FIG. 18 ), a control plane app tier 1924 (e.g., control plane app tier 1824 of FIG. 18 ) that may include an app subnet 1926 (e.g., app subnet 1826 of FIG. 18 ), and a control plane data tier 1928 (e.g., control plane data tier 1828 of FIG. 18 ) that may include a DB subnet 1930 (e.g., similar to database (DB) subnet 1830 of FIG. 18 ). The LB subnet 1922 included in the control plane DMZ layer 1920 is communicatively coupled to an app subnet 1926 included in the control plane app layer 1924 and an Internet gateway 1934 (e.g., Internet gateway 1834 of FIG. 18 ) that may be included in the control plane VCN 1916, and the app subnet 1926 may be communicatively coupled to a DB subnet 1930, a service gateway 1936 (e.g., service gateway 1836 of FIG. 18 ), and a network address translation (NAT) gateway 1938 (e.g., NAT gateway 1838 of FIG. 18 ) included in the control plane data layer 1928. The control plane VCN 1916 may comprise the service gateway 1936 and the NAT gateway 1938.

[0248] The control plane VCN 1916 may include a data plane mirror app layer 1940 (e.g., data plane mirror app layer 1840 of FIG. 18 ), which may include an app subnet 1926. The app subnet 1926 included in the data plane mirror app layer 1940 may include a virtual network interface controller (VNIC) 1942 (e.g., VNIC 1842) on which a compute instance 1944 (e.g., similar to compute instance 1844 of FIG. 18 ) may run. The compute instance 1944 may facilitate communication between the app subnet 1926 of the data plane mirror app layer 1940 and the app subnet 1926 that may be included in the data plane app layer 1946 via the VNIC 1942 included in the data plane mirror app layer 1940 and the VNIC 1942 included in the data plane app layer 1946 (e.g., data plane app layer 1846 of FIG. 18 ).

[0249] An internet gateway 1934 included in the control plane VCN 1916 may be communicatively coupled to a metadata management service 1952 (e.g., metadata management service 1852 of FIG. 18 ), which may be communicatively coupled to a public internet 1954 (e.g., public internet 1854 of FIG. 18 ). The public internet 1954 may be communicatively coupled to a NAT gateway 1938 included in the control plane VCN 1916. A service gateway 1936 included in the control plane VCN 1916 may be communicatively coupled to cloud services 1956 (e.g., cloud services 1856 of FIG. 18 ).

[0250] In some examples, the data plane VCN 1918 may be included in the customer tenancy 1921. In this case, the IaaS provider may provide a control plane VCN 1916 for each customer, and the IaaS provider may configure a unique compute instance 1944 for each customer, which is included in the service tenancy 1919. Each compute instance 1944 may enable communication between the control plane VCN 1916 in the service tenancy 1919 and the data plane VCN 1918 in the customer tenancy 1921. The compute instance 1944 may enable deployment or use of resources provisioned in the control plane VCN 1916 in the service tenancy 1919 in the data plane VCN 1918 in the customer tenancy 1921.

[0251] In another example, an IaaS provider customer may have a database that resides in customer tenancy 1921. In this example, control plane VCN 1916 may include data plane mirror app layer 1940 that may include app subnet 1926. Data plane mirror app layer 1940 may reside in data plane VCN 1918, but may not reside in data plane VCN 1918. That is, data plane mirror app layer 1940 may be accessible to customer tenancy 1921, but may not reside in data plane VCN 1918, and may not be owned or operated by the IaaS provider customer. Data plane mirror app layer 1940 may be configured to make calls to data plane VCN 1918, but may not be configured to make calls to any entities included in control plane VCN 1916. A customer may desire deployment or use of resources in the data plane VCN 1918 that have been provisioned in the control plane VCN 1916, and the data plane mirror app layer 1940 may facilitate the deployment or other use of the resources that the customer desires.

[0252] In some embodiments, the IaaS provider's customer can apply filters to the data plane VCN 1918. In this embodiment, the customer can determine what the data plane VCN 1918 can access, and the customer may limit access from the data plane VCN 1918 to the public internet 1954. The IaaS provider may not be able to apply filters or control the access of the data plane VCN 1918 to any external networks or databases. The customer's application of filters and controls to the data plane VCN 1918 in the customer tenancy 1921 can help isolate the data plane VCN 1918 from other customers and the public internet 1954.

[0253] In some embodiments, the cloud services 1956 can access services that may not be in the public internet 1954, the control plane VCN 1916, or the data plane VCN 1918 through calls made by the service gateway 1936. The connection between the cloud services 1956 and the control plane VCN 1916 or the data plane VCN 1918 may not be live or continuous. The cloud services 1956 may be on different networks owned or operated by the IaaS provider. The cloud services 1956 may be configured to receive calls from the service gateway 1936 or may not be configured to receive calls from the public internet 1954. Some cloud services 1956 may be isolated from other cloud services 1956, and the control plane VCN 1916 may be isolated from cloud services 1956 that may not be in the same region as the control plane VCN 1916. For example, control plane VCN 1916 may be located in "Region 1," and cloud service "deployment 18" may be located in Region 1 and Region 2. If a call to deployment 18 is made by a service gateway 1936 included in control plane VCN 1916 located in Region 1, the call may be sent to deployment 18 in Region 1. In this example, control plane VCN 1916 or deployment 18 in Region 1 may not be communicatively coupled to or in communication with deployment 18 in Region 2.

[0254] 20 is a block diagram 2000 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 2002 (e.g., service operator 1802 of FIG. 18 ) may be communicatively coupled to a secure host tenancy 2004 (e.g., secure host tenancy 1804 of FIG. 18 ), which may include a virtual cloud network (VCN) 2006 (e.g., VCN 1806 of FIG. 18 ) and a secure host subnet 2008 (e.g., secure host subnet 1808 of FIG. 18 ). The VCN 2006 may include an LPG 2010, which may be communicatively coupled to an SSH VCN 2012 via an LPG 2010 (e.g., LPG 1810 of FIG. 18 ) included in the SSH VCN 2012 (e.g., SSH VCN 1812 of FIG. 18 ). SSH VCN 2012 may include SSH subnet 2014 (e.g., SSH subnet 1814 in FIG. 18 ), and SSH VCN 2012 may be communicatively coupled to control plane VCN 2016 via LPG 2010 included in control plane VCN 2016 (e.g., control plane VCN 1816 in FIG. 18 ) and to data plane VCN 2018 via LPG 2010 included in data plane VCN 2018 (e.g., data plane VCN 1818 in FIG. 18 ). Control plane VCN 2016 and data plane VCN 2018 may be included in service tenancy 2019 (e.g., service tenancy 1819 in FIG. 18 ).

[0255] The control plane VCN 2016 may include a control plane DMZ tier 2020 (e.g., control plane DMZ tier 1820 of FIG. 18 ) that may include a load balancer (LB) subnet 2022 (e.g., LB subnet 1822 of FIG. 18 ), a control plane app tier 2024 (e.g., control plane app tier 1824 of FIG. 18 ) that may include an app subnet 2026 (e.g., similar to app subnet 1826 of FIG. 18 ), and a control plane data tier 2028 (e.g., control plane data tier 1828 of FIG. 18 ) that may include a DB subnet 2030. The LB subnet 2022 included in the control plane DMZ tier 2020 is communicatively coupled to an app subnet 2026 included in the control plane app tier 2024 and an Internet gateway 2034 (e.g., Internet gateway 1834 of FIG. 18 ) that may be included in the control plane VCN 2016, and the app subnet 2026 may be communicatively coupled to a DB subnet 2030, a service gateway 2036 (e.g., service gateway of FIG. 18 ), and a network address translation (NAT) gateway 2038 (e.g., NAT gateway 1838 of FIG. 18 ) included in the control plane data tier 2028. The control plane VCN 2016 may comprise the service gateway 2036 and the NAT gateway 2038.

[0256] The data plane VCN 2018 may include a data plane app layer 2046 (e.g., data plane app layer 1846 of FIG. 18 ), a data plane DMZ layer 2048 (e.g., data plane DMZ layer 1848 of FIG. 18 ), and a data plane data layer 2050 (e.g., data plane data layer 1850 of FIG. 18 ). The data plane DMZ layer 2048 may include a LB subnetwork 2022 that may be communicatively coupled to a trusted app subnetwork 2060 and a non-trusted app subnetwork 2062 of the data plane app layer 2046 and an Internet gateway 2034 included in the data plane VCN 2018. The trusted app subnetwork 2060 may be communicatively coupled to a service gateway 2036 included in the data plane VCN 2018, a NAT gateway 2038 included in the data plane VCN 2018, and a DB subnetwork 2030 included in the data plane data layer 2050. The untrusted app subnet 2062 may be communicatively coupled to a service gateway 2036 included in the data plane VCN 2018 and a DB subnet 2030 included in the data plane data layer 2050. The data plane data layer 2050 may include a DB subnet 2030 that may be communicatively coupled to a service gateway 2036 included in the data plane VCN 2018.

[0257] The untrusted app subnet 2062 may include one or more primary VNICs 2064(1)-2064(N), which may be communicatively coupled to tenant virtual machines (VMs) 2066(1)-2066(N). Each tenant VM 2066(1)-2066(N) may be communicatively coupled to a respective app subnet 2067(1)-2067(N), which may be included in a respective container egress VCN 2068(1)-2068(N), which may be included in a respective customer tenancy 2070(1)-2070(N). Each secondary VNIC 2072(1)-2072(N) may facilitate communication between the untrusted app subnet 2062, which is included in the data plane VCN 2018, and the app subnets, which are included in the respective container egress VCNs 2068(1)-2068(N). Each container egress VCN 2068(1)-2068(N) may include a NAT gateway 2038 that may be communicatively coupled to the public Internet 2054 (e.g., public Internet 1854 in FIG. 18).

[0258] An internet gateway 2034 included in the control plane VCN 2016 and the data plane VCN 2018 may be communicatively coupled to a metadata management service 2052 (e.g., metadata management system 1852 of FIG. 18 ), which may be communicatively coupled to the public internet 2054. The public internet 2054 may be communicatively coupled to a NAT gateway 2038 included in the control plane VCN 2016 and the data plane VCN 2018. A service gateway 2036 included in the control plane VCN 2016 and the data plane VCN 2018 may be communicatively coupled to cloud services 2056.

[0259] In some embodiments, data plane VCN 2018 may be integrated with customer tenancy 2070. This integration may be useful or desirable for an IaaS provider's customer, such as when they may want support for running code. A customer may provide code to run, which may be disruptive, may communicate with other customer resources, or may have undesirable effects. In response, the IaaS provider may determine whether to run the code provided to it by the customer.

[0260] In some examples, a customer of an IaaS provider may grant temporary network access to the IaaS provider to request functionality provided in the data plane app layer 2046. The code to perform this functionality may be configured to run in VMs 2066(1)-2066(N) and may not be configured to run anywhere else on the data plane VCN 2018. Each VM 2066(1)-2066(N) may be connected to one customer tenancy 2070. Each container 2071(1)-2071(N) contained in VMs 2066(1)-2066(N) may be configured to run code. In this case, there may be a double isolation (e.g., containers 2071(1)-2071(N) executing code may be contained in VMs 2066(1)-2066(N) contained in at least the untrusted app subnet 2062), which may help prevent erroneous or unwanted code from damaging the IaaS provider's network or a different customer's network. Containers 2071(1)-2071(N) may be communicatively coupled to customer tenancy 2070 and may be configured to send or receive data from customer tenancy 2070. Containers 2071(1)-2071(N) may be configured not to send or receive data from any other entity in data plane VCN 2018. Upon completion of code execution, the IaaS provider may disable or discard containers 2071(1)-2071(N).

[0261] In some embodiments, the trusted app subnet 2060 may execute code that may be owned or operated by the IaaS provider. In this embodiment, the trusted app subnet 2060 may be communicatively coupled to the DB subnet 2030 and may be configured to perform CRUD operations on the DB subnet 2030. The non-trusted app subnet 2062 may be communicatively coupled to the DB subnet 2030, but in this embodiment, may be configured to perform read operations on the DB subnet 2030. The containers 2071(1)-2071(N) included in each customer's VMs 2066(1)-2066(N) that may execute code from the customer may not be communicatively coupled to the DB subnet 2030.

[0262] In other embodiments, the control plane VCN 2016 and the data plane VCN 2018 may not be directly communicatively coupled. In this embodiment, there may not be direct communication between the control plane VCN 2016 and the data plane VCN 2018. However, communication may occur indirectly in at least one manner. An LPG 2010 may be established by an IaaS provider that may facilitate communication between the control plane VCN 2016 and the data plane VCN 2018. In another example, the control plane VCN 2016 or the data plane VCN 2018 may make a call to a cloud service 2056 via a service gateway 2036. For example, a call from the control plane VCN 2016 to the cloud service 2056 may include a request for a service that may communicate with the data plane VCN 2018.

[0263] 21 is a block diagram 2100 illustrating another example pattern of an IaaS architecture, according to at least one embodiment. A service operator 2102 (e.g., service operator 1802 of FIG. 18) may be communicatively coupled to a secure host tenancy 2104 (e.g., secure host tenancy 1804 of FIG. 18), which may include a virtual cloud network (VCN) 2106 (e.g., VCN 1806 of FIG. 18) and a secure host subnet 2108 (e.g., secure host subnet 1808 of FIG. 18). The VCN 2106 may include an LPG 2110, which may be communicatively coupled to an SSH VCN 2112 via an LPG 2110 (e.g., LPG 1810 of FIG. 18) included in the SSH VCN 2112 (e.g., SSH VCN 1812 of FIG. 18). SSH VCN 2112 may include SSH subnet 2114 (e.g., SSH subnet 1814 in FIG. 18 ), and SSH VCN 2112 may be communicatively coupled to control plane VCN 2116 via LPG 2110 included in control plane VCN 2116 (e.g., control plane VCN 1816 in FIG. 18 ) and to data plane VCN 2118 via LPG 2110 included in data plane VCN 2118 (e.g., data plane VCN 1818 in FIG. 18 ). Control plane VCN 2116 and data plane VCN 2118 may be included in service tenancy 2119 (e.g., service tenancy 1819 in FIG. 18 ).

[0264] The control plane VCN 2116 may include a control plane DMZ layer 2120 (e.g., control plane DMZ layer 1820 of FIG. 18 ) that may include a LB subnet 2122 (e.g., LB subnet 1822 of FIG. 18 ), a control plane app layer 2124 (e.g., control plane app layer 1824 of FIG. 18 ) that may include an app subnet 2126 (e.g., app subnet 1826 of FIG. 18 ), and a control plane data layer 2128 (e.g., control plane data layer 1828 of FIG. 18 ) that may include a DB subnet 2130 (e.g., DB subnet 2030 of FIG. 20 ). The LB subnet 2122 included in the control plane DMZ layer 2120 is communicatively coupled to an app subnet 2126 included in the control plane app layer 2124 and an Internet gateway 2134 (e.g., Internet gateway 1834 of FIG. 18 ) that may be included in the control plane VCN 2116, and the app subnet 2126 may be communicatively coupled to a DB subnet 2130, a service gateway 2136 (e.g., service gateway of FIG. 18 ), and a network address translation (NAT) gateway 2138 (e.g., NAT gateway 1838 of FIG. 18 ) included in the control plane data layer 2128. The control plane VCN 2116 may comprise the service gateway 2136 and the NAT gateway 2138.

[0265] The data plane VCN 2118 can include a data plane app layer 2146 (e.g., data plane app layer 1846 of FIG. 18 ), a data plane DMZ layer 2148 (e.g., data plane DMZ layer 1848 of FIG. 18 ), and a data plane data layer 2150 (e.g., data plane data layer 1850 of FIG. 18 ). The data plane DMZ layer 2148 can include a trusted app subnet 2160 (e.g., trusted app subnet 2060 of FIG. 20 ) and a non-trusted app subnet 2162 (e.g., non-trusted app subnet 2062 of FIG. 20 ) of the data plane app layer 2146 and a LB subnet 2122 that can be communicatively coupled to an Internet gateway 2134 included in the data plane VCN 2118. The trusted app subnet 2160 may be communicatively coupled to a service gateway 2136 included in the data plane VCN 2118, a NAT gateway 2138 included in the data plane VCN 2118, and a DB subnet 2130 included in the data plane data layer 2150. The untrusted app subnet 2162 may be communicatively coupled to a service gateway 2136 included in the data plane VCN 2118 and a DB subnet 2130 included in the data plane data layer 2150. The data plane data layer 2150 may include a DB subnet 2130 that may be communicatively coupled to a service gateway 2136 included in the data plane VCN 2118.

[0266] The untrusted app subnet 2162 can include primary VNICs 2164(1)-2164(N) that can be communicatively coupled to tenant virtual machines (VMs) 2166(1)-2166(N) that reside within the untrusted app subnet 2162. Each tenant VM 2166(1)-2166(N) can execute code in a respective container 2167(1)-2167(N) and can be communicatively coupled to an app subnet 2126 that can be included in a data plane app layer 2146 that can be included in a container egress VCN 2168. The secondary VNICs 2172(1)-2172(N) can facilitate communication between the untrusted app subnet 2162 included in the data plane VCN 2118 and the app subnet included in the container egress VCN 2168. The container egress VCN may include a NAT gateway 2138 that may be communicatively coupled to the public Internet 2154 (e.g., the public Internet 1854 of FIG. 18).

[0267] An internet gateway 2134 included in the control plane VCN 2116 and the data plane VCN 2118 may be communicatively coupled to a metadata management service 2152 (e.g., metadata management system 1852 of FIG. 18 ), which may be communicatively coupled to the public internet 2154. The public internet 2154 may be communicatively coupled to a NAT gateway 2138 included in the control plane VCN 2116 and the data plane VCN 2118. A service gateway 2136 included in the control plane VCN 2116 and the data plane VCN 2118 may be communicatively coupled to cloud services 2156.

[0268] In some examples, the pattern illustrated by the architecture of block diagram 2100 of FIG. 21 may be an exception to the pattern illustrated by the architecture of block diagram 2000 of FIG. 20 and may be desirable for customers of an IaaS provider when the IaaS provider cannot communicate directly with the customer (e.g., in a non-connected region). Each of the containers 2167(1)-2167(N) contained in VMs 2166(1)-2166(N) for each customer may be accessible in real time by the customer. The containers 2167(1)-2167(N) may be configured to make calls to each of the secondary VNICs 2172(1)-2172(N) contained in the app subnet 2126 of the data plane app layer 2146, which may be included in the container egress VCN 2168. Secondary VNICs 2172(1)-2172(N) may send the calls to NAT gateway 2138, which may send the calls to the public Internet 2154. In this example, containers 2167(1)-2167(N) that are accessible in real time by customers may be isolated from the control plane VCN 2116 and may be isolated from other entities included in the data plane VCN 2118. Containers 2167(1)-2167(N) may also be isolated from resources of other customers.

[0269] In another example, a customer can use containers 2167(1)-2167(N) to call cloud service 2156. In this example, the customer can execute code in containers 2167(1)-2167(N) that requests a service from cloud service 2156. Containers 2167(1)-2167(N) can send the request to secondary VNICs 2172(1)-2172(N), which can send the request to a NAT gateway, which can send the request to public internet 2154. Public internet 2154 can send the request to LB subnet 2122 included in control plane VCN 2116 via internet gateway 2134. In response to determining that the request is valid, the LB subnet can send the request to the app subnet 2126, which can send the request to the cloud service 2156 via the service gateway 2136.

[0270] It should be understood that the IaaS architectures 1800, 1900, 2000, 2100 depicted in the figures may include components other than those depicted. Additionally, the embodiment depicted in the figures is merely one example of a cloud infrastructure system that may incorporate an embodiment of the present disclosure. In other embodiments, an IaaS system may include more or fewer components than depicted, may combine two or more components, or may have a different configuration or arrangement of components.

[0271] In one embodiment, the IaaS system described herein may include a set of application, middleware, and database services delivered to customers in a self-service and subscription-based, elastically scalable, reliable, highly available, and secure manner. Oracle Cloud Infrastructure (OCI), offered by the Assignee, is one example of such an IaaS system.

[0272] 22 illustrates an exemplary computer system 2200 upon which various embodiments may be implemented. The system 2200 may be adapted to implement any of the computer systems described above. As shown in the figure, the computer system 2200 includes a processing unit 2204 that communicates with a number of peripheral subsystems via a bus subsystem 2202. The peripheral subsystems may include a processing acceleration unit 2206, an I / O subsystem 2208, a storage subsystem 2218, and a communication subsystem 2224. The storage subsystem 2218 includes a tangible computer readable storage medium 2222 and a system memory 2210.

[0273] Bus subsystem 2202 provides a mechanism for allowing the various components and subsystems of computer system 2200 to communicate with each other as desired. Although bus subsystem 2202 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 2202 may be any of a number of 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, which may be implemented as a mezzanine bus manufactured in accordance with the IEEE P1386.1 standard, 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.

[0274] Processing unit 2204, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of computer system 2200. Processing unit 2204 may include one or more processors. These processors may include single-core or multi-core processors. In some embodiments, processing unit 2204 may be implemented as one or more independent processing units 2232 and / or 2234, each including a single-core or multi-core processor. In other embodiments, processing unit 2204 may be implemented as a quad-core processing unit formed by integrating two dual-core processors on a single chip.

[0275] In various embodiments, the processing unit 2204 is capable of executing various programs in response to program code and maintaining multiple simultaneously executing programs or processes. At any given time, some or all of the program code being executed may reside on the processor 2204 and / or on the storage subsystem 2218. With suitable programming, the processor 2204 can provide the various functions discussed above. The computer system 2200 may also include a processing acceleration unit 2206, which may include a digital signal processor (DSP), a special purpose processor, and / or the like.

[0276] The I / O subsystem 2208 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, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include 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 voice commands. User interface input devices may also include an eye gesture recognition device such as a Google Glass® blink detector that detects a user's eye activity (e.g., "blinking" during filming and / or menu selection) and translates eye gestures as input to an input device (e.g., Google Glass®). The user interface input devices may also include a voice recognition sensing device that allows a user to interact with a voice recognition system (eg, the Siri® navigator) via voice commands.

[0277] User interface input devices may also include, but are not limited to, 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 video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser range finders, and eye-tracking devices. User interface input devices may also include medical imaging input devices such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, and medical ultrasound devices. User interface input devices may also include audio input devices such as, for example, MIDI keyboards, digital musical instruments, and the like.

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

[0279] Computer system 2200 may also include a storage subsystem 2218 that provides a tangible, transitory computer-readable storage medium for storing software and data constructs that provide functionality of embodiments described in the present disclosure. The software may include programs, code modules, instructions, scripts, etc. that, when executed by one or more cores or processors of processing unit 2204, provide the functionality described above. Storage subsystem 2218 may also provide a repository for storing data used in accordance with the present disclosure.

[0280] As shown in the example of FIG. 22, storage subsystem 2218 may include various components including a system memory 2210, a computer readable storage medium 2222, and a computer readable storage medium reader 2220. The system memory 2210 may store program instructions that may be loaded and executed by the processing unit 2204. The system memory 2210 may also store data used during execution of the instructions and / or data generated during execution of the program instructions. A variety of different types of programs may be loaded into the system memory 2210, including, but not limited to, client applications, web browsers, mid-tier applications, relational database management systems (RDBMS), virtual machines, containers, etc.

[0281] System memory 2210 may also store an operating system 2216. Examples of operating systems 2216 include various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems, various commercially available UNIX or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome OS, etc.), and / or mobile operating systems such as iOS, Windows Phone, Android OS, BlackBerry OS, and Palm OS operating systems. In some embodiments in which computer system 2200 runs one or more virtual machines, the virtual machines, along with respective guest operating systems (GOS), may be loaded into system memory 2210 and executed by one or more processors or cores of processing unit 2204.

[0282] The system memory 2210 may have a variety of configurations, depending on the type of computer system 2200. For example, the system memory 2210 may be volatile memory (such as random access memory (RAM)) and / or non-volatile memory (such as read-only memory (ROM), flash memory, etc.). Different types of RAM configurations may also be provided, including static random access memory (SRAM), dynamic random access memory (DRAM), and others. In some implementations, the system memory 2210 may include a basic input / output system (BIOS), which contains the basic routines that help to transfer information between elements within the computer system 2200, such as during start-up.

[0283] Computer-readable storage medium 2222 may represent remote, local, fixed, and / or removable storage devices, as well as storage media for temporarily and / or permanently containing and storing computer-readable information used by computer system 2200 (including instructions executable by processing unit 2204 of computer system 2200).

[0284] The computer readable storage medium 2222 may include any suitable medium known or used in the art (including storage media and communication media), including, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing and / or transmitting information. This may include tangible computer readable storage media, such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory, and other memory technologies, optical storage, such as CD-ROM, digital versatile disks (DVD), magnetic storage devices, such as magnetic cassettes, magnetic tape, magnetic disk storage, or other tangible computer readable media.

[0285] By way of example, the computer readable storage medium 2222 may include hard disk drives that read from and write to non-removable, non-volatile magnetic media, magnetic disk drives that read from and write to removable, non-volatile magnetic disks, and optical disk drives that read from and write to removable, non-volatile optical disks, such as CD-ROMs, DVDs, Blu-Ray® disks, or other optical media. The computer readable storage medium 2222 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 2222 may also include flash memory-based SSDs, enterprise flash drives, solid-state drives (SSDs) based on non-volatile memory, such as solid-state ROMs, solid-state RAMs, dynamic RAMs, static RAMs, 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 the computer system 2200.

[0286] Machine-readable instructions executable by one or more processors or cores of the processing unit 2204 may be stored on a non-transitory computer-readable storage medium. A non-transitory computer-readable storage medium may include physically tangible memory or storage devices, including volatile memory storage devices and / or non-volatile storage devices. Examples of non-transitory computer-readable storage media include magnetic storage media (e.g., disks or tapes), optical storage media (e.g., DVDs, CDs), various types of RAM, ROM, or flash memory, hard drives, floppy drives, removable memory drives (e.g., USB drives), or other types of storage devices.

[0287] The communications subsystem 2224 provides an interface to other computer systems and networks. The communications subsystem 2224 serves as an interface for sending and receiving data between the computer system 2200 and other systems. For example, the communications subsystem 2224 may enable the computer system 2200 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 2224 may comprise a wireless voice and / or data network (e.g., using cellular technology, 3G, 4G, or advanced data network technologies such as 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 a radio frequency (RF) transceiver component for accessing other components. In some embodiments, the communications subsystem 2224 may provide a wired network connection (e.g., Ethernet) in addition to or as an alternative to a wireless interface.

[0288] In some embodiments, the communications subsystem 2224 can also receive input information in the form of structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, etc., on behalf of one or more users who may be using the computer system 2200.

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

[0290] The communications subsystem 2224 may also be configured to receive data in the form of a continuous data stream, which may include an event stream 2228 of real-time events and / or event updates 2230, which may be continuous or effectively infinite with no apparent end. Examples of applications that generate continuous data include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0291] The communications subsystem 2224 may also be configured to output structured and / or unstructured data feeds 2226, event streams 2228, event updates 2230, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 2200.

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

[0293] Due to the ever-changing nature of computers and networks, the description of the illustrated computer system 2200 is intended as an example only. Many other configurations are possible, whether they include more or fewer components than the illustrated system. For example, the use of customized hardware and / or implementation of particular elements in hardware, firmware, software (including applets), or a combination is also contemplated. Additionally, connections to other computing devices, such as network I / O devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0294] Although specific embodiments have been described above, various improvements, modifications, alternative configurations, and equivalents are within the scope of the present disclosure. The embodiments are not limited to operating in a particular data processing environment, but may freely operate in multiple data processing environments. Furthermore, while the embodiments have been described using a specific sequence of transactions and steps, it will be apparent to those skilled in the art that the scope of the present 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 together.

[0295] Furthermore, while embodiments have been described using a particular combination of hardware and software, it will be appreciated that other combinations of hardware and software are within the scope of the present disclosure. The embodiments may be implemented solely in hardware, solely in software, or by using 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 any combination thereof. Processes may communicate using a variety of techniques, including, but not limited to, conventional techniques for inter-process communication. Also, different sets of processes may use different techniques, and the same set of processes may use different techniques at different times.

[0296] Accordingly, the specification and drawings are to be regarded as illustrative rather than restrictive. However, it will be apparent that additions, differences, deletions, and other modifications and changes may be made without departing from the broad spirit and scope of the appended claims. Thus, although specific embodiments of the present disclosure have been described, they are not intended to be limiting. Various modifications and equivalents are intended to be within the scope of the following claims.

[0297] 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 noted. The term "connected" shall be construed as partly or wholly contained, attached, or integrally connected, even if there is something intervening. The recitation of ranges of values ​​herein is merely intended to serve as a shorthand method of individually referring to each separate value included in the range, unless otherwise indicated herein, and each separate value is incorporated herein as if it were a separate recitation herein. All methods described herein may be performed in any suitable order, unless otherwise indicated herein or clearly contradicted by context. The use of any and all examples or exemplary language (e.g., "such as") herein is intended to facilitate understanding of the embodiments only and does not limit the scope of the disclosure unless otherwise asserted. No language in the specification should be construed as indicating any non-claimed element as essential to the practice of the disclosure.

[0298] Unless otherwise noted, disjunctive language, such as the phrase "at least one of X, Y, or Z," is intended to be understood in the context in which it is commonly used to indicate that an item, term, etc. can be either X, Y, Z, or any combination thereof (e.g., X, Y, and / or Z). Thus, such disjunctive language is generally not intended to, and should not, imply that an embodiment requires the presence of each of at least one of X, at least one of Y, or at least one of Z.

[0299] Preferred embodiments of the present disclosure are described herein, including the best mode known for carrying out the present disclosure. Variations of these preferred embodiments may become apparent to those skilled in the art upon reading the above description. Such variations can be accommodated by those skilled in the art as necessary, and the present disclosure may be practiced differently from the specific descriptions herein. Accordingly, this disclosure includes all modifications and equivalents of the subject matter recited in the claims appended hereto as permitted by applicable law. Moreover, unless otherwise indicated herein, this disclosure includes any combination of the above-described elements in all possible variations thereof.

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

[0301] Although aspects of the disclosure are described in the above specification with reference to specific embodiments, those skilled in the art will recognize that the disclosure is not limited thereto. The various features and aspects of the disclosure described above may be used individually or together. 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 are to be regarded as illustrative rather than limiting.

[0302] Clause 1: A computer-implemented method comprising: A computing device of the virtual cloud network selects one or more filters from a plurality of filters for the data pipeline.

[0303] Multiple filters can be Malware filter, Content filters, Signature Filters, Content Analyzer, Machine learning filters, or Artificial Intelligence Filter, Includes at least one of the following:

[0304] The method further includes a computing device of the virtual cloud network determining an order of the one or more selected filters in the data pipeline.

[0305] The method further includes a computing device of the virtual cloud network receiving messages in the data pipeline from a network interface card (NIC) configured as a one-way communication device.

[0306] The method further includes a computing device of the virtual cloud network filtering the messages in the data pipeline by passing the messages through one or more selected filters in the determined order.

[0307] The method further includes the computing devices of the virtual cloud network providing, via the logging network, a log of events occurring in the data pipeline.

[0308] Clause 2: The method of clause 1, wherein the determined order is determined at least in part based on a source of the messages.

[0309] Clause 3: The method of clause 1, wherein the one or more selected filters are selected based at least in part on a source of the message.

[0310] Clause 4: The method of clause 1, wherein a plurality of the one or more filters are selected for the same message source.

[0311] Clause 5: The method of clause 1, wherein the network interface card includes a software-based one-way transmission device.

[0312] Clause 6: The method of clause 1, further comprising removing the one or more selected filters from the data pipeline after the message has been processed by the one or more selected filters in the determined order.

[0313] Clause 7: The method according to clause 1, wherein the virtual cloud network is a virtual machine.

[0314] Clause 8: A computer program product comprising instructions tangibly embodied in one or more non-transitory machine-readable media and configured to cause one or more data processors to execute the instructions, The instructions executed by the one or more data processors include selecting one or more filters from a plurality of filters for the data pipeline.

[0315] Multiple filters can be Malware filter, Content filters, Signature Filters, Content Analyzer, Machine learning filters, or Artificial Intelligence Filter, Includes at least one of the following:

[0316] The instructions executed by the one or more data processors further include determining an order of the one or more selected filters in the data pipeline.

[0317] The instructions executed by the one or more data processors further include receiving a message in the data pipeline from a network interface card (NIC) configured as a one-way communication device.

[0318] The instructions executed by the one or more data processors further include filtering messages in the data pipeline by passing the messages through selected filters in the determined order.

[0319] The instructions executed by the one or more data processors further include providing, via a logging network, a log of events occurring in the data pipeline.

[0320] Clause 9: The computer program product of clause 8, wherein the determined order is determined based at least in part on a source of the messages.

[0321] Clause 10: The computer program product of clause 8, wherein the one or more selected filters are selected based at least in part on a source of the message.

[0322] Clause 11: The computer program product of clause 8, wherein a plurality of the one or more filters are selected for the same message source.

[0323] Clause 12: The computer program product according to clause 8, wherein the network interface card includes a software-based one-way transmission device.

[0324] Clause 13: The computer program product of clause 8, wherein the instructions executed by the one or more data processors further include removing the one or more selected filters from the data pipeline after the message has been processed by the one or more selected filters in the determined order.

[0325] Clause 14: The non-transitory computer-readable storage medium of clause 8, wherein the virtual cloud network is a virtual machine.

[0326] Clause 15: A data pipeline, comprising: As part of the data pipeline, a network interface card (NIC) is included that is configured as a one-way communication device.

[0327] The data pipeline is Malware filter, Content filters, Signature Filters, Content Analyzer, Machine learning filters, or Artificial Intelligence Filter, The device further comprises a plurality of filters including at least one of:

[0328] The data pipeline further comprises a virtual cloud network configured to include one or more filters of the plurality of filters, wherein messages received by the virtual cloud network from the network interface controller are passed sequentially through the one or more filters of the data pipeline in an order determined at configuration time.

[0329] The data pipeline further comprises a logging network for providing a log of events occurring in the data pipeline.

[0330] Clause 16: The data pipeline of clause 15, wherein the determined order is determined based at least in part on an origin of the messages.

[0331] Clause 17: The data pipeline of clause 15, wherein the one or more selected filters are selected based at least in part on an origin of the message.

[0332] Clause 18: The data pipeline of clause 15, wherein a plurality of the one or more filters are selected for a same message source.

[0333] Clause 19: The data pipeline of clause 15, wherein the network interface card includes a software-based one-way transmission device.

[0334] Clause 20: The data pipeline of clause 15, further comprising removing the one or more selected filters from the data pipeline after the message has been processed by the one or more selected filters in the determined order.

[0335] Clause 21: A computer-implemented method comprising: The method includes providing an application programming interface (API) configured for a computing device of the non-connected network to expose a set of filter types.

[0336] The method further includes receiving, via the application programming interface, a selection of one or more filter types from the set of filter types.

[0337] The method further includes receiving, via the application programming interface, an order for the set of filter types.

[0338] The method further includes generating, by a computing device of the non-connected network, a data pipeline including the ordered set of filters in response to a command received via the application programming interface.

[0339] The method further includes a computing device of the non-connected network analyzing the message received at the one-way transmission device by passing the message through the ordered set of filters.

[0340] The method further includes a logging network of the non-connected network receiving a log of events occurring in the data pipeline.

[0341] The method further includes presenting, via the application programming interface, a log of the events.

[0342] The method further includes terminating the data pipeline upon receiving a terminate command via the application programming interface.

[0343] Clause 22: The method of clause 21, wherein the one or more filter types include one or more of a malware filter, a content filter, a signature filter, a content analyzer, a machine learning filter, or an artificial intelligence filter.

[0344] Clause 23: The method of clause 21, further comprising sending the message from the unconnected network to the trusted repository via the one-way transmission device.

[0345] Clause 24: The method according to clause 21, wherein the one-way transmission device is a software-based one-way transmission device.

[0346] Clause 25: The method of clause 21, wherein the log of events includes logs of events occurring at an operating system (OS) level, an application level, and a payload level. Clause 26: The method of clause 21, wherein the non-connected network includes a virtual cloud network.

[0347] Clause 27: The method according to clause 21, wherein the one-way transmission device is a smart network interface card (smart NIC).

[0348] Clause 28: A computer program product comprising instructions tangibly embodied in one or more non-transitory machine-readable media and configured to cause one or more data processors to execute the instructions, The instructions executed by the one or more data processors include providing an application programming interface (API) configured to expose a set of filter types.

[0349] The instructions executed by the one or more data processors further include receiving, via the application programming interface, a selection of one or more filter types from the set of filter types.

[0350] The instructions executed by the one or more data processors further include receiving, via the application programming interface, an order for the set of filter types.

[0351] The instructions executed by the one or more data processors further include, in response to a command received via the application programming interface, generating a data pipeline including the ordered set of filters.

[0352] The instructions executed by the one or more data processors further include analyzing messages received at the one-way transmission device by passing the messages through the ordered set of filters.

[0353] The instructions executed by the one or more data processors further include receiving, via a logging network of the non-connected network, a log of events occurring in the data pipeline.

[0354] The instructions executed by the one or more data processors further include presenting, via the application programming interface, a log of the events.

[0355] The instructions executed by the one or more data processors further include terminating the data pipeline upon receiving a terminate command via the application programming interface.

[0356] Clause 29: The computer program product of clause 28, wherein the one or more filter types include one or more of a malware filter, a content filter, a signature filter, a content analyzer, a machine learning filter, or an artificial intelligence filter.

[0357] Clause 30: The computer program product of clause 28, wherein the set of instructions further comprises sending a message from the disconnected network to the trusted repository via the one-way transmission device.

[0358] Clause 31: The computer program product according to clause 28, wherein the one-way transmission device is a software-based one-way transmission device.

[0359] Clause 32: The computer program product of clause 28, wherein the log of events includes logs of events occurring at an operating system (OS) level, an application level, and a payload level. Clause 33: The computer program product of clause 28, wherein the unconnected network comprises a virtual cloud network.

[0360] Clause 34: The computer-readable storage medium of clause 28, wherein the one-way transmission device is a smart network interface card (smart NIC).

[0361] Clause 35: A system comprising: A memory configured to store a plurality of instructions is provided.

[0362] The system further comprises one or more processors of the computing device of the non-connected network configured to access the memory and to execute the instructions.

[0363] The one or more processors provide an application programming interface (API) configured to expose at least a set of filter types.

[0364] The one or more processors receive, via at least an application programming interface, a selection of one or more filter types from a set of filter types.

[0365] The one or more processors receive at least the order of the set of filter types.

[0366] The one or more processors, at least in response to commands received via the application programming interface, generate a data pipeline that includes the ordered set of filters.

[0367] The one or more processors analyze messages received at the one-way transmission device by passing the messages through at least the ordered set of filters.

[0368] The one or more processors receive, at least via a logging network of the non-connected network, a log of events occurring in the data pipeline.

[0369] The one or more processors at least present a log of events via an application programming interface.

[0370] The one or more processors terminate the data pipeline at least upon receiving a terminate command via the application programming interface.

[0371] Clause 36: The system of clause 35, wherein the one or more filter types include one or more of a malware filter, a content filter, a signature filter, a content analyzer, a machine learning filter, or an artificial intelligence filter.

[0372] Clause 37: The system of clause 35, further comprising sending the message from the unconnected network to the trusted repository via the one-way transmission device.

[0373] Clause 38: The system according to clause 35, wherein the one-way transmission device is a software-based one-way transmission device.

[0374] Clause 39: The system of clause 35, wherein the log of events includes logs of events occurring at an operating system (OS) level, an application level, and a payload level. Clause 40: The system of clause 35, wherein the unconnected network includes a virtual cloud network.< / realm>

Claims

1. A method executed by a computer, comprising: receiving, at a first processing node of a network interface card (NIC) associated with a virtual network, a message sent using a first communication protocol, the destination of which is the virtual network, wherein the network interface card comprises a network virtualization device configured to implement the virtual network operating on a physical network; the method further comprises: sending the message from the first processing node of the network interface card to a second processing node using a second communication protocol configured for unidirectional communication; receiving the message at the second processing node; sending the message from the second processing node to a destination resource of the virtual network using a third communication protocol; A method executed by a computer, further comprising the above steps.

2. The method according to claim 1, wherein the second communication protocol is the User Datagram Protocol (UDP).

3. The method according to claim 1, wherein the network interface card comprises a Smart Network Interface Card (Smart NIC).

4. The method according to claim 1, wherein the virtual network comprises a virtual cloud network.

5. The method according to claim 1, wherein the virtual network is configured not to be connected to a public network.

6. The method according to claim 1, wherein the message is configured to pass through a filter chain after leaving the second processing node and before reaching the destination resource.

7. The method according to claim 1, wherein a connection between the first processing node and the second processing node is established using a network cable.

8. The method according to claim 7, wherein the connection established using the network cable enables bidirectional communication.

9. A computer program for causing one or more data processors to execute the method according to any one of claims 1 to 8.

10. A network interface card (NIC) associated with a virtual network, comprising: a first processing node; a second processing node; A memory storing computer-executable instructions, One or more processors configured to access the first processing node, the second processing node, and the memory and to execute the method according to any one of claims 1 to 8, A network interface card comprising.

Images