Crowd-sourced container anomaly detection

Abstract

Generally discussed herein are devices, systems, and methods for secure container operations. A behavior profile of normal container operations can be generated, such as by using crowd-sourced data. A container monitor can provide a container action of an application in a deployed container. The container action can be compared to a behavior profile indicative of normal behavior of the container. A communication can be responsive to the container action and the normal behavior of the behavior profile not being consistent. The container can be suspended to stop abnormal behavior.

Description

Background Technology

[0001] A container is a deployed instance of a container image. Developers create container images that include all the resources needed for an application to operate within the container. The container is then deployed, and users can access the functionality of the application within it.

[0002] More and more organizations are using containers for their application deployments. Compared to other application deployments, such as virtual machines (VMs), containers offer a faster deployment process, simpler maintenance, and easier development. Containers can reduce costs by decreasing the maintenance and computing resources required to operate and maintain them. Malicious actors familiar with this trend of container usage are attempting to use these containers as new attack vectors. These malicious actors are looking for ways to exploit these container resources for their malicious purposes. Summary of the Invention

[0003] This summary provides a simplified description of aspects of the embodiments, which will be further explained in the detailed description. This summary is not intended to identify essential or mandatory features of the claimed subject matter, and the combinations and order of elements listed in the summary are not intended to limit the elements of the claimed subject matter.

[0004] This article generally discusses the devices, systems, machine-readable media, and methods for secure container operations. Behavioral profiles for normal container operation can be generated, for example, by using crowdsourced data. Container monitors can provide container actions of applications deployed in containers. Container actions can be compared to behavioral profiles indicating normal container behavior. In response to inconsistencies between container actions and the normal behavior profile, communication can be initiated. Containers can be paused to stop anomalous behavior.

[0005] A system for operating secure containers may include processing circuitry and a memory device coupled to a processor. The memory device includes instructions stored thereon for execution by the processing circuitry to perform operations for container monitoring. Operations may include receiving container actions from an application operating within a deployed container from a container monitor. Operations may include comparing the container actions with a behavior profile indicating normal behavior of the container. Operations may include issuing a communication or pausing the container in response to a discrepancy between the container actions and the normal behavior profile.

[0006] A behavior profile includes data indicating the port number of a port accessed by an application within the container or the procedure called by an application within the container. Container actions can indicate the port number of a port accessed by an application within the container or the procedure called by an application within the container. A behavior profile includes data indicating the actions performed by an application within the container and a percentage indicating the number of containers built from the same container image that demonstrate the behavior.

[0007] The operation may further include filtering container actions associated with container action types not in the behavior profile before comparing container actions with the behavior profile. Comparing container actions with the behavior profile includes generating feature vectors based on the container actions and using a machine learning classifier trained on normal container actions to generate labels based on the feature vectors indicating whether the application in the container is operating inconsistently with normal container actions. Attached Figure Description

[0008] Figure 1 A high-level diagram illustrating an example of a virtual machine architecture is provided.

[0009] Figure 2 A high-level diagram illustrating an example of a container architecture is provided.

[0010] Figure 3 An example diagram illustrating an embodiment of a container system is provided.

[0011] Figure 4 An example diagram illustrating an embodiment of a method for identifying and responding to abnormal container behavior is provided.

[0012] Figure 5 The following illustration demonstrates how to generate a behavior profile (execution). Figure 4 A diagram illustrating an embodiment of the system (operation).

[0013] Figure 6 The illustration shows an example of what is used for behavior monitoring (execution). Figure 4 A diagram illustrating an embodiment of the system (operation).

[0014] Figure 7 A block diagram illustrating an embodiment of a machine (e.g., a computer system) for implementing one or more embodiments is shown by way of example. Detailed Implementation

[0015] In the following description, reference is made to the accompanying drawings, which form a part of this document. The drawings illustrate specific embodiments that can be practiced by way of illustration. These embodiments are described in sufficient detail to enable those skilled in the art to practice them. It should be understood that other embodiments can be utilized and structural, logical, and / or electrical changes can be made without departing from the scope of the embodiments. Therefore, the following description of the embodiments should not be construed as limiting, and the scope of the embodiments is defined by the appended claims.

[0016] In some embodiments, the operations, functions, or methods described herein may be implemented in software. The software may include computer-executable instructions stored on a computer or other machine-readable medium or storage device, such as one or more non-transitory memories (e.g., non-transitory machine-readable media) or other types of hardware-based storage devices, local or networked storage devices. Furthermore, such functionality may correspond to a subsystem, which may be software, hardware, firmware, or a combination thereof. Multiple functions may be executed as needed in one or more subsystems, and the described embodiments are merely examples. The software may be executed on a digital signal processor, application-specific integrated circuit (ASIC), microprocessor, central processing unit (CPU), graphics processing unit (GPU), field-programmable gate array (FPGA), or other types of processors running on computing systems such as personal computers, servers, or other computer systems that transform such computer systems into specially programmed machines. Functions or algorithms may be implemented using processing circuitry. Processing circuitry may include electrical and / or electronic components. Electrical and / or electronic components may include one or more of the following: transistors, resistors, capacitors, inductors, amplifiers, modulators, demodulators, antennas, radios, regulators, diodes, oscillators, multiplexers, logic gates, buffers, caches, memory, GPUs, CPUs, FPGAs, ASICs, etc.

[0017] A container is a set of resources that operates on an operating system (or a guest operating system) to provide operations defined by the corresponding container image. Containers can run inside a virtual machine (VM). This operation can create multiple hosts with multiple operating systems supporting multiple containers. Therefore, containers can share physical resources without depending on other applications using the same operating system.

[0018] Attack scenarios involving the use of containers include malicious actors gaining access to containers (e.g., in the "cloud") and using them for malicious (e.g., unintentional or unauthorized) purposes, such as botnets. The embodiments described herein may use crowdsourcing (e.g., from the cloud) to learn the typical behavior of deployed public containers using public container images.

[0019] The cloud is a global network of servers accessible via the internet, providing a variety of hardware and software services. These servers are designed to store and manage data, run applications, or deliver content or services. Services may include streaming video, webmail, office productivity software, or social media. Unlike accessing files and data from a local or personal computer, cloud data is accessed online from internet-enabled devices.

[0020] The implementation can issue alerts in response to the detection of unexpected actions. The implementation can allow learned knowledge to be transferred across entities. When a container is executing and exhibiting unexpected behavior, a specific entity (existing or new) using a container deployed based on a container image can be alerted. Monitored behavior can be learned based on the actions of containers deployed using container images of other entities.

[0021] Figure 1 A high-level diagram illustrating an embodiment of virtual machine architecture 100 is provided as an example. Figure 2 High-level diagrams illustrating an embodiment of container architecture 200 are provided as examples. These diagrams are offered to help understand the context of containers and to highlight the differences between virtual machines (VMs) and containers.

[0022] The VM architecture 100 shown in the figure includes applications 102A and 102B, which rely on corresponding libraries 104A and 104B for operation. Applications 102A-102B operate on corresponding guest operating systems (OS) 106A and 106B. Guest OS 106A-106B operate on hypervisor 108. Hypervisor 108 can operate on computer or network infrastructure 110. Guest OS 106A, libraries 104A, and applications 102A form a VM virtualized by hypervisor 108. Each VM includes a unique instance of OS 106A-106B. Each VM includes its own binary("bin") files, library(s), and the applications(s) it serves. Generally, the VM operating on hypervisor 108 emulates a hardware system.

[0023] While VM architecture 100 offers advantages over applications operating on hardware, it also has disadvantages compared to other application deployment architectures. For example, each VM consumes an excessive amount of memory space. This is at least in part due to each OS 106A-106B operating on its own VM. VM startup times are too long, at least in part due to booting OS 106A-106B. VM download times are also too long, at least in part due to the data required by OS 106A-106B. Other disadvantages of VMs are not specifically described here.

[0024] Container architecture 200 overcomes one or more of the drawbacks of VM architecture 100. In container architecture 200, applications 102A-102B use libraries 104A-104B and operate on container engine 212, sometimes referred to as the runtime environment. Container engine 212 is hosted by OS 214 operating on infrastructure 110. A container includes applications 102A-102B and libraries 104A-104B, along with other configuration files required to operate applications 102A-102B. Containers are generally deployments of container images.

[0025] The container and image frameworks used for application deployment currently have security flaws. For example, organizations currently monitor for spoofed container images and train users on best practices when they pull from public repositories. To help avoid this problem, organizations can create a limited list of available images. However, even with this limited set of available images, malicious actors can deploy malicious images that, when deployed, operate for malicious purposes. Other container security relies on digital signatures to help verify that image files downloaded from public repositories are in their original state and have not been altered. However, this added authenticity verification does not prevent the creation or distribution of malware. Better container security is needed and beneficial.

[0026] Containers are distinct from legacy or traditional application deployments. Generally, in the context of containers, terms like "legacy" or "traditional" refer to the infrastructure where applications are executed directly on VMs or bare metal servers. However, VMs or bare metal servers can be used within containers. If an entity uses containers, one or more host servers or servers still exist somewhere where the container is operating. These servers are typically VMs or bare metal servers.

[0027] The difference between containerized infrastructure and legacy or traditional infrastructure is that in containerized infrastructure, the container environment sits between the host server (whether virtual or bare metal) and the applications operating within the container environment. The container runtime extracts containerized applications from the host server, providing greater flexibility and simplifying configuration. Common types of applications operating in containers include database servers, application servers, web servers, email servers, and more.

[0028] Containerized applications start much faster than VMs. This is because there's no need to start the entire server to launch a containerized application. The server is already running; only the container needs to be started to initialize the application. Containers can start in seconds, whereas it typically takes several minutes to start a VM or bare-metal server and subsequently the applications running on it.

[0029] Containerized applications are deployed "more densely" than traditional applications. More containerized applications can be installed on a single bare-metal server compared to using virtual machines (VMs) to run the same applications. This is at least partly because containers do not require the virtualization of a complete operating system like VMs do. Since the container environment only needs to be running, higher application density can be achieved.

[0030] Containerized applications are more scalable than traditional application deployments. The ability to start containers faster than legacy infrastructure leads to greater scalability. If more instances of the application are needed, new containers can be started even faster by spinning off to accelerate their deployment.

[0031] Container environments have fewer configuration variables. Regardless of the type of host operating system the container environment runs on or the underlying hardware that supports it, the container environment looks the same. This means that there are fewer configuration variables to worry about when setting up and managing a container environment.

[0032] Figure 3 An example diagram illustrating an embodiment of container system 300 is provided. The container system 300 shown includes source code 302, container image 304, registry 306, container 308, and VM 310. The construction of source code 302 produces container image 304. VM 310 may accordingly include... Figure 1 The guest OSs are 106A and 106B, bin / lib is 104A and 104B, and the applications are 102A and 102B.

[0033] Container image 304 is an immutable, static file containing executable code that can be run on container engine 212 as an isolation process. Changes to container image 304 create new instances of different container images. The isolation process is container 308. Container image 304 may include one or more system libraries 104A-104B (see...). Figure 2 One or more system tools, and executable code, need to run on the platform as other platform settings for container 308. Container image 304 can share its host OS 214 (see [link to container image]) with other container images. Figure 2 This is the main difference between containers (deployed examples of images) and virtual machines (VMs). VMs use their own OS instance to operate, while containers share OS capabilities with other containers or other applications.

[0034] Container images 304 are built from file system layers built on top of a parent or base image. These layers encourage the reuse of various components, so users don't have to create everything from scratch for each project.

[0035] Many software vendors create publicly available container images of their products that 304-erode. For example, Microsoft, based in Redmond, Washington, USA, provides a standardized query language (SQL) server container image. Container adopters need to be aware of the existence of broken, counterfeit, and malicious publicly available container images that 304-erode, sometimes masquerading as images from official vendors.

[0036] Unlike VMs, and as mentioned earlier, container image formats are designed for fast download and near-instant startup. Running a container typically consumes fewer compute and memory resources than a comparable VM running the same application.

[0037] Registry 306 is the service that stores container images 304. Container images 304 can be pushed to registry 306 for storage or pulled from registry 306 for deployment. For each container image 304, the registry includes an image identifier. The container image is currently identified by the first 12 characters of its image identifier (in registry 306) and has a virtual size measured according to the underlying layer. Container images 304 can be tagged (e.g., using a revision number, etc.) or left untagged. Container images 304 can be searchable using their image identifiers.

[0038] Typically, each container 308 (which is a deployed example of container image 304) provides a single service (often referred to as a "microservice"), such as a web server or database. Container 308 can be used for any workload. Container 308 can only access the resources defined in container image 304, unless additional access is granted to container 308 at the time of its creation.

[0039] VM 310 can pull container image 304 and run container image 304 to deploy container 308. Container engine 212 and container monitor 550 can be implemented in VM 310.

[0040] While containers offer greater isolation than traditional application deployments, they still have vulnerabilities. For example, malicious actors can use containers to deploy applications for various malicious purposes, such as botnets and unauthorized access.

[0041] Figure 4 An illustration of an embodiment of a method 400 for identifying and responding to anomalous container behavior is provided by way of example. The illustrated method 400 includes, at operation 410, identifying a public container image; at operation 420, generating a container image behavior profile for the identified public container image; at operation 430, logging the behavior of deployed containers using the public container image; at operation 440, comparing the logged container deployment behavior with the generated container image behavior profile; and at operation 450, generating an alert or creating a log entry. Operation 450 can be performed in response to a comparison at operation 440 indicating that the logged container deployment differs from the image behavior profile generated at operation 420.

[0042] Container technology is widely used by many organizations across various scales. Containers can be used internally within an organization or accessed over a network. While some container images are public and used by many different organizations, others are not.

[0043] Crowdsourced data aggregates from multiple users, organizations, etc. Crowdsourcing techniques may be insufficient for less popular images. This is at least partly due to the lack of data for generating behavioral profiles at operation 420. Therefore, at operation 410, a subset of public or frequently used container images 304 can be identified. Thus, crowdsourcing may include performing operation 410. Operation 410 may include aggregating data for identified images.

[0044] Operation 410 may include querying records of metrics indicating the number of container image deployments, container image downloads, etc. These metrics can be retrieved from container image version control tools, such as Docker Hub from Docker Inc. in San Francisco, California, or other container image control tools. Other container platforms (besides Docker) include Rkt (short for Rocket), LXC (short for Linux Containers), Solaris Containers, and Open Virtuozzo (VZ). Metrics can be at container level 308, container image level 304, or a combination thereof. Metrics may include the number of container image 304 deployments (e.g., container 308), the number of container image 304 downloads, the number of users accessing container 308 features, the number of organizations accessing or deploying container 308 features or container image 304, or combinations thereof. Information can be provided by querying registry 306 or other data repositories that have such container or container image data.

[0045] Operation 410 may include comparing a metric with one or more thresholds to determine whether container 308 or container image 304 is in public use. In another example, a predefined number of container image deployments or users can be used as a rule to define when a container image is considered public. In yet another example, a known image can be labeled as a public image and a less known container image can be labeled as 'non-public'. An ML classifier (e.g., linear regression, support vector machine (SVM), NN, or other classifier) ​​can be trained on the data. The ML classifier can then be used to classify container image 304 or container 308 as public or non-public. Only public container images or public containers can be operated on at operation 420.

[0046] For example, consider a sample of N public container images and M low-use container images (a total of N+M container images). For each container image, a feature vector can be generated. The feature vector may include information such as the number of container image downloads, the number of users, the age of the container image (the number of days it was first seen), or other features that might indicate publicness (e.g., attributes). An ML model can then be trained based on these feature vectors and their labels (public or non-public). Using the generated output model, feature vectors for other images can be assembled, and the model can identify whether a container image is public or non-public. That is, the model can operate on a given feature vector and provide a prediction about whether an image is public or non-public.

[0047] Operation 420 may include expressing the normal behavior of container image 304 (after deployment as container 308). Normal behavior may include a statistically significant majority of the deployed container 308 exhibiting this behavior.

[0048] Figure 5 An illustration of an embodiment of a system 500 for generating a behavior profile 556 is shown by way of example. System 500 can perform operation 420. Behavior profile 556 can be generated by monitoring the execution of container 305. The monitored behavior can be associated with an identifier indicating that a container image 304 has been deployed from its container 308. The identifier can be associated with an image identifier or a portion thereof in registry 306. In some embodiments, container monitor 550 can be associated with container 308, a portion of container engine 212 (see...). Figure 2 ) or a part of another application or device operating on OS 214 (see Figure 2 ( ) combined.

[0049] Container monitor 550 can record container actions 554 that occur within container 308 or access resources outside container 308. Container actions 554 may include access to a port and the corresponding port number, Internet Protocol (IP) address of a data request, reading from or writing to a process, executing a process, sending or receiving communication from another device, process bandwidth used, allocated or consumed storage space, duration of a specific operation or duration between specific operations, output of an application executing in container 308, or other container actions.

[0050] Processing circuitry 552 can receive container actions 554 and generate a behavior profile 556 based on the container actions 554. Behaviors in the behavior profile 556 may include accessing a specific port, reading or writing to a port or process, executing a process, sending or receiving communications from or from another device, processor bandwidth used, allocated or consumed memory space, specific operations, duration of communication, or port access, etc. The behavior profile 556 of container 308 may specify behaviors, and in some embodiments, may specify a percentage of the total number of corresponding containers exhibiting that behavior. For some behaviors, the average and deviation (e.g., standard deviation, variance, normal range, etc.) of all or a subset of the deployed containers 308 for a specific container image 304 may be determined and used as part of the behavior profile 556. The behavior profile 556 of container 308 may include one or more of the following entries:

[0051] [(port x0, percentage), (port x1, percentage), … (port x n-1 (percentage)

[0052] [(process y0, percentage), (process y1, percentage), ... (process y n-1 (percentage)

[0053] [(common z0, percentage), (common z1, percentage), ... (common z n-1, percentage)]

[0054] [(Processor bandwidth, bias)]

[0055] [(Allotted memory, offset)]

[0056] [(Memory consumed, bias)]

[0057] [(Time difference between processes y0 and y1)]

[0058] One way to generate a profile is by defining its attributes (ports used, processes executed, network communication, CPU bandwidth, memory bandwidth, communication bandwidth, etc.). Operation 420 may include determining statistically expected values ​​and boundaries for one or more attributes. For example, for a given image, 20% of deployments use only port 20 and 80% of deployments use only port 21. This defines the expected value for that attribute. Other approaches use machine learning methods, such as a class classifier model, where the predictor knows whether to classify each new instance as belonging to or not belonging to that class.

[0059] Operations 410 and 420 are parts of the behavior profile generation and can be offline operations. The remaining parts of operations 430, 440, and 450 are parts of the behavior monitoring and can be runtime operations.

[0060] Operations 410 and 420 can be performed periodically (e.g., daily, weekly, monthly, etc.) or by another trigger (such as a user request, memory usage, etc.). For example, each time a specified amount of new image data is uploaded to the cloud provider, after one hundred (100) new images have been uploaded, etc.

[0061] Figure 6 An example diagram illustrates an embodiment of a system 600 for behavior monitoring (performing operations 430, 440, 450). The illustrated system 600 includes a deployed container 608, a container monitor 650, and processing circuitry 652.

[0062] Operation 430 may include, after a behavior profile 556 for container 308 has been generated, using a container monitor 550 (e.g., the same or a different container monitor that records container actions 554 used to generate the behavior profile 556) to record container actions 654 for container 308. The recorded container actions 654 may be provided to processing circuitry 652 (the same or a different processing circuitry that generated the behavior profile 556).

[0063] Operation 440 may include filtering container actions 654 of operation container 308 to include only the behavior types in the corresponding behavior profile 556 for container 308. For example, if behavior profile 560 only includes port access entries, process calls, temporary data, and other behaviors of container action 654 that are not port accesses can be filtered, such as those via processing circuitry 652. Filtering can reduce computation time and memory requirements for comparison.

[0064] Operation 440 may include, at operation 420, training an ML container classifier on a correctly operating container and classifying container actions 654 from a container monitor 650 of deployed containers. The ML container classifier may be a behavior profile 560 for container 308. The ML container classifier may return a label indicating "normal" or "abnormal" for the container action.

[0065] Operation 440 may include comparing container action 654 or data derived from container action 654 with rules defining normal container behavior, such as those defined in the corresponding behavior profile 556. Data derived from container action 654 may include time intervals between actions, such as the time between port accesses or process executions. Data derived from container action 654 may include memory usage, processing circuit bandwidth usage, etc.

[0066] Operation 450 may include issuing an alarm 658 to device 662. Operation 450 may be performed in response to determining at operation 440 that the behavior of container 308, as indicated by container action 654, is anomalous or violates the rules defined in behavior profile 556. Alarm 658 may include data uniquely identifying container 308 as the object of the alarm, the container action(s) deemed anomalous 654, the time 654 of the container action(s), the location of the infrastructure 110 on which container 608 operates (e.g., server identifier, geographic location (e.g., hosting center, etc.)). Device 662 may be associated with a user responsible for maintaining container 608. Device 662 may include a smartphone, computer, tablet, laptop, smartwatch, and the alarm may include text, telephone call, direct messaging, or other communication. In some embodiments, device 662 may include an email server, etc., through which users can be notified via email or other communication.

[0067] Action 450 can include blocking the operation of running containers, auditing container actions to log or alert customers. Users can configure their alert preferences for Action 450. For example, users can indicate whether they want to block / unblock containers, be notified via email or text (e.g., Simple Messaging Service (SMS)), be notified only on high-confidence alerts, the maximum number of alerts to be notified daily or at other times, or be notified only on specified image types, among other configuration options.

[0068] Figure 7 A block diagram illustrating an embodiment of a machine 700 (e.g., a computer system) for implementing one or more embodiments is shown by way of example. An example machine 700 (in the form of a computer) may include a processing unit 702, a memory 703, a removable storage device 710, and a non-removable storage device 712. Although the example computing device is illustrated and described as machine 700, computing devices take different forms in different embodiments. For example, a computing device may be a smartphone, laptop computer, desktop computer, tablet computer, smartwatch, or include... Figure 7Other computing devices may include portions of the same or similar elements illustrated and described. One or more of the following: hypervisor 108, infrastructure 110, container engine 212, registry 306, container monitor 550, processing circuitry 552, container monitor 650, processing circuitry 652, device 662, or other components may be implemented using or include one or more components of machine 700. Furthermore, while various data storage elements are illustrated as portions of machine 700, the storage device may also, or alternatively, include a cloud-based storage device accessible via a network (such as the Internet).

[0069] Memory 703 may include volatile memory 714 and non-volatile memory 708. Machine 700 may include—or have access to a computing environment, including—various computer-readable media, such as volatile memory 714 and non-volatile memory 708, removable storage device 710, and non-removable storage device 712. Computer storage devices include random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM) and electrically erasable programmable read-only memory (EEPROM), flash memory or other storage technologies, optical disc read-only memory (CD-ROM), digital versatile disk (DVD) or other optical disc storage devices, magnetic cartridges, magnetic tapes, disk storage devices, or other magnetic storage devices capable of storing computer-readable instructions for performing the functions described herein.

[0070] Machine 700 may include or have access to a computing environment including input 706, output 704, and communication connection 716. Output 704 may include a display device, such as a touchscreen, which may also be used as an input device. Input 706 may include one or more of the following: touchscreen, touchpad, mouse, keyboard, camera, one or more device-specific buttons, one or more sensors integrated into or coupled to machine 700 via a wired or wireless data connection, and other input devices. The computer may use the communication connection to operate in a networked environment to connect to one or more remote computers, such as database servers, including cloud-based servers and storage devices. Remote computers may include personal computers (PCs), servers, routers, network PCs, peer-to-peer devices, or other public network nodes. Communication connection may include a local area network (LAN), a wide area network (WAN), cellular, IEEE 802.11 (Wi-Fi), Bluetooth, or other networks.

[0071] Computer-readable instructions stored on a computer-readable storage device are executable by the processing unit 702 of machine 700. Hard disk drives, CD-ROMs, and RAM are some examples of articles of manufacture that include non-transitory computer-readable media such as storage devices. For example, computer program 718 can be used to cause processing unit 702 to perform one or more methods or algorithms described herein.

[0072] Using one or more aspects of artificial intelligence (AI), some embodiments can be implemented, including processing and reasoning performed using machine learning (ML) or neural networks (NN). Artificial intelligence is a technological field involving the development of decision-making systems to perform cognitive tasks that traditionally require living actors, such as humans. A neural network (NN) is a computational structure that loosely models biological neurons. Typically, information (e.g., information or decisions) is encoded in the NN via weighted connections (e.g., spurs) between nodes (e.g., neurons). Modern neural networks are the foundation of many artificial intelligence applications.

[0073] Many neural networks (NNs) are represented as weight matrices corresponding to the modeled connections. NNs operate by receiving data into a set of input neurons, which typically have many outgoing connections to other neurons. In each traversal between neurons, the corresponding weights modify the input, and a threshold is tested at the target neuron. If the weighted value exceeds the threshold, it is either reweighted or transformed by a non-linear function and transmitted to another neuron further down the NN graph—if the threshold is not exceeded, the value is not transmitted to the down-graph neuron, and the synaptic connection remains inactive. This weighting and testing process continues until an output neuron is reached; the pattern and values ​​of the output neuron constitute the result of the neural network processing.

[0074] The correct operation of most neural networks (NNs) relies on accurate weights. However, NN designers typically do not know which weights will work for a given application. Instead, a training process (sometimes involving machine learning) is used to arrive at the appropriate weights. NN designers often select specific connections between multiple layers of neurons or between layers that include recurrent connections. Conversely, the training process is usually performed by selecting initial weights, which can be deliberately or randomly chosen. Training data is fed into the neural network, and the results are compared to an objective function that provides an error indication. The error indication measures how much the neural network's output is erroneous compared to the expected result. This error is then used to correct the weights. After multiple iterations, the weights can converge together to encode the operational data into the NN. This process can be called optimization of the objective function (e.g., cost or loss function), thereby reducing or even minimizing the cost or loss.

[0075] Gradient descent techniques can be used to perform objective function optimization. Gradients (e.g., partial derivatives) with respect to layer parameters (e.g., aspects of the weights) are computed to provide direction and the possible degree of correction, but do not result in a single correction to set the weights to the "correct" values. That is, through multiple iterations, the weights can be moved toward the "correct" or operationally useful values. In some implementations, the amount of movement or step size is fixed (e.g., the same from iteration to iteration). Small step sizes tend to take a long time to converge, while large step sizes may oscillate around the correct value or exhibit other unwanted behavior. Without the drawbacks of large or small step sizes, variable step sizes can be attempted to provide faster convergence.

[0076] Backpropagation is a technique for training neural networks (NNs) by feeding data forward—where "forward" means the data starts at the input neurons and follows a directed graph of neuron connections until the output neuron is reached—and the objective function is applied backward through the NN to correct synaptic weights. At each step of the backpropagation process, the results of the previous step are used to correct the weights. Therefore, the corrected output neuron is applied to the neurons connected to it, and so on, until the input neuron is reached. Backpropagation has become a popular technique for training various neural networks. Any well-known backpropagation optimization algorithm can be used, such as stochastic gradient descent (SGD), Adam, etc.

[0077] The following is a description of an example to help understand the published topic:

[0078] Example 1 includes a system comprising: processing circuitry and a memory device coupled to the processing circuitry, the memory device including instructions stored thereon for execution by the processing circuitry to perform operations for container monitoring, the operations including receiving container actions of an application operating in a deployed container from a container monitor, comparing the container actions with a behavior profile indicating normal behavior of the container, and issuing communications in response to a mismatch between the container actions and the normal behavior of the behavior profile.

[0079] In Example 2, Example 1 also includes a behavior profile that includes data indicating the port number of a port accessed by an application within the container, and a container action that indicates the port number of a port accessed by an application within the container.

[0080] In Example 3, at least one of Examples 1 to 2 further includes a behavior profile that includes data indicating a procedure invoked by an application in the container.

[0081] In Example 4, at least one of Examples 1 to 3 further includes a behavior profile comprising: data indicating actions performed by the application of the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

[0082] In Example 5, at least one of Examples 1 through 4 also includes an operation that further includes generating a behavior profile of the container.

[0083] In Example 6, Example 5 also includes generating a behavior profile that includes analyzing container actions of multiple container instances built from the same container image and logging the container actions performed in the multiple container instances.

[0084] In Example 7, at least one of Examples 1 to 6 further includes the operation of filtering container actions associated with container action types not in the behavior profile before comparing the container action with the behavior profile.

[0085] Example 8 includes at least one machine-readable storage medium including instructions for execution by processing circuitry to perform operations targeting a container monitor, the operations including comparing container actions of an application deployed in a container with a behavior profile indicating normal behavior of the container, and issuing a communication in response to a discrepancy between the container actions and the normal behavior of the behavior profile.

[0086] In Example 9, Example 8 also includes a behavior profile that includes data indicating the port number of a port accessed by an application within the container, and a container action that indicates the port number of a port accessed by an application within the container.

[0087] In Example 10, at least one of Examples 8 to 9 further includes a behavior profile that includes data indicating a procedure invoked by an application in the container.

[0088] In Example 11, at least one of Examples 8 through 10 further includes a behavior profile comprising: data indicating actions performed by the application of the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

[0089] In Example 12, at least one of Examples 8 to 11 also includes an operation that further includes generating a behavior profile of the container.

[0090] In Example 13, Example 12 also includes generating a behavior profile that includes analyzing container actions from multiple container instances built from the same container image and logging the container actions performed in the multiple container instances.

[0091] In Example 14, at least one of Examples 8 through 13 further includes the operation of filtering container actions associated with container action types not in the behavior profile before comparing the container action with the behavior profile.

[0092] Example 15 includes a method for container performance monitoring, the method being executed by at least one processor, the method including generating a behavior profile of an application operating in a deployed container based on multiple instances of a deployed container, receiving container actions of the application operating in the deployed container from a container monitor, comparing the container actions with the generated behavior profile, and issuing a communication in response to a discrepancy between the container actions and the normal behavior of the behavior profile.

[0093] In Example 16, Example 15 also includes a behavior profile that includes a port number indicating a port accessed by an application within the container, and a container action that indicates a port number accessed by an application within the container.

[0094] In Example 17, at least one of the examples in Examples 15-16 further includes a behavior profile that includes data indicating a procedure invoked by an application in the container.

[0095] In Example 18, at least one of the examples 15-17 further includes a behavior profile that includes: data indicating actions performed by the application of the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

[0096] In Example 19, at least one of the examples 15-18 further includes the operation of filtering container actions associated with container action types not in the behavior profile before comparing the container action with the behavior profile.

[0097] In Example 20, at least one of the examples 15-19 further includes comparing the container action with the behavior profile by generating a feature vector based on the container action and using a machine learning classifier trained on normal container actions to generate a label based on the feature vector indicating whether the application in the container is operating inconsistently with normal container actions.

[0098] While some embodiments have been described in detail above, other modifications are possible. For example, the logical flow depicted in the figures does not require the shown order or sequential order to achieve the desired result. Other steps may be provided from the described flow, or steps may be eliminated, and other components may be added to or removed from the described system. Other embodiments may fall within the scope of the following claims.

Claims

1. A system for monitoring container performance, comprising: Processing circuitry; as well as A memory device coupled to the processing circuitry, the memory device including instructions stored thereon, the instructions being executed by the processing circuitry to perform operations for container monitoring, the operations including: Based on multiple instances of deployed containers, a behavioral profile of the application operating within the deployed containers is generated. The behavioral profile is generated by identifying a public container image and generating a behavioral profile for the public container image. Identifying the public container image includes comparing metrics with one or more thresholds to determine whether the container image is in public use. The metrics include any one or more of the following: the number of container image deployments, the number of container image downloads, the number of users accessing the functionality of the container, and the number of organizations accessing or deploying the functionality of the container or the container image. Receive container actions from the container monitor for applications operating within the deployed container; Compare the container action with the generated behavior profile; and In response to a discrepancy between the container action and the normal behavior of the behavior profile, communication is initiated.

2. The system of claim 1, wherein the behavior profile includes data indicating a first port number of a first port accessed by an application within the container, and the container action indicates a second port number of a second port accessed by the application within the container.

3. The system of claim 1, wherein the behavior profile includes data indicating a procedure invoked by an application in the container.

4. The system according to claim 1, wherein the behavior profile includes: Data indicating actions performed by the application of the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

5. The system of claim 1, wherein generating the behavior profile comprises: Analyze container actions from multiple container instances built from the same container image, and record the container actions executed in the multiple container instances.

6. The system according to claim 1, wherein the operation further comprises: Before comparing the container action with the behavior profile, filter out container actions that are not associated with container action types in the behavior profile.

7. At least one machine-readable storage medium, including instructions for execution by processing circuitry to perform operations for container monitoring, the operations including: Based on multiple instances of deployed containers, a behavioral profile of the application operating within the deployed containers is generated. The behavioral profile is generated by identifying a public container image and generating a behavioral profile for the public container image. Identifying the public container image includes comparing metrics with one or more thresholds to determine whether the container image is in public use. The metrics include any one or more of the following: the number of container image deployments, the number of container image downloads, the number of users accessing the functionality of the container, and the number of organizations accessing or deploying the functionality of the container or the container image. Receive container actions from the container monitor for applications operating within the deployed container; Compare the container action with the generated behavior profile; as well as In response to a discrepancy between the container action and the normal behavior of the behavior profile, communication is initiated.

8. The at least one machine-readable storage medium of claim 7, wherein the behavior profile includes data indicating a first port number of a first port accessed by an application within the container, and the container action indicates a second port number of a second port accessed by the application within the container.

9. The at least one machine-readable storage medium of claim 7, wherein the behavioral profile includes data indicating a procedure invoked by an application in the container.

10. The at least one machine-readable storage medium according to claim 7, wherein the behavioral profile comprises: Data indicating actions performed by applications within the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

11. The at least one machine-readable storage medium according to claim 7, wherein generating the behavioral profile comprises: Analyze container actions from multiple container instances built from the same container image, and record the container actions executed in the multiple container instances.

12. The at least one machine-readable storage medium according to claim 7, wherein the operation further comprises: Before comparing the container action with the behavior profile, filter out container actions that are not associated with container action types in the behavior profile.

13. A method for monitoring container performance, the method being executed by at least one processor, the method comprising: Based on multiple instances of deployed containers, a behavioral profile of the application operating within the deployed containers is generated. The behavioral profile is generated by identifying a public container image and generating a behavioral profile for the public container image. Identifying the public container image includes comparing metrics with one or more thresholds to determine whether the container image is in public use. The metrics include any one or more of the following: the number of container image deployments, the number of container image downloads, the number of users accessing the functionality of the container, and the number of organizations accessing or deploying the functionality of the container or the container image. Receive container actions from the container monitor for applications operating within the deployed container; Compare the container action with the generated behavior profile; as well as In response to a discrepancy between the container action and the normal behavior of the behavior profile, communication is initiated.

14. The method of claim 13, wherein the behavior profile includes data indicating a first port number of a first port accessed by an application within the container, and the container action indicates a second port number of a second port accessed by the application within the container.

15. The method of claim 13, wherein the behavior profile includes data indicating a procedure invoked by an application in the container.

16. The method of claim 13, wherein the behavioral profile comprises: Data indicating actions performed by the application of the container and a percentage indicating the number of containers built from the same container image that exhibit the behavior.

17. The method of claim 13, wherein the operation further comprises: Before comparing the container action with the behavior profile, filter out container actions that are not associated with container action types in the behavior profile.

18. The method of claim 13, wherein comparing the container action with the behavior profile comprises: A feature vector is generated based on the container action, and a machine learning classifier trained on normal container actions is used to generate a label based on the feature vector indicating whether the application in the container is operating inconsistently with the normal container action.

Images