Automated port configuration management in a service mesh

Systems, methods and/or computer program products for managing and dynamically automating service mesh communications between microservices, eliminating unnecessary exposure of microservice ports and increasing security between microservices of the service mesh. The control plane collects data describing communications between microservices and tracks the frequency at which microservices communicate. Collected data is fed to machine learning models which outputs a forecast predicting future communication interactions between microservices. Using the predicted requirements for facilitating communications between microservices of the service mesh, an allowed list of communications can be generated describing the microservices allowed to send and receive communications, duration of communications allowed, when such communications are allowed, and the ports that will be used for facilitating the communication between microservices. Administrators of the service mesh may manually override the one or more approved aspects of the dynamically generated allowed list configured automatically by the service mesh.

BACKGROUND

The present disclosure relates generally to the field of microservice architecture, and more specifically to service meshes and techniques for managing communications and network policies between the microservices of a service mesh.

Modern applications are often broken down into this microservice architecture, whereby a loosely coupled and independent network of smaller services each perform a specific business function. The microservices architecture lets developers make changes to an application's services without the need for a full redeploy. Microservices operate on a principle reflecting a single responsibility per service being deployed. Microservices are built independently, communicate with each other, and can individually fail without escalating into an application-wide outage. A microservice may typically be represented by a container or groups of containers (i.e., a POD in certain environments such Kubernetes). The microservices communicate via a defined interface using lightweight API's. Because microservices run independently of each other, each service can be updated, deployed and scaled to meet demand for specific functions of an application. In order to execute microservice functions, one service might need to request data from several other services.

A service mesh provides a way to control how different parts of an application share data with one another. The service mesh is a dedicated infrastructure layer built right into an application. This visible infrastructure layer can document how well different parts of an application interact with one another, making it easier to optimize communication and avoid downtime as an application grows and changes over time. Each microservice of the application can rely on other microservices to complete transactions, tasks or other functions requested by users. The service mesh routes requests from one service to the next, optimizing how all the moving parts of the network of microservices work together. The service mesh takes the logic governing service-to-service communication out of individual services and abstracts the logic to the layer of infrastructure. Requests are routed between microservices of the service mesh through proxies in the infrastructure layer; sometimes individually referred to as “sidecars” because the proxies run alongside each service rather than within the service. Taken together, the “sidecar” proxies decoupled from each service form the mesh network. Within complex microservice architectures, locating problems can be nearly impossible without a service mesh. The service mesh is able to capture aspects of service-to-service communication as performance metrics. Over time, data made visible by the service mesh can be applied to the rules for interservice communication, resulting in more efficient and reliable services.

SUMMARY

Embodiments of the present disclosure relate to a computer-implemented method, an associated computer system and computer program products for managing port configurations of microservices within a service mesh. The computer-implemented method comprising: collecting, by the service mesh, time series data describing communications between a first microservice and a second microservice of a microservice chain; tracking, by the service mesh, historical communications between the first microservice and the second microservice; forecasting, by the service mesh, future communications between the first microservice and second microservice of the microservice chain based on the time series data collected by the service mesh and patterns of the historical communications tracked by the service mesh; generating, by the service mesh, as a function of forecasting the future communications, an allowed list describing one or more permitted ports of the second microservice configured to receive incoming traffic from the first microservice; identifying, by the service mesh, an absence of communication between the first microservice and the second microservice for a threshold period of time, or communications routed from the first microservice of the allowed list to the second microservice as being vulnerable to manipulation or insecure; disabling, by the service mesh, the permitted ports of the second microservice configured to receive communications from the first microservice; and re-configuring, by the service mesh, the allowed list, preventing the future communications between the first microservice to the second microservice.

DETAILED DESCRIPTION

Overview

Microservices of a service mesh architecture are networked together, allowing communications to be routed between the microservices according to particular rules of the service mesh. A control plane of the service mesh knows about each and every microservice in detail. The control plane may specifically focus on the networking between microservices and rules for routing communications. When microservices of the service mesh are part of a microservice chain, the microservices may be configured to enable incoming and outgoing ports for communication between microservices within the microservice chain. During configuration of the microservices, the control plane can designate which microservices are allowed to approach other microservices, which ports can be used for communications between microservices and designated protocols that are acceptable for sending and/or receiving the communications. However, communications between microservices may not always be occurring. Microservice communications may occur periodically, at specific times of day, days of the week, for specified lengths of time, and/or only a limited number of times per designated time period. Leaving configured ports of the microservices open all the time to the microservices of the microservice chain(s) may leave microservices open to unnecessary exposure and security risks. Therefore, there is a need for automating configurations of the microservice ports to limit the unnecessary exposure to other microservices of the microservice chain(s) and enabling ports securely, as needed, without requiring administrators to manually configure ports for communication between microservices.

Embodiments of the present disclosure recognize a need for managing and dynamically automating service mesh communications between microservices, as well as eliminating unnecessary exposure of microservice ports to increase security of the microservices or the service mesh as a whole. Embodiments of the service mesh collects metrics of transactions between microservices, tracks via the control plane, the frequency at which microservices are communicating and whether communications between certain ports of the microservices are secure and/or need to be enabled or restricted. Based on findings of the control plane regarding port security and necessity for active communications between microservices, the service mesh may automatically configure which microservice ports are allowed to accept and receive service mesh traffic, while disabling unneeded and/or unsecure ports, improving the security of the service mesh communications between microservices by avoiding unnecessary exposure of the ports.

Embodiments of the present disclosure leverage data collection by the service mesh and apply machine learning models in order to predict future data, including but not limited to forecasting future communication interactions between microservices. During a learning period, the service mesh collects time series data of micro services accessing or communicating with other microservices of a microservice chain. For example, the control plane of the service mesh can collect the communication data during the learning period using the control handshake between proxies sending and receiving the communications. The collected data may include the time of day, the microservice that is the source of the communication, the microservice that is the destination service, the port being used and the duration of the communications. As the data is continuously collected, the slices of information describing communications are sent to machine learning models which may output forecasts predicting microservice interactions expected to occur in the future, the probability of such communications occurring, and/or the confidence level of the predictions being made by the machine learning models. Using the predicted requirements for facilitating communications between microservices of the service mesh, an allowed list of communications can be generated describing the microservices allowed to send and receive communications, duration of communications allowed, when such communications are allowed, and the ports that will be used for facilitating the communication between microservices. Moreover, in some embodiments, administrators of the service mesh may manually override the one or more approved aspects of the dynamically generated allowed list configured automatically by the service mesh.

Computing System

FIG.1illustrates a block diagram describing an embodiment of a computing system100, which may be a simplified example of a computing device (i.e., a physical bare metal system and/or a virtual system) capable of performing the computing operations described herein. Computing system100may be representative of the one or more computing systems or devices implemented in accordance with the embodiments of the present disclosure and further described below in detail. It should be appreciated thatFIG.1provides only an illustration of one implementation of a computing system100and does not imply any limitations regarding the environments in which different embodiments may be implemented. In general, the components illustrated inFIG.1may be representative of any electronic device, either physical or virtualized, capable of executing machine-readable program instructions.

AlthoughFIG.1shows one example of a computing system100, a computing system100may take many different forms, including bare metal computer systems, virtualized computer systems, container-oriented architecture, microservice-oriented architecture, etc. For example, computing system100can take the form desktop computer system or workstation, laptops, notebooks, tablets, servers, client devices, network devices, network terminals, thin clients, thick clients, kiosks, mobile communication devices (e.g., smartphones), multiprocessor systems, microprocessor-based systems, minicomputer systems, mainframe computer systems, smart devices, and/or Internet of Things (IoT) devices. The computing systems100can operate in a local computing environment, networked computing environment, a containerized computing environment comprising one or more pods or clusters of containers, and/or a distributed cloud computing environment, which can include any of the systems or devices described herein and/or additional computing devices or systems known or used by a person of ordinary skill in the art.

Computing system100may include communications fabric112, which can provide for electronic communications among one or more processor(s)103, memory105, persistent storage106, cache107, communications unit111, and one or more input/output (I/O) interface(s)115. Communications fabric112can be implemented with any architecture designed for passing data and/or controlling information between processor(s)103(such as microprocessors, CPUs, and network processors, etc.), memory105, external devices117, and any other hardware components within a computing system100. For example, communications fabric112can be implemented as one or more buses, such as an address bus or data bus.

Memory105and persistent storage106may be computer-readable storage media. Embodiments of memory105may include random access memory (RAM) and/or cache107memory. In general, memory105can include any suitable volatile or non-volatile computer-readable storage media and may comprise firmware or other software programmed into the memory105. Program(s)114, application(s), processes, services, and installed components thereof, described herein, may be stored in memory105and/or persistent storage106for execution and/or access by one or more of the respective processor(s)103of the computing system100.

Persistent storage106may include a plurality of magnetic hard disk drives, solid-state hard drives, semiconductor storage devices, read-only memories (ROM), erasable programmable read-only memories (EPROM), flash memories, or any other computer-readable storage media that is capable of storing program instructions or digital information. Embodiments of the media used by persistent storage106can also be removable. For example, a removable hard drive can be used for persistent storage106. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer-readable storage medium that is also part of persistent storage106.

Communications unit111provides for the facilitation of electronic communications between computing systems100. For example, between one or more computer systems or devices via a communication network. In the exemplary embodiment, communications unit111may include network adapters or interfaces such as a TCP/IP adapter cards, wireless interface cards, or other wired or wireless communication links. Communication networks can comprise, for example, copper wires, optical fibers, wireless transmission, routers, load balancers, firewalls, switches, gateway computers, edge servers, and/or other network hardware which may be part of, or connect to, nodes of the communication networks including devices, host systems, terminals or other network computer systems. Software and data used to practice embodiments of the present disclosure can be downloaded to the computing systems100operating in a network environment through communications unit111(e.g., via the Internet, a local area network, or other wide area networks). From communications unit111, the software and the data of program(s)114or application(s) can be loaded into persistent storage106.

One or more I/O interfaces115may allow for input and output of data with other devices that may be connected to computing system100. For example, I/O interface115can provide a connection to one or more external devices117such as one or more smart devices, IoT devices, recording systems such as camera systems or sensor device(s), input devices such as a keyboard, computer mouse, touch screen, virtual keyboard, touchpad, pointing device, or other human interface devices. External devices117can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. I/O interface115may connect to human-readable display118. Human-readable display118provides a mechanism to display data to a user and can be, for example, computer monitors or screens. For example, by displaying data as part of a graphical user interface (GUI). Human-readable display118can also be an incorporated display and may function as a touch screen, such as a built-in display of a tablet computer.

FIG.2provides an extension of the computing system100environment shown inFIG.1to illustrate that the methods described herein can be performed on a wide variety of computing systems that operate in a networked environment. Types of computing systems100may range from small handheld devices, such as handheld computer/mobile telephone110to large mainframe systems, such as mainframe computer170. Examples of handheld computer110include personal digital assistants (PDAs), personal entertainment devices, such as Moving Picture Experts Group Layer-3 Audio (MP3) players, portable televisions, and compact disc players. Other examples of information handling systems include pen, or tablet computer120, laptop or notebook computer130, workstation140, personal computer system150, and server160. Other types of information handling systems that are not individually shown inFIG.2are represented by information handling system180.

Many of the computing systems can include nonvolatile data stores, such as hard drives and/or nonvolatile memory. The embodiment of the information handling system shown inFIG.2includes separate nonvolatile data stores (more specifically, server160utilizes nonvolatile data store165, mainframe computer170utilizes nonvolatile data store175, and information handling system180utilizes nonvolatile data store185). The nonvolatile data store can be a component that is external to the various computing systems or can be internal to one of the computing systems. In addition, removable nonvolatile storage device145can be shared among two or more computing systems using various techniques, such as connecting the removable nonvolatile storage device145to a USB port or other connector of the computing systems. In some embodiments, the network of computing systems100may utilize clustered computing and components acting as a single pool of seamless resources when accessed through network250by one or more computing systems. For example, such embodiments can be used in a datacenter, cloud computing network, storage area network (SAN), and network-attached storage (NAS) applications.

As shown, the various computing systems100can be networked together using computer network250(referred to herein as “network250”). Types of networks250that can be used to interconnect the various information handling systems include Local Area Networks (LANs), Wireless Local Area Networks (WLANs), home area network (HAN), wide area network (WAN), backbone networks (BBN), peer to peer networks (P2P), campus networks, enterprise networks, the Internet, single tenant or multi-tenant cloud computing networks, the Public Switched Telephone Network (PSTN), and any other network or network topology known by a person skilled in the art to interconnect computing systems100.

Characteristics are as follows:

Service Models are as follows:

Deployment Models are as follows:

Referring to the drawings,FIG.3is an illustrative example of a cloud computing environment300. As shown, cloud computing environment300includes a cloud network350comprising one or more cloud computing nodes310with which end user device(s)305a-305n(referred to generally herein as end user device(s)305) or client devices, may be used by cloud consumers to access one or more software products, services, applications, and/or workloads provided by cloud service providers or tenants of the cloud network350. Examples of the user device(s)305are depicted and may include devices such as a desktop computer, laptop computer305a, smartphone305bor cellular telephone, tablet computers305cand smart devices such as a smartwatch305nand smart glasses. Nodes310may communicate with one another and may be grouped (not shown) physically or virtually, in one or more networks, such as Private, Community, Public, or Hybrid clouds as described hereinabove, or a combination thereof. This allows cloud computing environment300to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing device. It is understood that the types of end user devices305shown inFIG.3are intended to be illustrative only and that computing nodes310of cloud computing environment300can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

Referring now toFIG.4, a set of functional abstraction layers provided by cloud computing environment300is shown. It should be understood in advance that the components, layers, and functions shown inFIG.4are intended to be illustrative only and embodiments of the invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

Hardware and software layer460includes hardware and software components. Examples of hardware components include mainframes461; RISC (Reduced Instruction Set Computer) architecture-based servers462; servers463; blade servers464; storage devices465; and networks and networking components466. In some embodiments, software components include network application server software467and database software468.

Virtualization layer470provides an abstraction layer from which the following examples of virtual entities may be provided: virtual servers471; virtual storage472; virtual networks473, including virtual private networks; virtual applications and operating systems474; and virtual clients475.

Management layer480may provide the functions described below. Resource provisioning481provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment300. Metering and pricing482provide cost tracking as resources are utilized within the cloud computing environment300, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal483provides access to the cloud computing environment300for consumers and system administrators. Service level management484provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment485provide pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA.

Workloads layer490provides examples of functionality for which the cloud computing environment may be utilized. Examples of workloads and functions which may be provided from this layer include software development and lifecycle management491, data analytics processing492, multi-cloud management493, transaction processing494; database management495and video conferencing496.

System for Managing Port Configurations of Microservices within a Service Mesh

The instant features, structures, or characteristics as described throughout this specification may be combined or removed in any suitable manner in one or more embodiments. For example, the usage of the phrases “example embodiments,” “some embodiments,” or other similar language, throughout this specification refers to the fact that a particular feature, structure, or characteristic described in connection with the embodiment may be included in at least one embodiment. Accordingly, appearances of the phrases “example embodiments,” “in some embodiments,” “in other embodiments,” or other similar language, throughout this specification do not necessarily all refer to the same group of embodiments, and the described features, structures, or characteristics may be combined or removed in any suitable manner in one or more embodiments. Further, in the Figures, any connection between elements can permit one-way and/or two-way communication even if the depicted connection is a one-way or two-way arrow. Also, any device depicted in the drawings can be a different device. For example, if a mobile device is shown sending information, a wired device could also be used to send the information.

Referring to the drawings,FIG.5depicts an embodiment of a computing environment500illustrating a microservice architecture that can be executed on one or more computing systems100and variations thereof. As illustrated in the embodiment of the computing environment500, a plurality of planes (or layers) of the environment500are placed in communication with one another. As depicted, the computing environment500includes (but is not limited to) an application plane503comprising one or more application(s)501, a control plane507and a data plane509.

Embodiments of the application plane503may be the layer of the network comprising one or more application(s)501that may make requests for network functions and services provided by the control plane507and/or data plane509. The combination of the control plane507and the data plane509make up the service mesh511. Users accessing the applications501of the application plane503may input requests for services and/or functions of the service mesh511network by interacting with a user interface (UI) of the application501. For example, an application UI displayed by an end user device or client device. In response to requests for services by users or other services, a microservice chain comprising a plurality of microservices525a-525n(generally referred to herein as microservices525or services525) may be invoked causing the microservices525to communicate with one another and transmit data. Embodiments of end user devices or client devices may request the services or functions from the other planes of the service mesh511by inputting or transmitting one or more calls from an interface of application(s)501to the service mesh511. More specifically, in exemplary embodiments, API calls may request the execution of one or more capabilities or functions of the microservices525.

Embodiments of the application UI transmitting requests may be part of a mobile application, web application, SaaS application, etc. For example, mobile applications may be inputting requests and routing data through the service mesh511by transmitting an API call to an API gateway of the network. In other examples, client devices may use a command line interface (CLI) to input commands and requests to the service mesh511and/or a web-based UI transmitting an HTTP request via a web browser. Transaction requests to one or more microservices525of an application501may be initiated by external user(s), and/or external services incoming from outside of service mesh511network.

Referring now to the data plane509, embodiments of the data plane509may be responsible for touching every packet of data and/or incoming call requesting services from the service mesh511. In other words, the data plane509of the service mesh511may be responsible for conditionally translating, forwarding, and observing every network packet that flows to and from the instances523a-523n(hereinafter referred to generally as instances523) of services525(and replicas thereof) and/or proxies527a-527n(hereinafter proxies527) within the service mesh511. As illustrated in the exemplary embodiment ofFIG.5, the data plane509may comprise a plurality of instances523, which can be in the form of one or more clusters, pods, or containers hosting a microservice525within the instance523. Embodiments of each service525may be co-located within an instance523with a sidecar network proxy527injected into the instance523. For example, as shown inFIG.5, service525ais co-located with proxy527awithin instance523a; service525bis co-located with proxy527bwithin instance523b; and service525nis co-located with proxy527nwithin instance523nof the data plane509. Network traffic (e.g., HTTP, REST, gRPC, Redis, etc.) being routed along microservice chains comprising more than one individual microservice525may flow via the local proxies527to a destination microservice routed by the service mesh511, in accordance with the routing rules and policies of the service mesh511, such as the allowed list521controlling inter-microservice communications and restrictions as described in detail herein. Since the data flows from the services525to the co-located proxy527, the services525may not be aware of the network of services at large that may form the data plane509. Instead, the services525themselves may only be aware of their local proxy527.

Embodiments of the proxies527may be responsible for performing tasks associated with service discovery, health checking, routing, load balancing, authentication/authorization, and observability. Service discovery tasks may include discovery of upstream and/or backend services525and instances523thereof that are available on the data plane509of the service mesh511. Health checking tasks may include determining whether upstream services525and instances523thereof returned by service discovery are healthy and ready to accept network traffic. Health checking may include both active health checking and/or passive health checking.

Routing tasks of the proxies527may include directing requests to a proper instance523, such as a cluster, pod or container of a service525. For example, a REST request for a local instance523aof a service525a, a proxy527atasked with sending an outbound communication to the next service525bof a microservice chain knows where to send the communication according to the routing rules and configurations of the service mesh511. For example, routing rules may include allowed lists521of microservices525permitted to send network traffic to other microservices525of the microservice chain and/or receiving incoming traffic from other microservices525, via specific ports601a-n,603a-nauthorized by the service mesh511for facilitating the communications. Authentication and authorization tasks of the proxies527may include the performance of cryptographic attestation of incoming requests in order to determine if the request being invoked by an API call is valid and allowable. For example, the user sending the requested call is authenticated by the proxy527using Mutual Transport Layer Security (mTLS) or another mechanism of authentication, and if the user is allowed to invoke the requested endpoint service of the service mesh511, the proxy527may route the request to the next service525along the microservice chain. Otherwise, the proxy527can return a response to the user or external service indicating that the requesting user or service is not authorized to invoke a particular call function and/or a user is not authenticated by the service mesh511.

Embodiments of the proxies527may perform one or more observability tasks and network functions of the service mesh511in response to API calls and communications being routed between proxies527of the microservice chain being invoked. The observability tasks may include, for each API call, collecting historical call information as detailed time series data513about the service mesh511, including statistics including time day the call occurred, a source service outputting the call to a second microservice, a destination microservice receiving the call from the source service, the type of call or communication occurring, the data involved, one or more ports601a-n,603a-nbeing used to send and/or receive the communications, duration of microservice525usage, which user profile executed the call, the success or failure of the call, which microservice chains were invoked, the time the call was placed, etc. Observability tasks may also include generation of distributed tracing data that may allow operators and administrators of the service mesh511to understand the distributed traffic flow of the service mesh511. Embodiments of the service mesh511may keep track of all possible services525being invoked by users and may track the functions or capabilities of services525being invoked on a per user basis then store the data associated with the user's invoked services525to profiles associated with the users (i.e., user profiles). Over time, the service mesh511may build a database comprising historical data metrics collected as time series data513by the proxies527as requested calls are made and fulfilled by the service mesh511. Embodiments of the service mesh511can use the collected data to keep track of all API calls being made to the service mesh511. More specifically, embodiments of the service mesh control plane505can keep track of all microservice chains, and all microservices communicating with each other within each of the microservice chains. Historical data collected and stored as time series data513can further track how frequently microservices525communicate with each other, whether or not vulnerabilities of containers or other instances523of the microservices525exist and/or whether one or more microservices525communicating within a microservice chain may be considered insecure. Table 1 as shown below provides an example of the time series data513collected by the service mesh511:

In the exemplary embodiment ofFIG.5, the database collecting time series data513of the service mesh511may be referred to data repository514. Proxies527of the service mesh511may collect and store a plurality of different metrics as time series data513to one or more data repository514over time, along with user profiles associated with the time series data513being collected. For example, the time series data being collected by the service mesh511may be represented as historical data describing past API calls and communications between the microservices525of microservice chains, including (but not limited to) the type of API call being made, time stamps describing the time the communication occurs, the source microservice, the destination microservice, the port(s) being used, duration of the communications, the types of errors, warnings and failures that are occurring from the API calls, security events, timeout events between microservices525, etc. Furthermore, embodiments of the data repository514may additionally store machine learning model(s)515(ML model(s)515), predictive forecasts517about future microservice communications, container log(s)519and allowed list(s)521of permitted communications between microservices525.

Embodiments of the control plane507of the service mesh511, may configure the data plane509based on a declared or desired state of the service mesh511. The control plane507may be the portion or part of a network responsible for controlling how data packets are forwarded from a first location of the network to a destination of the network, the route the data will take to arrive at a destination and network functions that may control the flow of the data packets. Control plane507may be responsible for creating a routing table, routing rules, and implementing various protocols to identify the network paths that may be used by the network. The control plane207can store the network paths to the routing table. Examples of protocols used for creating routing tables may include Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), and/or Intermediate System to Intermediate System (IS-IS).

Embodiments of the control plane507may include a service mesh control plane505, which may turn all the data planes509of the service mesh511into a distributed system. The service mesh control plane505may provide the rules, policies and/or configurations enacted for each of the running data planes509of a service mesh511, but the service mesh control plane505does not touch the data packets or requests transmitted by the user(s) or external service(s) making calls. For example, service mesh control plane505may utilize the service mesh metrics and time series data513collected from the proxies527and/or microservices525of the service mesh511to track all communications between microservices of the service mesh511. The service mesh control plane505can configure network policies that can be pushed to the proxies527and in doing so may control: communications between the microservices525of invoked microservice chains and ports of communication; the fulfillment API calls; secure the service mesh511from intrusion or exploitation of vulnerabilities of microservice(s)525; and/or the ability of specific users to utilize the services of the service mesh511.

Embodiments of the service mesh511may be initially configured by a human administrator interacting with the service mesh control plane505via a UI to control the distributed system of the service mesh511. For example, the administrator may interact with the service mesh control plane505through a web portal, CLI or some other interface. Through the UI, the operator or administrator may access global system configurations for the service mesh511, including but not limited to, deployment control, authentication and authorization settings, route table specifications, initial application logging settings and load balancer settings such as timeouts, retries, circuit breakers, etc.

Embodiments of the service mesh control plane505, may further include additional components that configure the service mesh511. For example, in some embodiments, the service mesh control plane505may further configure a workload scheduler, service discovery, sidecar proxy configuration APIs, a forecasting module531, rule configuration module533and/or dynamic network intrusion detection and prevention service (NIDPS). The services525may run on infrastructure via a scheduling system (e.g., Kubernetes®), and the workload scheduler may be responsible for bootstrapping a service525along with a sidecar or proxy527. As the workload scheduler starts and stops instances523of the services525, the service discovery component may report the state of services525and may be the process responsible for automatically finding instances523of services525to fulfill requests of incoming API calls. Embodiments of sidecar proxy configuration APIs may describe the configuration of the proxies527mediating inbound and outbound communication to the services525attached to the proxies527. During configuration of the proxies527, all proxies527may be programmed in the service mesh511with configuration settings that may allow the proxies527to reach every instance523and service525of the service mesh511in some instances. Conversely, proxies527can be configured to follow one or more allowed list(s)521, responsible for managing and limiting communications between microservices525based on one or more forecasts of the forecasting module531as described herein. Moreover, the sidecar proxy configuration APIs may, in some embodiments, configure the proxies527to accept traffic on all ports601,603associated with a service525, while in other embodiments a selection of ports may be designated by one or more allowed list(s)521. Furthermore, through the sidecar proxy configuration APIs, the service mesh control plane505may fine tune the set of ports601,603, and protocols that a proxy527may accept when forwarding traffic to and from an instance523and services525. Additionally, through the sidecar proxy configuration APIs, the service mesh control plane505may restrict a set of services525that a proxy527may reach when forwarding outbound traffic from a service525or instance523, in accordance with allowed list(s)521of the service mesh511.

Embodiments of the forecasting module531may be responsible for performing functions or tasks of the service mesh control plane505directed toward training one or more machine learning models515using time series data513collected by the service mesh511inputted into the forecasting module531. Forecasting module531can output one or more forecasts517predicting future communications and interactions between microservices525of the microservice chains within a service mesh511. As noted above, during learning period, the service mesh511continuously collects time series data513describing communications, calls, interactions, etc., between the microservices525of the microservice chain. As the time series data513is collected and stored, the forecasting module531may train one or more ML models515using the time series data, or portions thereof (referred to as “slices”) collected during the learning period to predict future dates and times of interactions between various microservices525. This training period implemented by the forecasting module531may be referred to as the “predictability establishment period.”

During the phase of the predictability establishment period, embodiments of the forecasting module531may use ML models515one or more time series forecasting techniques to transform the time series data513into supervised learning. The forecasting module531may input the time series data513comprising observations about the communications between microservices525occurring sequentially in time and fitting the ML models515to the historical data in order to predict future observations as forecasts517. Embodiments of the forecasts517comprise future data predicting future communications and interactions between the microservices of one or more microservice chains in the service mesh511. The time series data513may be transformed into supervised machine learning by introducing lag times or lags which can shift the data backward in the time sequence established by the time series data513.

In some embodiments, forecasting module531may use techniques for cross-validation of time series data513to predict future communications between microservices during a training period and validate the accuracy of the future predictions made by the forecasts517following the training phase using a validation set of data. Examples of these forecasting methods may include the sliding-window cross-validation method and the forward chaining cross-validation method. A sliding window method may train ML models515using a selected number of data points (n) of the time series data513, then validate the predictions using the next n number of data points in the time series data513collected; i.e., by comparing the predictions with real data describing actual interactions between the microservices525providing the time series data513. Embodiments of the forecasting module531may slide the training and validation window by 2n, and repeat the process continuously until the predictability achieved by the forecasts517outputted by the forecasting module531reach a threshold level of accuracy for the future predictions being validated. The threshold level of accuracy used to establish an acceptable level of predictability may be set by an administrator. For instance, the administrator may set the threshold level of accuracy to 85%, 90%, 92%, 95%, 97%, 99% accuracy or beyond.

In alternative embodiments, the forecasting module531may generate output forecasts517predicting future communications and interactions between microservices within a microservice chain using a forward chaining cross-validation method. Similar to sliding-window techniques, forward chaining cross-validation may train ML model(s)515using the last n number of data points from the time series data513to make predictions. The predictions are validated using a subsequent number of time series data points (m) collected as time series data513and compared with the predictions being forecasted by the forecasting module531. The training and validation window slides forward in time n+m data points and repeats the prediction process by training ML model515using all previous data points collected as time series data513. The cycle of training and validating predictions continues until a level of predictability by the forecasts517using the trained ML model515is as accurate or more accurate than the threshold level of accuracy. For example, a level of accuracy set by the administrator of the service mesh511.

Once the level of accuracy achieved by the forecasts517of the forecasting module531reaches or exceeds the threshold level of accuracy for predicting the future interactions and communications between one or more microservices525of one or more microservice chains, the microservices525that can accurately be forecasted can be marked to enter a dynamic allowed list mode. Once entered into dynamic allowed list mode, the forecasting module531may still continue to generate forecasts517predicting future interactions and communications between microservices525of one or more microservice chains. Additionally, while in dynamic allowed list mode, the service mesh control plane505may further create, and/or modify one or more allowed list(s)521for each of the microservices525that can be accurately forecasted by the forecasting module531. Each of the allowed lists521may be prepared or updated by rules configuration module533of the service mesh control plane505using the forecasts517comprising prediction requirements generated by the forecasting module531. An allowed list521may refer to live lists of all rules which define the allowed list of all incoming traffic that may be accepted by microservices525, including designated ports which may receive the traffic, the times of day traffic can be received from certain microservices, the length of time the incoming communications may last, etc. For example, if a microservice M1is predicted by the forecasting module531to contact a microservice M2each day at 10 AM for 5 minutes, an allowed list521for M2may allow M2to receive communications from M1each day at 10 AM for the prescribed 5 minutes and outside of the allotted timeframe, restrict and/or prevent incoming communications from M1from being received by restricting access to one or more incoming ports601assigned to the communications of M1.

Embodiments of the rule configuration module533may not only create and configure allowed lists521of rules corresponding to the microservices525of the service mesh511, but the rules configuration module also533may further update the allowed lists521of the microservices525dynamically as circumstances change. For instance, rule configuration module533may remove a microservice525from an allowed list521based on an extended period of time wherein a microservice525fails to communicate with other microservices525in accordance with one or more forecasts517. For example, if a microservice M1is predicted to communicate daily with microservice M2but M2has not received the predicted communications from M1for several days or another length of time that is beyond a threshold period of time, the rules configuration module533may check whether M1is still listed as part of M2's allowed list521of microservices that it can receive incoming communications from. If M1is still listed within M2's allowed list but has not sent communications for the period of time that is greater than the threshold period of time, the rules configuration module533can amend the allowed list521of M2and dynamically remove M2from the allowed list521and push the updated allowed list521to a proxy527of M2.

Proposed changes to the allowed lists521can be reviewed, modified and overridden by administrators of the service mesh. For example, in the example provided above, an admin may explicitly override the rule configuration module's change to M2's allowed list521which would remove M1from the list and instead allow M1to remain on the allowed list521of microservice M2. Alternatively, an admin may modify the allowed list to include a microservice525but may further place restrictions on acceptable incoming communications the microservice525may receive from another microservice. For instance, in the example of M1and M2, an admin may manually restrict allowable communications M2receives from M1to a particular day of the week, time of day, period of days in a month, etc. Conversely, an admin may also override timing restrictions on future communications between microservices prescribed by the allowed lists521and may reconfigure the allowed list521in situations where a microservice has been unable to communicate with another microservice for a period of time that is longer than the threshold period of time because the first microservice has been attempting to communicate during a date or time outside of restrictions set by the allowed list of the second microservice. For instance, if an allowed list521is configured to allow a microservice to only communicate with another microservice on a particular day and/or time of day, and upon checking communication requests by the first microservice by the service mesh control plane505, the service mesh control plane identifies attempts outside of the restrictions set by an allowed list521, an admin may override the restriction and/or amend the allowed list to permit communications more broadly or by adjusting the dates and/or times wherein communications are permitted between the first and second microservice.

For example, if microservice M2is permitted to accept incoming communications from microservice M1during a scheduled period of time, such as on Saturdays at 10 AM to 11 AM, then according to the allowed list521for M2, communications from M1at other days of the week and times are not accepted by M2unless overridden by an administrator. If, upon failing to receive communications from M1at the scheduled time for a threshold period of time, the service mesh control plane505may check whether M1is still on the allowed list521for M2and may identify communication attempts that are being made by M1at a different date or time instead of the scheduled date or time predicted by the forecasting module531. Checking on M1may reveal that communications of M1are being attempted outside of the permitted communications times prescribed by the allowed list521and therefore were being restricted. The lack of communication may have been identified after not receiving communications from M1for the threshold period of time. In response to identifying changes in the communication behavior of M1to M2, the rule configuration module533and/or admin may remove M1from the allowed list521of M2and/or may modify the restrictions of the allowed list521to match the communication patterns of M2by changing the date and/or times prescribed by the allowed list of M2, therefore allowing future communications to occur at the new day and time consistent with M1's communication pattern.

As discussed above, in situations where a first microservice is listed on an allowed list521of a second microservice as being permitted to communicate with the second microservice, and the first microservice fails to communicate for a threshold period of time, the rules configuration module533may remove the first microservice from the allowed list521. In some instances, the second microservice may receive an incoming communication from the first microservice following removal of the first microservice from the allowed list521due to lack of communication for the threshold period of time. Embodiments of the service mesh control plane505and/or rules configuration module533may permit the subsequent communication from the first microservice upon identifying whether or not a legitimate sequence of access code is being executed to facilitate the communication and not an unauthorized user who may have taken over one or more containers of the first microservice. Embodiments of the service mesh control plane505may identify the sequence of access code as being legitimate by recording container logs519of the containers making up the microservices525. The service mesh control plane505can use recorded container logs executing the sequence of access code over time to predict whether it's the code being executed that is accessing the microservice receiving the incoming traffic or an intruder. Upon verification of the sequence of access code or input from an admin overriding a restriction of the incoming communication from the microservice, the incoming traffic may be permitted to be received by the second microservice. Moreover, if upon evaluating the container logs519the service mesh control plane505confirms the incoming communication is an intruder that has taken over one or more containers of the microservice attempting to communicate with the second microservice, the microservice can be fully prevented from communicating with the second microservice by removing the microservice from allowed lists521and/or blocking communication ports with the compromised microservice.

Embodiments of the service mesh control plane505may detect vulnerabilities or a security posture changes in one or more microservices525permitted to communicate with a second microservice as allowed by the allowed list521. Embodiments of rule configuration module533may dynamically adjust the rules of the allowed list521in order to prevent previously permitted microservices from sending further communications to other microservices by removing the vulnerable microservices from the allowed list521, unless the restriction of the vulnerable microservice is overridden by an administrator or the service mesh control plane505learns that the vulnerable microservice has been re-deployed without the previously identified vulnerabilities. For example, a vulnerability may include containers of a microservice running outdated software and attempting to communicate with another microservice using outdated access code (unless overridden by an administrator). A microservice525containing vulnerabilities that has been removed from an allowed list521may be taken offline and updated by the service mesh control plane505. Upon re-deployment of the containers that comprise the microservice, the service mesh control plane505recording the container logs519can confirm the access code being executed by the re-deployed microservice is up to date and secure. Embodiments of the rule configuration module533may subsequently amend one or more allowed lists521and re-add the re-deployed microservice, permitted the re-deployed microservice525to communicate again with other microservices525of the service mesh511.

In some embodiments, service mesh control plane505may amend all allowed lists521of downstream microservices within a microservice chain when an upstream microservice is found to be vulnerable, experienced a security posture change or taken over by an unauthorized user. For example, if a microservice chain comprises microservices M1to M2to M3and microservice M1is found to be vulnerable, rule configuration module533may not only remove M1from the allowed list521of M2but may also remove M2from the allowed list521of M3. Preventing unauthorized communications from spreading downstream through the microservice chain unless an administrator explicitly overrides and/or until the previously vulnerable microservice re-deploys in a non-vulnerable state.

Embodiments of the service mesh control plane505may include a dynamic NIDPS component535. Embodiments of dynamic NIDPS may be responsible for monitoring and detecting intrusions into the service mesh network that may violate security policies, acceptable use policies and/or security practices. The dynamic NIDPS535may operate within the service mesh511by placing vulnerable microservices525in a prevention mode that may still allow incoming connections without removing access to the microservice entirely by the service mesh511and/or allow microservices525to receive incoming connections from a potentially vulnerable microservice operating within prevention mode while monitoring the vulnerable microservice for signs of intrusion or unauthorized access to the containers thereof. By operating within prevention mode using a dynamic NIDPS535, the service mesh511may make the vulnerable microservices more secure when microservice communications may deviate from normal scenarios, without having to block incoming connections between microservices entirely.

Referring now toFIGS.6A-6D,FIG.6Adepicts an embodiment of a microservice525or a proxy527thereof comprising a plurality of input ports601a-601nfor receiving incoming communications or calls from upstream microservices as well as a plurality of output ports603a-603ntransmitting outgoing communications and calls to downstream microservices.FIG.6Bdepicts an example of two microservice chains which share a common microservice (microservice M2in this instance) communicating with other microservices525of the microservice chains. Communications between the microservices525of the microservice chains are routed in accordance with rules established by the service mesh control plane505via output ports603sending outbound communications to input ports601receiving incoming communications. The input ports601and output ports603establish connectivity between the microservices in one or more microservice chains and control which microservices can approach each other in accordance with the allowed lists521by managing the ports601,603.

FIG.6Bdemonstrates a flow of communication between multiple microservices allowed to approach the downstream microservices within two different microservice chains. As shown, a first microservice chain comprises microservice M1to M2to M3and a second microservice chain containing microservices M7to M2to M5. In the instance of the first microservice chain, outbound communications from M1leave output port603aof proxy P1and are received by proxy P2via input port601a. The communications designated for microservice M3continue to be routed by proxy P2as outbound communications exiting output port603c. Outbound communications from P2exiting output port603care routed to proxy P3and enter the proxy P3via input port601cand are ultimately received by microservice M3. Likewise, they second microservice chain comprising M7, M2and M5may communicate separately from the first microservice chain and be independently managed despite sharing a common microservice (M2), by using different input ports601and output ports603for communications depending on the microservices M2communicates with. For example, as shown inFIG.6B, outbound communications from microservice M7exit proxy P7via output port603band are routed to input port601bof proxy P2, rather than input port601awhich is being used for communications from microservice M1. Communications from microservice M7which are destined for microservice M5are outputted by proxy P2via output port603d(rather than603cwhich are destined for microservice M3) wherein the incoming communications are received by proxy P5at input port601dand routed to the destination microservice M5.

FIG.6Cdescribes the flow of communications as shown inFIG.6B, wherein the service mesh511may independently manage incoming communications from different microservices based on one or more independent forecasts517of the predicted microservice communications and allowed lists521configured for each microservice by the service mesh control plane505. As shown inFIG.6C, the communications for the microservice M7to M2to M5continue to operate and be acceptable in accordance with the allowed list of microservice M2and M5. However, as shown, incoming communications from M1arriving at input port601ahave been stopped and not allowed to enter proxy P2. For example, in situations where the allowed list521of M2only allows M1to approach M2at certain periods of time and outside of the allowed period of time as per M2's allowed list521, prohibits M1from approaching M2at input port601aand thus prevents communications from entering proxy P2. In another example, microservice M1may have stopped communicating with microservice M2for an extended period of time that is beyond a threshold period of time set by the service mesh511. Therefore, in response to the lack of communications for the threshold period of time, the allowed list521for microservice M2was modified to remove microservice M1from communicating with M2, therefore prohibiting incoming communications from M1to enter proxy P2via input port601aas shown. In another possible scenario, microservice M1may be identified as being vulnerable to intrusion or other security risks that may impact M2. For example, outdated software running on containers that execute outdated access code when attempting to communication with microservice M2. In response to the identified security vulnerabilities of microservice M1, the allowed list521of M2may be modified to prevent incoming communications via input port601aunless or until an administrator overrides the rules of M2's allowed list521or the vulnerabilities of M1are addressed or fixed by a re-deployment of M1.

Referring now toFIG.6D, the embodiments ofFIG.6Ddescribes a change in the flow of communications over time between microservices525of the plurality of microservice chains. More specifically,FIG.6Ddemonstrates how permitted communications between microservices525as governed by the rules of the allowed lists521can change over time. Microservices525that were previously removed from allowed lists521or prevented from communicating with other microservices525can be dynamically re-permitted to engage in communications again. For example, as discussed above with regards toFIG.6C, the allowed list521for microservice M2was shown to have previously blocked communications incoming from microservice M1via input port601a. However, as shown inFIG.6D, the incoming communications from microservice M1are allowable again, as per the rules of microservice M2's allowed list521and/or via an administrative override. For instance, outgoing communications from proxy p1via output port603amay be occurring during a predicted time period considered to be allowable by the allowed list521maintained by proxy P2. Therefore, instead of blocking communications as shown inFIG.6C, proxy P2may accept the incoming communications at input port601aand route the communications as prescribed to proxy P3. Likewise, if the reason for communications being blocked from microservice M1inFIG.6Cwas due to vulnerabilities or potential intrusions of the containers or other instances523being run by M1, then upon updating and re-deploying microservice M1inFIG.6D, M1may no longer be considered vulnerable or insecure and therefore may be re-added to the allowed list521of microservice M2, thus permitting communications to be received at proxy P2and routed to proxy P3as shown.

Moreover, as exemplified by the changes in the embodiments ofFIG.6BtoFIG.6D, the previously permissible communications of microservice M7are depicted as being dynamically restricted at the input port601bof proxy P2. For example, in situations where the allowed list521of M2previously allowed M7to approach M2at during the period of time depicted inFIG.6BandFIG.6C,FIG.6Dmay describe a period of time as per M2's allowed list521that prohibits M7from approaching M2at input port601band thus prevents communications from entering proxy P2. For instance, such a period may be established to limit exposure of the input port601bduring period of time wherein M7is not forecasted by the forecasting module531to be sending communications along the microservice chain M7to M2to M5and thus the allowed list521closed the input port601b. In another example, microservice M7may have stopped communicating with microservice M2for an extended period of time that is beyond a threshold period of time set by the service mesh511. Therefore, in response to the lack of communications for the threshold period of time, the allowed list521for microservice M2was modified to remove microservice M7from communicating with M2, therefore prohibiting incoming communications from M2to enter proxy P2via input port601bas shown. In another possible scenario, microservice M7may be identified as being vulnerable to intrusion or other security risks that may impact M2. For example, outdated software running on containers that execute outdated access code when attempting to communication with microservice M2. In response to the identified security vulnerabilities of microservice M7, the allowed list521of M2may be modified to prevent incoming communications via input port601bunless or until an administrator overrides the rules of M2's allowed list521or the vulnerabilities of M7are addressed or fixed. Such as through an update and a re-deployment of M7.

Method for Managing Port Configurations of Microservices within a Service Mesh

The drawings ofFIG.7represent embodiments of methods for implementing a service mesh511capable of managing port configurations and communications between microservices of a service mesh, in accordance withFIGS.3-6Ddescribed above, using one or more computing systems defined generically by computing system100ofFIGS.1-2; and more specifically by the embodiments of specialized systems depicted inFIGS.3-6Dand as described herein. A person skilled in the art should recognize that the steps of the method described inFIG.7may be performed in a different order than presented and may not require all the steps described herein to be performed.

The embodiment of method700described byFIG.7may begin at step701. During step701, the service mesh511may collect time series data513historically describing microservices accessing and/or communicating with other microservices of the service mesh511. The microservices525communicating with one another may be part of a microservice chain fulfilling a request or API call invoking the microservice chain comprising the microservices525. Embodiments of the service mesh control plane505can track all possible microservice chains of the service mesh511, as well as all communications between microservices525of the microservice chains by storing and analyzing the historical data as time series data513describing the communications. Time series data513can be collected at data plane509of the service mesh511by the proxies527as part of the control handshake between the proxies527sending and receiving the communications.

In step703, the time series data513and/or sliced portions thereof being continuously collected by the service mesh511, may be inputted into one or more machine learning models515(ML Model(s)515) trained by the forecasting module531of the service mesh control plane505to predict future communications between the microservices525based on historical communications of the microservices525as described by the collected time series data513. During this predictability establishment period of the ML model(s)515can be trained and transformed using supervised learning to predict future dates and times of expected communications between microservices. During step705, the forecasting module531outputs one or more predictions describing expected future interactions between microservices525of a microservice chain, including predicted future dates and time communications are predicted to occur.

In step707the accuracy of the predictions forecasted by the ML model(s)515can be assessed to determine whether or not the predictions of future communications between microservices are considered accurate enough to deploy. The predictability and accuracy of the ML model(s)515may be assessed by comparing predictions describing expected future communications and interactions between microservices525forecasted by the ML model515and outputted by the forecasting module531, with actual, subsequent interactions and communications between the microservices525that have been collected as time series data513by the service mesh511. In step709, a determination is made whether the forecasted predictions of the ML model515match actual interactions and communications between the microservices within a threshold level of accuracy in order to achieve an acceptable level of predictability. For example, an administrator may require a threshold level of predictions to be accurate with 97% accuracy before adopting ML model515predictions and use of said predictions to generate allowed lists521. If the predictions forecasted by the ML model(s)515using the time series data513are not validated with actual subsequent interactions and communications within a threshold level of accuracy prescribed by the service mesh511, the method700may proceed to step711. In step711, the forecasting methods and/or ML model(s)515used to generate the predictions of future interactions may be revised and/or the ML model(s)515may be continuously trained using additional time series data513collected by the service mesh. Conversely, if in step709, the predictions forecasted by the ML model(s)515match actual future interactions and communications between microservices525of the service mesh with a level of accuracy that correctly makes predictions at, or above, and established accuracy threshold, the method700may proceed to step713.

In step713, the service mesh control plane505, and more specifically, the rule configuration module533one or more microservices525that can be accurately predicted for future communications may enter a dynamic allowed list mode. The dynamic allowed list mode may be used to create live lists of rules for the microservices525that are being forecasted with accurate predictions describing future interactions or communication by the ML model(s)515. The rules configuration module533may define allowed list(s)521for each of the microservices525. Embodiments of the allowed lists521may include rules describing incoming traffic and/or outgoing communications allowed to be sent or received by the microservices525, acceptable ports for sending and/or receiving the traffic between microservices and/or times of day when such incoming or outgoing communications are considered allowable by the service mesh control plane505. In situations wherein incoming or outgoing communications are outside of the rules set by the allowed list(s)521generated by rules configuration module533, an administrator of the service mesh511may override the established rules. For example, If a microservice M1is predicted by the forecasting module531to contact microservice M2every day for 5 minutes at 10 AM, the allowed list521may include a rule that allows M1and M2to communicate for 5 minutes at 10 AM, otherwise such communications may be restricted or prevented from occurring unless an administrator overrides the rules of the allowed list521and approves communications between M1and M2outside the of limited rule prescribed by the allowed list521.

In step715, service mesh control plane505of the service mesh may track vulnerabilities for each instance523of microservices525deployed, including for example, vulnerabilities of deployed containers, pods, clusters, etc. Service mesh control plane505may continuously check historical data to calculate how frequently microservices on the allowed list(s)521are communicating with each other and/or whether or not sequences of code used to access microservices525are legitimate access codes or intruders attempting to access the recipient microservice525. Checking for legitimate access codes and/or intrusion attempts may help verify security of the microservice chains in order to prevent a vulnerable or insecure first microservice on an allowed list521from accessing or communicating with the second microservice. In step717, for each time a first microservice is attempting to access or communicate with a second microservice, the service mesh control plane505may record within one or more container logs519a corresponding container, pod, or cluster executing a sequence of code as part of the access or communication attempt by the first microservice.

In step719, a determination is made whether or not the attempt to access the second microservice by the first microservice is beyond a threshold period of time since the previous communication between the microservices525. For example, an administrator may set a threshold period of time, such as 12 hours, 24 hours, 5 days, 2 weeks, a month, etc. wherein a communication outside of the threshold period of time may be considered too long and leaving ports open on the second microservice to receive a communication from the first microservice may make the second microservice vulnerable. If the attempt to access or communicate with the second microservice are outside of the threshold period of time, the service mesh control plane505may in step721remove the first microservice from the allowed list521of the second microservice. In step723a further determination may be made whether or not an administrator of the service mesh511has overridden the removal of the first microservice from the allowed list521of the second microservice. If the administrator has overridden the decision to remove the microservice from the allowed list521, the method700may proceed to step725, otherwise, the method700may return to step713and revise the live list of rules encompassed by the allowed list521, finalizing the removal of the first microservice from the allowed list521.

Referring back to step719, if the attempt to access the microservice is within the threshold time period, the method700may proceed to step725. During step725the service mesh control plane505may further determine whether or not the sequence of code being executed is an allowable access code and whether or not the first microservice attempting to the access the second microservice is a non-vulnerable microservice (i.e., an insecure microservice that may be vulnerable to intrusion), based on the recorded container logs519. If the sequence of code being executed to access the second microservice is allowable and/or up to date (i.e., via upgrades or patches applied to a re-deployed first microservice) and thus not a security threat to the second microservice or indicative of the presence of an intruder, the method700may proceed to step727, wherein the communication between the first microservice and the second microservice is considered allowable per the allowed list521. Conversely, if the sequence of code being executed by the first microservice is not an allowable access code, the access code is outdated indicating the first microservice is vulnerable to intrusion and/or the actions of seeking access or communication indicate intrusion onto the first microservice, the method may proceed to step729. During step729, the service mesh control plane prevents access to the second microservice by the first microservice and/or removes the first microservice from the allowed list of the second microservice, unless an administrator overrides the removal in step731.

In step731, a determination is made whether or not an override has been commenced by an administrator of the service mesh, preventing the restriction on the first microservice's access to the second microservice. If the administrator overrides the restriction, the method may proceed to step727, whereby the communication between the first microservice and second microservice are allowed in accordance with the list of rules provided by the allowed list521. On the other hand, if in step731the administrator does not override the restriction of the first microservice, the method may proceed to step713, wherein the live list of rules defined by the allowed list521for the second microservice is amended, preventing the second microservice from being accessed by the first microservice.