Cloud-native feature authentication at Layer 2

Abstract

Embodiments of this disclosure relate to Cloud Native Functionality (CNF) authentication during CNF instantiation and bootstrapping. Embodiments may provide a method that includes: a supplicant sending a message to an authentication unit during the CNF instantiation and bootstrapping stage to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, wherein EAP-TLS authentication is performed on an authentication server based on the message; and the supplicant receiving the result of EAP-TLS authentication from the authentication unit, the result of EAP-TLS authentication being generated on an authentication server, and the authentication unit being configured to control CNF traffic based on the result of EAP-TLS authentication.

Description

Technical Field

[0001] Devices and methods consistent with embodiments of the present disclosure relate to cloud-native function authentication in layer 2 of a cloud-native network platform.

Background Art

[0002] In related technologies, a cloud-native platform can provide various infrastructure, platforms, or software services. To provide such infrastructure, platforms, or software services, cloud-native functions (CNFs) may be implemented, and CNFs may be instantiated and bootstrapped on the cloud-native platform. An operator of the cloud-native platform may have underlying security approaches to protect the CNFs from unauthorized access, breaches, or other cyber threats.

Summary of the Invention

Problems to be Solved by the Invention

[0003] Related technologies do not consider the security of CNF-level authentication by the underlying cloud-native platform when a CNF is onboarded by the cloud-native platform. In particular, related technologies do not support the authentication of CNFs during instantiation and bootstrapping. This leads to the possibility that unauthorized / malicious CNFs may be onboarded onto the cloud-native platform. This may pose a problem in the case of a public cloud platform where multi-tenancy is common and an on-premises cloud infrastructure that may have multiple tenants sharing the same cloud platform. The security problems generated by this potential loophole may affect the stability of the entire cloud platform and the tenants hosted thereon.

[0004] Therefore, a solution is needed that can provide CNF-level authentication during CNF instantiation and bootstrapping. [Means for solving the problem]

[0005] According to embodiments, a system and method are provided for Cloud Native Functionality (CNF) authentication during CNF instantiation and bootstrapping to support a zero-trust container network interface. The system and method may block unauthenticated CNFs to avoid unauthorized access, breaches, and other cyber threats. According to embodiments, a method may be provided which includes: a supplicant sending a message to an authentication unit during the CNF instantiation and bootstrapping stage to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, wherein EAP-TLS authentication is performed on an authentication server based on the message; and the supplicant receiving the result of EAP-TLS authentication from the authentication unit, the result of EAP-TLS authentication being generated on an authentication server, and the authentication unit being configured to control CNF traffic based on the result of EAP-TLS authentication. Therefore, authentication is performed at the Ethernet layer (L2) during the onboarding and instantiation stages for the CNF, and all communications for the CNF (except EAPoL (Extensive Authentication Protocol over LAN)) are blocked by the cloud-native platform, thus providing network isolation for unsuccessful authentication attempts.

[0006] According to one embodiment, a supplicant may be provided that sends a message to the authentication unit during the instantiation and bootstrapping stages of a cloud-native function (CNF) to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and that EAP-TLS authentication is performed on the authentication server based on the message, and that the supplicant receives the result of EAP-TLS authentication from the authentication unit, the result of EAP-TLS authentication is generated on the authentication server, and the authentication unit is configured to control the traffic of the CNF based on the result of EAP-TLS authentication.

[0007] According to one embodiment, a non-temporary computer-readable recording medium may be provided with instructions for performing a method which includes: sending a message to the authentication unit during the instantiation and bootstrapping stages of a cloud-native function (CNF) to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, wherein EAP-TLS authentication is performed on the authentication server based on the message; and receiving the result of EAP-TLS authentication from the authentication unit, the result of EAP-TLS authentication is generated on the authentication server, and the authentication unit is configured to control the traffic of the CNF based on the result of EAP-TLS authentication.

[0008] Additional aspects may be partially presented in the following description, partially revealed from the description, or realized by implementing the embodiments presented in this disclosure. [Brief explanation of the drawing]

[0009] Features, aspects, and advantages of certain exemplary embodiments of the disclosure are described below with reference to the accompanying drawings, where similar reference numerals represent similar elements.

[0010] Figure 1 illustrates a system architecture according to one embodiment in which CNF functions as a supplicant for authentication.

[0011] Figure 2 illustrates a system architecture according to one embodiment in which a container network interface (CNI) plugin functions as a supplicant for authentication.

[0012] Figure 3 illustrates a call flow diagram of a method for CNF authentication in which the CNF functions as a supplicant, according to one embodiment.

[0013] Figures 4A-4B illustrate a call flow diagram of a method for CNF authentication in which a CNI plugin functions as a supplicant, according to one embodiment.

[0014] Figure 5 illustrates a flowchart of a method for CNF certification according to one embodiment.

[0015] Figure 6 illustrates a flowchart of a method for CNF authentication, including bootstrap certificate verification, according to one embodiment.

[0016] Figure 7 is a diagram illustrating an example environment in which the system and / or methods described herein may be implemented.

[0017] Figure 8 shows an example of a device component according to one embodiment. [Modes for carrying out the invention]

[0018] The following detailed descriptions of embodiments refer to the accompanying drawings. The prior disclosures provide examples and descriptions, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and alterations are possible in light of the prior disclosures or may be obtained from the implementations. Furthermore, one or more features or components of one embodiment may be integrated with or combined with other embodiments (or one or more features of other embodiments). In addition, in the flowcharts and descriptions of operations provided below, one or more operations may be omitted, one or more operations may be added, one or more operations may be performed simultaneously (at least partially), and the order of one or more operations may be changed.

[0019] It will become clear that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The specific control hardware or software code used to implement these systems and / or methods is not limiting to the implementation. For this reason, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0020] Even if certain combinations of features are described in the claims and / or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways different from those specifically described in the claims and / or disclosed in the specification. Each of the dependent claims listed below may depend directly on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the group of claims.

[0021] None of the elements, actions, or commands used herein should be interpreted as important or essential unless explicitly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." When only one item is intended, the term "one" or similar is used. Also, as used herein, the terms "has," "have," "having," "include," "including," etc., are intended to be open-ended terms. Furthermore, the phrase "based on" means "at least partially based on" unless explicitly stated otherwise. Additionally, expressions such as "at least one of A and B," "A and / or B," or "at least one of A or B" are understood to include only A, only B, or both A and B.

[0022] The descriptions of the embodiments in this disclosure may include terms and names defined by one or more standardization bodies, such as the 3GPP (3rd Generation Partnership Project), the ETSI (European Telecommunications Standards Institute), and the Open RAN (O-RAN) Alliance. For example, terms such as RFC 5216, EAPoL, and 802.1x, and related features and operations, should be interpreted as consistent with those defined in IEEE specifications unless otherwise specified. Nevertheless, such terms and descriptions are not intended to be exhaustive, and any reasonable variations or changes to those skilled in the art should be understood as being within the scope of this disclosure.

[0023] Embodiments of this disclosure provide methods and systems for providing Cloud Native Functionality (CNF) authentication during the instantiation and bootstrapping stages of a CNF. This may include: a supplicant (which may be the CNF itself or a Container Network Interface (CNI) plugin) sending a message to an authentication unit (which may be a host Layer 2 networking module) during the instantiation and bootstrapping stages of the CNF to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, wherein EAP-TLS authentication is performed on an authentication server based on the message; and the supplicant receiving the result of EAP-TLS authentication from the authentication unit, the result of EAP-TLS authentication being generated on the authentication server, and the authentication unit being configured to control CNF traffic based on the result of EAP-TLS authentication. Therefore, authentication is performed at the Ethernet layer (L2) during the onboarding and instantiation stages for the CNF, and all communications for the CNF (except EAPoL (Extensive Authentication Protocol over LAN)) are blocked by the cloud-native platform, thus providing network isolation for unsuccessful authentication attempts.

[0024] Figure 1 illustrates a system architecture of a system 100 in which a CNF functions as a supplicant for authentication, according to one embodiment. A cloud-native platform host 110, an authentication server 120, and the internet 130 may be provided in the system.

[0025] The cloud-native platform host 110 may include a container runtime 111. The container runtime 111 may function as an 802.1x supplicant and may include multiple CNFs 112 (112-1, 112-2,... 112-N). According to some embodiments (not illustrated in FIG. 1), it should be understood that the CNF 112 may be alternatively configured to function as an 802.1x authentication unit. The CNF may be onboarded (initialized) onto the cloud-native platform host 110 using the container runtime 111 or a container orchestrator. Each CNF may have its own container and may communicate with the 802.1x authentication unit 115 via EAPoL (Extensible Authentication Protocol over LAN) to perform authentication. According to an embodiment, EAPoL may be implemented using an EAP-TLS (Extensible Authentication Protocol-Transport Layer Security) protocol sequence.

[0026] The cloud-native platform host 110 may include a Container Network Interface (CNI) plugin 113. The CNI plugin 113 may be used to implement a cluster network and may also be used to configure communication between containers in the container runtime 111 of the cloud-native platform host 110. The CNI plugin 113 may be able to initialize the CNF 112 as a virtual interface.

[0027] The cloud-native platform host 110 may include a host layer 2 networking module 114. Layer 2 (L2) in this context represents the Ethernet layer. The host layer 2 networking module 114 provides communication with the Internet 130 for the cloud-native platform host 110. The host layer 2 networking module 114 may not allow communication from the CNF 112 (except for EAPoL) until authentication is completed. The host layer 2 networking module 114 may function as an 802.1x authenticator or may be used to implement an authenticator 115. The authenticator 115 may use the EAP-TLS protocol to relay EAP messages from the CNF 112 to the authentication server 120. According to some embodiments (not illustrated in FIG. 1), it should be understood that the host layer 2 networking module 114 may alternatively be configured to implement an 802.1x supplicant.

[0028] The authentication server 120 may receive and communicate with the authenticator 115 using the RADIUS protocol or the Diameter protocol depending on the specific implementation. The authentication server 120 may be used to perform EAP-TLS authentication (e.g., in accordance with the RFC 5216 standard in the IEEE) and may provide (return) the result of the authentication to the authenticator 115. According to an embodiment, the authentication server 120 may require the use of an EAP-TLS certificate.

[0029] FIG. 2 illustrates a system architecture of a system 200 in which a container network interface (CNI) plugin functions as a supplicant for authentication according to an embodiment. The schematic architecture of the system 200 may share similarities with the system 100 described above in FIG. 1, but is mainly different in that the CNI plugin 213 receives a certificate from the CNF 212 and the CNI plugin 213 functions as an 802.1x supplicant. Nevertheless, each element is described below.

[0030] The cloud-native platform host 210 may include a container runtime 211. The container runtime 211 may include multiple CNFs 212 (212-1, 212-2, ..., 212-N). The CNFs 212 may be onboarded (initialized) on the cloud-native platform host 210 using the container runtime 211 or a container orchestrator. Each CNF may have its own container and may communicate with a CNI plugin 213 to perform authentication. According to one embodiment, the CNF 212 may provide a bootstrap transport layer security (TLS) certificate to the CNI plugin 213.

[0031] The cloud-native platform host 210 may include a container network interface (CNI) plugin 213 that functions as an 802.1x supplicant. According to some embodiments (not illustrated in Figure 2), the CNI plugin 213 may be configured to function instead as an 802.1x authentication unit. The CNI plugin 213 may be used to implement a cluster network and may be used to configure communication between containers in the container runtime 211 of the cloud-native platform host 110. The CNI plugin 213 may initialize CNF212 as a virtual interface. The CNI plugin 213 may not allow communication from CNF212 (except EAPoL) until authentication is complete. The CNI plugin 213 may request a bootstrap TLS certificate from CNF212 (e.g., via a GET request) and verify that the received bootstrap TLS certificate conforms to the configured certificate profile. If the bootstrap TLS certificate is invalid, the CNI plugin 213 may log the issue.

[0032] CNI Plugin 213 is merely one example of a supplicant, and it should be understood that supplicants are not necessarily limited to it. Other equivalents and / or variations of the CNI Plugin may be used to implement supplicants, as may be obvious to those skilled in the art.

[0033] According to one embodiment, a strict authentication mode may be implemented that can enable or disable intra-CNF traffic (e.g., communication between different interfaces of the same CNF212). When the strict CNF authentication mode is enabled (on), intra-CNF traffic is permitted, and when the strict CNF authentication mode is disabled (off), intra-CNF traffic is not permitted. A CNI plugin 213 or a similar entity may be configured to implement the strict CNF authentication mode.

[0034] The cloud-native platform host 210 may include a host layer 2 networking module 214. The host layer 2 networking module 214 provides communication with the internet 230 for the cloud-native platform host 210. The host layer 2 networking module 214 may also be used to implement an authentication unit 215, which may function as an 802.1x authentication unit. The authentication unit 215 may use the EAP-TLS protocol to relay EAP messages from the CNF 212 to the authentication server 220. According to some embodiments (not illustrated in Figure 2), the authentication server 220 may be configured to implement an 802.1x supplicant instead.

[0035] The authentication server 220 may, depending on the specific implementation, use the RADIUS protocol or the Diameter protocol to receive and communicate with the authentication unit 215. The authentication server 230 may be used to perform EAP-TLS authentication (for example, according to the IEEE RFC 5216 standard) and may provide (return) the authentication result to the authentication unit 215. According to the embodiment, the authentication server 220 may require the use of an EAP-TLS certificate.

[0036] The embodiments illustrated in Figures 1 and 2 illustrate an example of an architecture in which the CNF 112 or CNI plugin 213 functions as an 802.1x supplicant and the host Layer 2 networking modules 114, 214 implement the 802.1x authentication unit (authentication units 115, 215). However, according to some embodiments, the CNF 112 or CNI plugin 213 may function as the 802.1x authentication unit (for example, the CNF or CNI plugin may communicate with authentication servers 120, 220), and the host Layer 2 networking module 114 may implement the 802.1x supplicant. For example, the CNF may function as the authentication unit in scenarios in which the CNF is intended to establish connections with other CNFs (e.g., inter-CNF communication), inter-service communication, or communication between different tenants in a cloud-native platform.

[0037] Figure 3 illustrates a call flow diagram of Method 300 for CNF authentication, in which the CNF functions as a supplicant, according to one embodiment. Method 300 may be implemented using a system architecture similar to System 100 described above in Figure 1. CNF 310 may function as an 802.1x supplicant, or it may be similar to one of the CNF 112. Host Layer 2 (L2) 320 may function as an 802.1x authentication unit, or it may be similar to the Host Layer 2 networking module 114 and / or authentication unit 115. Authentication server 330 may be similar to authentication server 120.

[0038] Referring to Figure 3, as a prerequisite, an 802.1x supplicant function with EAP-TLS support may be enabled first on CNF310, and similarly, an 802.1x authentication function with EAP-TLS support may be enabled first on "Host L2" 320. The EAP-TLS authentication server details of the authentication server 330 may be configured on "Host L2" 320.

[0039] CNF may be onboarded by a container runtime (such as container runtime 111) or a container orchestrator, and the CNF interface is initialized as a virtual interface by a CNI plugin (e.g., CNI plugin 113). Host L2 320 may not allow traffic from the CNF interface to other services (e.g., excluding EAPoL and EAP-TLS messages) until the authentication process (using 802.1x authentication) is successful.

[0040] Referring to Figure 3, in Operation 1, CNF310 may initiate an EAP-TLS protocol sequence with "Host L2" 320. This may include sending a message to "Host L2" 320. Upon receiving this message, an EAP-TLS message exchange may occur between CNF310 (802.1x supplicant), "Host L2" 320 (802.1x authentication unit), and authentication server 330, in accordance with the relevant standard (e.g., RFC 5216).

[0041] Once the authentication procedure using EAP-TLS message exchange is complete, in Operation 2, the result of the EAP-TLS authentication (which may indicate whether EAP-TLS was successful or failed) is returned by the authentication server 330 to the "Host L2" 320. In Operation 3, the result of the EAP-TLS authentication may be forwarded by the "Host L2" 320 to the CNF 310.

[0042] If EAP-TLS authentication is successful (Case A (see Figure 3)), Host L2 320 may allow traffic from all CNF interfaces to internal / external destinations and may log the success of CNF authentication.

[0043] If EAP-TLS authentication fails (Case B (see Figure 3)), Host L2 320 may block traffic to and from all interfaces of CNF and may log the authentication failure of CNF.

[0044] Figures 4A-4B illustrate a call flow diagram of Method 400 for CNF authentication, according to one embodiment, in which a CNI plugin functions as a supplicant. Method 400 may be implemented using a system architecture similar to that of System 200 described in Figure 2. CNF 410 may be similar to one of CNF 212. CNI plugin 420 may function as an 802.1x supplicant, or it may be similar to CNI plugin 213. Host Layer 2 (L2) 430 may function as an 802.1x authentication unit, or it may be similar to Host Layer 2 networking module 214 and / or authentication unit 215. Authentication server 440 may be similar to authentication server 220.

[0045] Referring to Figure 4A, as a prerequisite, an 802.1x supplicant function with EAP-TLS support may be initially enabled in the CNI plugin 420, and similarly, an 802.1x authentication function with EAP-TLS support may be initially enabled in the "Host L2" 430. A strict CNF authentication mode may be configured in the CNI plugin 420 (on / enabled or off / disabled). The EAP-TLS authentication server details for the authentication server 330 may be configured in the "Host L2" 430.

[0046] CNF may be onboarded by a container runtime (such as container runtime 211) or a container orchestrator, and the CNF interface is initialized as a virtual interface by CNI plugin 420. CNI plugin 420 may not allow traffic from the CNF interface to other services (e.g., excluding EAPoL and EAP-TLS messages) until the authentication process (using 802.1x authentication) is successful.

[0047] Referring to Figure 4A, if the strict CNF authentication mode is disabled (Case A (see Figure 4A)), Operation 1 allows intra-CNF traffic. This is to allow CNF initialization to be accelerated before external traffic is allowed for CNF410. However, if the strict CNF authentication mode is enabled (Case B (see Figure 4A)), Operation 2 does not allow intra-CNF traffic.

[0048] In Operation 3, CNI Plugin 420 may request the bootstrap TLS certificate from CNF410 (using a GET request). In Operation 4, CNI Plugin 420 may provide the requested bootstrap TLS certificate. Thus, CNI Plugin 420 may check whether the bootstrap TLS certificate conforms to the configured certificate profile.

[0049] Referring to Figure 4B, the CNI plugin 420 may determine based on whether it has checked whether the bootstrap TLS certificate conforms to the certificate profile. If it does not conform to the configured certificate profile (Case C (see Figure 4B)), the CNI plugin 420 does not initiate the EAP-TLS procedure and logs the certificate issue. No further actions may be taken thereafter, and the authentication procedure may not occur.

[0050] On the other hand, if the bootstrap TLS certificate is compatible with the configured certificate profile (Case D (see Figure 4B)), the CNI plugin 420 may proceed with the EAP-TLS procedure.

[0051] Referring to Figure 4B, in Operation 5, the CNI plugin 420 may initiate an EAP-TLS protocol sequence with the "Host L2" 430. This may include sending a message to the "Host L2" 430. Upon receiving this message, an EAP-TLS message exchange may occur between the CNI plugin 420 (802.1x supplicant), the "Host L2" 430 (802.1x authentication unit), and the authentication server 440, in accordance with the relevant standard (e.g., RFC 5216). The CNF 410 does not send or receive EAP-TLS messages during this process.

[0052] Once the authentication procedure using EAP-TLS message exchange is complete, in Operation 6, the result of the EAP-TLS authentication (which may indicate whether EAP-TLS was successful or failed) is returned from the authentication server 440 to the "Host L2" 430. In Operation 7, the result of the EAP-TLS authentication may be forwarded by the "Host L2" 430 to the CNI plugin 420.

[0053] If EAP-TLS authentication is successful (Case E (see Figure 4B)), the CNI plugin 420 may allow traffic from all CNF interfaces to internal / external destinations and may log the success of CNF authentication.

[0054] If EAP-TLS authentication fails (Case F (see Figure 4B)), the CNI plugin 420 may block traffic to and from all interfaces of the CNF and may log the authentication failure of the CNF. A security alert may also be issued by the CNI plugin 420.

[0055] Figure 5 illustrates a flowchart of Method 500 for CNF authentication according to one embodiment. Method 500 generalizes the message exchange that occurs between the supplicant and the authentication unit and may include operations 1-3 from Method 300 (see Figure 3) and / or operations 5-7 from Method 400 (see Figure 4B).

[0056] In Operation 501, the supplicant (e.g., CNF112, 212, or CNI plugin 213, as described above) may send a message to the authentication unit (e.g., a host L2 networking module similar to the host Layer 2 networking modules 114, 214, as described above) to initiate the EAP-TLS protocol. This may occur during the instantiation and bootstrapping stages of the CNF. Upon receiving the message, the authentication unit may perform EAP-TLS authentication using an authentication server (e.g., authentication servers 120, 220, as described above).

[0057] In Operation 502, the supplicant may receive the EAP-TLS authentication result, which may be generated by the authentication server, from the authentication unit. The authentication unit is configured to control CNF traffic based on the EAP-TLS authentication result. That is, if the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from all interfaces of the CNF; if it fails, the authentication unit is configured to block traffic from all interfaces of the CNF. According to some embodiments, the authentication unit may log the authentication result.

[0058] Figure 6 illustrates a flowchart of Method 600 for CNF authentication, including bootstrap certificate verification, according to one embodiment. Method 600 is an embodiment in which the supplicant is a CNI plugin. Method 600 may also encompass operations 1-7 from Method 400 (see Figures 4A and 4B).

[0059] In Operation 601, before sending a message, the supplicant (e.g., CNI plugin 213) verifies whether the bootstrap TLS certificate received from the CNF (e.g., CNF212) conforms to the configured certificate profile. If not, Operation 602 may occur, in which the supplicant may not send a message, a certificate issue may be logged, and the process may subsequently terminate.

[0060] On the other hand, if the CNF conforms to the configured certificate profile and is verified by the supplicant, operation 603 may cause the supplicant to send a message to the authentication unit (e.g., a host L2 networking module similar to the host Layer 2 networking module 214 described above) to initiate the EAP-TLS protocol. This may occur during the instantiation and bootstrapping stages of the CNF. Upon receiving the message, the authentication unit may perform EAP-TLS authentication using an authentication server (e.g., an authentication server 220 as described above).

[0061] In Operation 604, the supplicant may receive the results of EAP-TLS authentication, which may be generated by the authentication server, from the authentication unit. The authentication unit is configured to control CNF traffic based on the results of EAP-TLS authentication. Specifically, if the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from all interfaces of the CNF; if it fails, the authentication unit is configured to block traffic from all interfaces of the CNF.

[0062] Therefore, authentication is performed at the Ethernet layer (L2) during the onboarding and instantiation stages for the CNF, and all communications for the CNF (except EAPoL (Extensive Authentication Protocol over LAN)) are blocked by the cloud-native platform, thus providing network isolation for unsuccessful authentication attempts.

[0063] Figure 7 is a diagram of an example environment 700 in which the system and / or method described herein may be implemented. As shown in Figure 7, the environment 700 may include a user device 710, a platform 720, and a network 730. The devices in environment 700 may be interconnected via wired connections, wireless connections, or a combination of wired and wireless connections. In embodiments, any functions and operations described later with reference to Figure 1 above may be performed by any combination of the elements illustrated in Figure 7.

[0064] User device 710 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information related to platform 720. For example, user device 710 may include computing devices (e.g., desktop computers, laptop computers, tablet computers, handheld computers, smart speakers, servers, etc.), mobile phones (e.g., smartphones, wireless phones), wearable devices (e.g., smart glasses or smartwatches), or similar devices. In some implementations, user device 710 may receive information from and / or transmit information to platform 720.

[0065] Platform 720 includes one or more devices capable of receiving, generating, storing, processing, and / or providing information. In some implementations, Platform 720 may include a cloud server or a group of cloud servers. In some implementations, Platform 720 may be designed to be modular so that certain software components can be swapped (in or out) depending on specific needs. Thus, Platform 720 may be easily and / or quickly reconfigured for different applications.

[0066] In some implementations, as shown, platform 720 may be hosted in a cloud computing environment 722. Although the implementations described herein describe platform 720 as being hosted in a cloud computing environment 722, in some implementations, platform 720 may not be cloud-based (i.e., it may be implemented outside a cloud computing environment) or may be partially cloud-based.

[0067] The cloud computing environment 722 includes an environment that hosts platform 720. The cloud computing environment 722 may provide services that do not require end-user (e.g., user device 710) knowledge of the physical location and configuration of the systems and / or devices that host platform 720, such as computation, software, data access, and storage. As shown, the cloud computing environment 722 may also include a group of computing resources 724 (collectively referred to as “computing resources 724” and individually as “computing resources 724”).

[0068] Computing resource 724 includes one or more personal computers, a cluster of computing devices, a workstation computer, a server device, or other types of computing and / or communication devices. In some implementations, computing resource 724 may host platform 720. Cloud resources may include compute instances running in computing resource 724, storage devices provided in computing resource 724, data transfer devices provided by computing resource 724, etc. In some implementations, computing resource 724 may communicate with other computing resources 724 via wired connections, wireless connections, or a combination of wired and wireless connections.

[0069] As further shown in Figure 7, the computing resources 724 include a group of cloud resources such as one or more applications ("APP") 724-1, one or more virtual machines ("VM") 724-2, virtualized storage ("VS") 724-3, and one or more hypervisors ("HYP") 724-4. One or more embodiments are understood to be not limited to a specific type of cloud computing environment and may be implemented on one or more servers in the form of virtualized network functions (VNF), containerized and / or cloud-native functions (CNF), etc.

[0070] Application 724-1 includes one or more software applications that may be provided to or accessed by the user device 710. Application 724-1 may eliminate the need to install and run software applications on the user device 710. For example, Application 724-1 may include any other software that can be provided via the platform 720 and its associated software and / or the cloud computing environment 722. In some implementations, one application 724-1 may send and receive information to and from one or more other applications 724-1 via a virtual machine 724-2.

[0071] The virtual machine 724-2 includes a software implementation of a device (e.g., a computer) that runs programs like a physical device. Depending on the degree to which the virtual machine 724-2 is used and its correspondence to any real-world device, the virtual machine 724-2 may be a system virtual machine or a process virtual machine. A system virtual machine may provide a complete system platform that supports the execution of a complete operating system ("OS"). A process virtual machine may run a single program or support a single process. In some implementations, the virtual machine 724-2 may run on behalf of a user (e.g., a user device 710) and manage the infrastructure of a cloud computing environment 722, such as data management, synchronization, or long-duration data transfer.

[0072] Virtualized storage 724-3 includes one or more storage systems and / or one or more devices or computing resources 724 that use virtualization technology within the storage systems. In some implementations, within the context of the storage system, the types of virtualization may include block virtualization and file virtualization. Block virtualization may represent an abstraction (or isolation) of logical storage from physical storage so that the storage system may be accessed without considering the physical storage or heterogeneous structure. Isolation can provide administrators of the storage system with flexibility in managing storage for end users. File virtualization may remove the dependency between data accessed at the file level and the location where the files are physically stored. This may enable optimized storage usage, server consolidation, and / or performance of non-destructive file migration.

[0073] The hypervisor 724-4 may provide hardware virtualization technology that enables multiple operating systems (e.g., "guest operating systems") to run simultaneously on a host computer such as computing resource 724. The hypervisor 724-4 may present a virtual operating platform to the guest operating systems and may manage the execution of the guest operating systems. Multiple instances of various operating systems may share virtualized hardware resources.

[0074] Network 730 includes one or more wired and / or wireless networks. For example, Network 730 may include cellular networks (e.g., 5G networks, LTE (long-term evolution) networks, 3G networks, CDMA (code division multiple access) networks, etc.), PLMN (public land mobile network), local area networks (LANs), wide area networks (WANs), MAN (metropolitan area networks), telephone networks (e.g., PSTN (Public Switched Telephone Network), private networks, ad hoc networks, intranets, the Internet, fiber optic networks, etc.), and / or combinations of these or other types of networks.

[0075] The number and arrangement of devices and networks shown in Figure 7 are provided as an example. In practice, there may be additional devices and / or networks, fewer devices and / or networks, different devices and / or networks, or devices and / or networks in different arrangements than those shown in Figure 7. Furthermore, two or more devices shown in Figure 7 may be implemented within a single device, and a single device shown in Figure 7 may be implemented as multiple distributed devices. In addition or alternatively, a set of devices in environment 700 (e.g., one or more devices) may perform one or more functions that are described as being performed by other sets of devices in environment 700.

[0076] In some embodiments, the authentication process described herein (or one or more operations associated therewith) may be implemented or deployed on the aforementioned server platform in the form of a virtualized network function (VNF). In this regard, the terms "virtual," "virtualized," etc., as used herein are understood to be merely for the purpose of indicating the nature of a machine (and associated elements and resources) provided in a virtual or software form. In this regard, the terms "virtual machine," "virtualized storage," etc., as used herein should not be limited to a specific type of virtual machine or virtual element. Therefore, it can be understood that it (or operations associated therewith) may be defined or presented in the form of a containerized network function, whose functionality may be provided in the form of a container.

[0077] Figure 8 shows an example of the components of device 800. Device 800 may correspond to user device 710 and / or platform 720. As shown in Figure 8, device 800 may include a bus 810, a processor 820, memory 830, a storage component 840, an input component 850, an output component 860, and a communication interface 870.

[0078] Bus 810 includes components that enable communication between components of device 800. Processor 820 may be implemented in hardware, firmware, or a combination of hardware and software. Processor 820 may be a central processing unit (CPU), graphics processing unit (GPU), acceleration unit (APU), microprocessor, microcontroller, digital signal processor (DSP), FPGA (field-programmable gate array), ASIC (application-specific integrated circuit), or other types of processing components. In some implementations, processor 820 includes one or more processors that are programmable to perform functions. Memory 830 includes random access memory (RAM), read-only memory (ROM), and / or other types of dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory) that store information and / or instructions for use by processor 820.

[0079] The storage component 840 stores information and / or software related to the operation and use of device 800. For example, the storage component 840 may include, along with a corresponding drive, a hard disk (e.g., magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, magnetic tape, and / or other types of non-temporary computer-readable media. The input component 850 includes components that enable device 800 to receive information via user input (e.g., a touchscreen display, keyboard, keypad, mouse, buttons, switches, and / or a microphone), etc. In addition or alternatively, the input component 850 may include sensors for measuring information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, and / or actuators). The output component 860 includes components that provide output information from device 800 (e.g., a display, a speaker, and / or one or more light-emitting diodes (LEDs)).

[0080] The communication interface 870 includes transceiver-like components (e.g., a transceiver and / or separate receiver and transmitter) that enable device 800 to communicate with other devices via wired connections, wireless connections, or a combination of wired and wireless connections. The communication interface 870 enables device 800 to receive information from and / or provide information to other devices. For example, the communication interface 870 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a Universal Serial Bus (USB) interface, a Wi-Fi interface, a cellular network interface, and the like.

[0081] Device 800 may execute one or more processes described herein. Device 800 may execute these processes depending on a processor 820 that executes software instructions stored in a non-temporary computer-readable medium such as memory 830 and / or storage component 840. The computer-readable medium is defined herein as a non-temporary memory device. A memory device includes a memory space within a single physical storage device or a memory space distributed across multiple physical storage devices.

[0082] Software instructions may be read into memory 830 and / or storage component 840 from other computer-readable media or other devices via the communication interface 870. When executed, the software instructions stored in memory 830 and / or storage component 840 may cause the processor 820 to execute one or more processes described herein.

[0083] In addition, or instead of, wired circuits may be used to execute one or more of the processes described herein, either in place of or in combination with software instructions. Thus, the implementations described herein are not limited to any particular combination of hardware circuits and software.

[0084] The number and arrangement of components shown in Figure 8 are provided as an example. In practice, device 800 may include additional components, fewer components, different components, or components in different arrangements than those shown in Figure 8. In addition or alternatively, a set of components of device 800 (e.g., one or more components) may perform one or more functions that are described as being performed by other sets of components of device 800.

[0085] In the embodiments, any operation or process in Figures 1-6 may be implemented by or using any elements illustrated in Figures 7 and 8. Other embodiments are understood to be, but are not limited thereto, and may be implemented in various different architectures (e.g., bare metal architecture, any cloud-based architecture, or deployment architectures such as Kubernetes, Docker, or OpenStack).

[0086] The foregoing disclosures are illustrative and descriptive, but are not intended to be exhaustive or to limit implementations to the exact forms disclosed. Modifications and variations are possible in light of the foregoing disclosures or may be derived from the execution of implementations.

[0087] Some embodiments may also relate to systems, methods, and / or computer-readable media at a technical level of any possible integration. Furthermore, one or more of the above components may be implemented as instructions that are stored on a computer-readable medium and are executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-temporary storage medium (or medium) that stores computer-readable program instructions for causing a processor to perform an operation.

[0088] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital multipurpose disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or grooves on which instructions are recorded, or any suitable combination thereof. The computer-readable storage medium used herein is not to be interpreted as a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmitting media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0089] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device, or downloaded to an external computer or external storage device via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers them to storage in the computer-readable storage medium within each computing / processing device.

[0090] The computer-readable program code / instructions for performing the operation may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, procedural programming languages ​​such as the C programming language, or similar programming languages. The computer-readable program instructions may be executed as a standalone software package, either entirely on the user's computer, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), and the connection may be to an external computer (for example, via the Internet using an Internet Service Provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, an FPGA (field-programmable gate array), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of computer-readable program instructions to personalize the electronic circuit in order to perform a side or operation.

[0091] These computer-readable program instructions may be provided to a general-purpose computer, a dedicated computer, or a processor of another programmable data processing device to generate a device such that instructions executed via the processor of a computer or other programmable data processing device generate means for implementing functions / actions described in flowcharts and / or block diagrams (one or more blocks). These computer-readable program instructions may be stored on a computer-readable storage medium on which the instructions are stored, which can be instructed to make a computer, a programmable data processing device, and / or other device function in a particular manner such that the storage medium containing the instructions has a creation containing instructions that implement aspects of functions / actions described in flowcharts and / or block diagrams (one or more blocks).

[0092] Computer-readable program instructions may be loaded onto a computer, another programmable device, or another device so that a series of operational steps are executed on the computer, another programmable device, or other device to generate a computer-implemented process in which instructions executed on the computer, another programmable device, or other device implement a function / action described in a flowchart and / or block diagram (one or more blocks).

[0093] The illustrated flowcharts and block diagrams illustrate the architecture, functions, and operations of possible implementations of systems, methods, and computer-readable media according to various embodiments. Here, each block in the flowchart or block diagram may represent a microservice, module, segment, or portion of instructions comprising one or more executable instructions to implement a particular logical function. The methods, computer systems, and computer-readable media may include additional blocks, fewer blocks, different blocks, or different arrangements of blocks than those shown in the diagrams. In some alternative implementations, the functions shown in the blocks may occur outside the order shown in the diagrams. For example, two blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, depending on the functions involved, or the blocks may be executed in reverse order. Note that each block in the illustrated block diagrams and / or flowcharts, and combinations of blocks in the illustrated block diagrams and / or flowcharts, may be implemented by a system based on dedicated hardware that performs a particular function or action, or by executing a combination of dedicated hardware and computer instructions.

[0094] It is evident that the systems and / or methods described herein may be implemented in different forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement these systems and / or methods is not limited to the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code. It is understood that software and hardware may be designed to implement the systems and / or methods based on the descriptions herein.

[0095] In view of the foregoing, various further aspects and features of the embodiments of this disclosure may be defined by the following items. Item 1: The supplicant sends a message to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate the Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The supplicant is configured to receive the EAP-TLS authentication result from the authentication unit, the EAP-TLS authentication result is generated by the authentication server, and the authentication unit controls the CNF traffic based on the EAP-TLS authentication result. A method that includes this. Item 2: The method according to item 1, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF. Item 3: The method according to item 2, wherein the authentication unit is the CNF and the supplicant is a host layer 2 (L2) networking module. Item 4: If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. The method described in item 1 or 2. Item 5: Before sending the aforementioned message, the supplicant further includes verifying whether the bootstrap transport layer security (TLS) certificate from the CNF conforms to the certificate profile. If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent, and the certificate issue is logged by the supplicant. The method described in any of items 1 through 4. Item 6: The method according to item 1, 4, or 5, wherein the authentication unit is a host Layer 2 (L2) networking module, and the supplicant is a container network interface (CNI) plugin. Item 7: The method according to item 6, wherein, based on the configuration of a strict CNF authentication mode in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful. Item 8: A message is sent to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate the Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The authentication unit receives the result of the EAP-TLS authentication, the authentication server generates the result of the EAP-TLS authentication, and the authentication unit is configured to control the traffic of the CNF based on the result of the EAP-TLS authentication. A supplicant configured to perform the following actions. Item 9: The authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF, as described in item 8. Item 10: The authentication unit is the CNF, and the supplicant is the host Layer 2 (L2) networking module, as described in item 8. Item 11: If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. Supplements as listed in item 8 or 9. Item 12: Before sending the aforementioned message, the bootstrap transport layer security (TLS) certificate from the CNF is further configured to verify whether it conforms to the certificate profile. If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent and the system is further configured to log the certificate issue. A supplement listed in any of items 8 through 11. Item 13: The authentication unit is a host Layer 2 (L2) networking module, and the supplicant is a container network interface (CNI) plugin, as described in item 8, 11, or 12. Item 14: A supplicant as described in item 13, in which, based on the configuration of a strict CNF authentication mode in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful. Item 15: The supplicant sends a message to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate the Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The supplicant is configured to receive the EAP-TLS authentication result from the authentication unit, the EAP-TLS authentication result is generated by the authentication server, and the authentication unit controls the CNF traffic based on the EAP-TLS authentication result. A non-temporary computer-readable recording medium that stores instructions for performing a method including [a specific method]. Item 16: The authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF, as described in item 15, for a non-temporary computer-readable recording medium. Item 17: The authentication unit is the CNF, and the supplicant is a host layer 2 (L2) networking module, as described in item 15, for a non-temporary computer-readable recording medium. Item 18: If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. Non-temporary computer-readable recording media as described in item 15 or 16. Item 19: Before sending the aforementioned message, the supplicant further includes verifying whether the bootstrap transport layer security (TLS) certificate from the CNF conforms to the certificate profile. If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent, and the method further comprises logging the certificate issue by the supplicant, the supplicant being a container network interface (CNI) plugin. A non-temporary computer-readable recording medium as described in any of items 15 to 18. Item 20: The authentication unit is a host Layer 2 (L2) networking module, the supplicant is a container network interface (CNI) plugin, and based on the fact that a strict CNF authentication mode is configured in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful, the non-temporary computer-readable recording medium as described in item 19.

[0096] In light of the above teachings, it can be understood that many modifications and alterations of this disclosure are possible. It is clear that, within the scope of the attached items, this disclosure may be implemented in a manner different from that specifically described herein.

Claims

1. The supplicant sends a message to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The supplicant is configured to receive the EAP-TLS authentication result from the authentication unit, the EAP-TLS authentication result is generated by the authentication server, and the authentication unit controls the CNF traffic based on the EAP-TLS authentication result. A method for providing this.

2. The method according to claim 1, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF.

3. The method according to claim 1, wherein the authentication unit is the CNF and the supplicant is a host layer 2 (L2) networking module.

4. If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. The method according to claim 1.

5. Before sending the aforementioned message, the supplicant further includes verifying whether the bootstrap transport layer security (TLS) certificate from the CNF conforms to the certificate profile, If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent, and the certificate issue is logged by the supplicant. The method according to claim 1.

6. The method according to claim 5, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is a container network interface (CNI) plugin.

7. The method according to claim 6, wherein, based on the configuration of a strict CNF authentication mode in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful.

8. A message is sent to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate the Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The authentication unit receives the result of the EAP-TLS authentication, the authentication server generates the result of the EAP-TLS authentication, and the authentication unit is configured to control the traffic of the CNF based on the result of the EAP-TLS authentication. A supplicant configured to perform the following actions.

9. The supplicant according to claim 8, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF.

10. The supplicant according to claim 8, wherein the authentication unit is the CNF, and the supplicant is a host layer 2 (L2) networking module.

11. If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. The supplementant according to claim 8.

12. Before sending the aforementioned message, the bootstrap transport layer security (TLS) certificate from the CNF is further configured to verify whether it conforms to the certificate profile. If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent, and the system is further configured to log the certificate issue, and the supplicant is a container network interface (CNI) plugin. The supplementant according to claim 8.

13. The supplicant according to claim 12, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is a container network interface (CNI) plugin.

14. The supplicant according to claim 13, wherein, based on the configuration of a strict CNF authentication mode in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful.

15. The supplicant sends a message to the authentication unit during the instantiation and bootstrapping stages of the Cloud Native Function (CNF) to initiate an Extensible Authentication Protocol Transport Layer Security (EAP-TLS) protocol sequence, and EAP-TLS authentication is performed by the authentication server based on the message. The supplicant is configured to receive the EAP-TLS authentication result from the authentication unit, the EAP-TLS authentication result is generated by the authentication server, and the authentication unit controls the CNF traffic based on the EAP-TLS authentication result. A non-temporary computer-readable recording medium that records instructions for performing a method comprising [a certain feature].

16. The non-temporary computer-readable recording medium according to claim 15, wherein the authentication unit is a host layer 2 (L2) networking module, and the supplicant is the CNF.

17. The non-temporary computer-readable recording medium according to claim 15, wherein the authentication unit is the CNF, and the supplicant is a host layer 2 (L2) networking module.

18. If the EAP-TLS authentication is successful, the authentication unit is configured to allow traffic from the CNF. If the EAP-TLS authentication fails, the authentication unit is configured to block traffic from the CNF. The non-temporary computer-readable recording medium according to claim 15.

19. The method further comprises, before sending the message, the supplicant verifying whether the bootstrap transport layer security (TLS) certificate from the CNF conforms to the certificate profile, If the bootstrap TLS certificate from the CNF does not conform to the certificate profile, the message is not sent, and the certificate issue is logged by the supplicant. The non-temporary computer-readable recording medium according to claim 15.

20. The non-temporary computer-readable recording medium according to claim 19, wherein the authentication unit is a host layer 2 (L2) networking module, the supplicant is a container network interface (CNI) plugin, and based on the fact that a strict CNF authentication mode is configured in the CNI plugin, CNF traffic is not permitted for the CNF until the EAP-TLS authentication is successful.

Images