Service-to-service communication and authentication via a central network mesh

Abstract

The present disclosure relates to techniques for service-to-service communication and authentication over a network mesh. In particular, aspects relate to receiving a service request for a first service in a network mesh and obtaining information related to the first service. The information includes a location of a first pod that encapsulates the first service. The network mesh uses the location of the first pod to obtain security rules specific to the first pod. The network mesh forwards the service request to the first service based on the security rules for the first pod and obtains results of the service request from the first service. The results include sub-results obtained from the second service according to the security rules for the first pod that encapsulate the first service and the security rules for a second pod that encapsulate the second service.

Description

[Technical Field]

[0001] Priority claim This application claims the benefit of and priority to U.S. Provisional Patent Application No. 63 / 111,997, filed November 10, 2020, which is incorporated herein by reference in its entirety for all purposes.

[0002] The present disclosure relates to digital and personalized healthcare, and more particularly to techniques for service-to-service communication and authentication over a centralized network mesh in a distributed computing environment. [Background technology]

[0003] In healthcare, data-driven technology solutions are being developed to reduce costs and further personalize healthcare. As the healthcare landscape shifts toward an on-demand deployment system for personalized medical services and solutions, healthcare providers are looking to developers for help innovating solutions more quickly by automating and streamlining software deployment and service management processes. To support healthcare providers and services, developers have turned to distributed computing environments (e.g., cloud computing) as the healthcare information technology infrastructure standard. Cloud computing offers many benefits, including flexibility, cost and energy savings, resource sharing, and rapid deployment. For example, cloud computing can provide the complex infrastructure needed to support software deployment and service management processes within various service models (e.g., analytics as a service (AaaS)), which can help facilitate communication, collaboration, and coordination between different healthcare providers. Cloud computing can also help the healthcare industry deliver more value for its dollars. For example, cloud computing can provide fast, flexible, scalable, and cost-effective infrastructure and applications. Cloud computing can also help store, manage, protect, share, and archive electronic health records (EHRs), laboratory information systems, drug information systems, and medical images.

[0004] While distributed computing environments such as cloud computing offer many benefits to healthcare providers, they function differently than legacy storage or information sharing solutions and therefore pose their own unique privacy and security challenges. The centralization of data on the cloud raises many security and privacy concerns for individuals and healthcare providers. This centralization of data provides attackers with a one-stop shop for exfiltrating data, intercepting data in motion, and transferring ownership of the data to the cloud service provider. Thus, individuals and healthcare providers lose some control over their sensitive data. As a result, security, privacy, efficiency, and scalability concerns have hindered the widespread adoption of cloud technology. For example, because users access data via an internet connection, compliance with government regulations (e.g., the Health Insurance Portability and Accountability Act (HIPAA), "good practice" quality guidelines and regulations (GxP), and the General Data Protection Regulation (GDPR) poses unique challenges for healthcare providers considering cloud solutions to support their software deployment and service management processes. Therefore, advances in compliant software deployment platforms built to ensure the confidentiality, availability, and integrity of protected healthcare information are needed. Summary of the Invention

[0005] In some embodiments, a method is provided in a network mesh comprising: receiving a service request for a first service; retrieving, by the network mesh, information related to the first service from a cache or service registry, the information related to the first service including an identification of a first pod that includes the first service and a location of the first pod within the first distributed computing environment; retrieving, by the network mesh, security rules for the first pod using the location of the first pod, the security rules defining (i) a unique address identifier for the first service and (ii) services with which the first service is authorized to communicate and access; forwarding, by the network mesh, the service request to the first service using the unique address identifier for the first service; and receiving, by the network mesh, an access request from the first service to communicate with and access a second service. receiving an access request, the access request including a security key specific to the second service; retrieving, by the network mesh, information related to the second service from a cache or service registry, the information including an identification of a second pod including the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment; retrieving, by the network mesh, security rules for the second pod using the location of the second pod, the security rules defining (i) a unique address identifier for the second service and (ii) services with which the second service is allowed to communicate and access; and forwarding, by the network mesh, the access request from the first service to the second service based on the security rules for the first pod and the security rules for the second pod using the unique address identifier for the second service;A computer-implemented method is provided that includes receiving, by a network mesh, a final result of a service request from a first service, the final result including sub-results obtained from a second service; and outputting, by the network mesh, the final result of the service request.

[0006] In some embodiments, obtaining the information related to the first service or the information related to the second service includes determining whether information related to the first service or the second service is available from a cache; if the information related to the first service or the second service is available from the cache, obtaining the information related to the first service or the second service from the cache; if the information related to the first service or the second service is not available from the cache, obtaining the information related to the first service or the second service from a registry; and in response to obtaining the information related to the first service or the second service from the registry, storing the information related to the first service or the second service in the cache for subsequent requests.

[0007] In some embodiments, the security key is obtained by the first service from the vault, and the first service embeds the security key in the access request.

[0008] In some embodiments, the access request from the first service further includes a request for the second service to perform one or more operations and / or obtain services on behalf of the first service.

[0009] In some embodiments, the second service performs one or more operations and / or obtains services on behalf of the first service and generates sub-results based on the performance of the one or more operations and / or obtains services.

[0010] In some embodiments, the second service verifies the security key before performing one or more operations and / or before obtaining services on behalf of the first service.

[0011] In some embodiments, the second pod is located in a second distributed computing environment that is different from the first distributed computing environment.

[0012] In some embodiments, the security rules for the first pod further define (i) a number of instances available for the first service and (ii) which instances are available to process the service request, and forwarding the service request to the first service includes determining the instances available to process the service request based on the security rules for the first pod and forwarding the service request to at least one of the instances of the first service.

[0013] In some embodiments, forwarding the access request from the first service to the second service includes determining whether security rules for the first pod define the second service as a service with which the first service is permitted to communicate and access; determining whether security rules for the second pod define the first service as a service with which the second service is permitted to receive communications and allow access; and forwarding the access request from the first service to the second service if the second service is a service with which the first service is permitted to communicate and access and the first service is a service with which the second service is permitted to receive communications and allow access.

[0014] In some embodiments, the security rules for the second pod further define (i) a number of instances available for the second service and (ii) which instances are available to process the access request, and forwarding the access request from the first service to the second service further includes determining the instances available to process the access request based on the security rules for the second pod and forwarding the access request to at least one of the instances of the second service.

[0015] In some embodiments, the first service includes one or more programs deployed on one or more clusters packaged as a first container or a first set of containers on a first distributed computing environment, where the first container or the first set of containers is packaged as a first pod, which is a higher-level structure representing the one or more programs running on the one or more clusters; and the second service includes one or more programs deployed on one or more clusters packaged as a second container or a second set of containers on the first distributed computing environment or a second distributed computing environment, where the second container or the second set of containers is packaged as a second pod, which is a higher-level structure representing the one or more programs running on the one or more clusters.

[0016] Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium including instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium including instructions configured to cause one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0017] The terms and expressions which have been employed are used as terms of description rather than of limitation, and there is no intention in the use of such terms and expressions to exclude any equivalents of the features shown and described, or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims. [Brief explanation of the drawings]

[0018] The present disclosure is described in conjunction with the accompanying drawings, in which:

[0019] [Figure 1] FIG. 1 illustrates a diagram of a digital health platform for providing data-driven technology solutions, according to various embodiments.

[0020] [Figure 2] 1 shows a diagram of a security system according to various embodiments.

[0021] [Figure 3] FIG. 1 illustrates a swimlane diagram illustrating a process for service-to-service communication and authentication in a digital health platform according to various embodiments.

[0022] [Figure 4] 1 shows a flowchart illustrating a process for service-to-service communication and authentication over a centralized network mesh environment, according to various embodiments.

[0023] In the accompanying drawings, similar components and / or features may have the same reference label. Furthermore, various components of the same type may be distinguished by following the reference label with a dash and by a second label that distinguishes between the similar components. When only a first reference label is used in this specification, the description is applicable to any of the similar components having the same first reference label, regardless of the second reference label. DETAILED DESCRIPTION OF THE INVENTION

[0024] I. Overview This disclosure describes techniques for service-to-service communication and authentication over a centralized network mesh in a distributed computing environment. More specifically, embodiments of the present disclosure provide a network mesh that provides pod-level networking that allows services to communicate with each other in a secure manner across multiple types of distributed computing environments. The network mesh and pod-level networking maintain isolation between services and resources, ensuring that the correct services and resources always have the correct access, regardless of where the services or resources are running or stored, so that it is easier to maintain control over where data is stored, who can access what data, and which resources a service or user can consume at a given time.

[0025] Cloud computing offers both opportunities and challenges. Like many other information technology solutions, the cloud poses various security challenges and concerns. Because cloud computing typically operates in an open and shared environment, it is often vulnerable to data loss, theft, and malicious attacks. Weak cloud security is one of the key issues preventing cloud computing from becoming fully adopted in the healthcare industry. Healthcare professionals have many reasons for not trusting cloud computing, including a lack of free control over their own medical records. Organizations and cloud providers typically store their data in different data centers located in different geographic locations. This presents unique advantages because data storage in the cloud becomes redundant and, in the event of a force majeure event, different data centers aid in disaster recovery. However, this same advantage can pose security challenges because data stored in different locations is prone to theft or loss. Furthermore, data stored in different locations and its security are governed by various international, regional, and local regulations. In general, there are many security risks associated with the use of cloud computing; for example, failure to isolate virtual users, identity theft, privilege abuse, and insufficient encryption are some of these security risks.

[0026] To address these limitations and issues, the techniques for service-to-service communication and authentication in this disclosure utilize pod-level networking managed by communication rules and security keys. In a digital and personalized healthcare environment, there are typically multiple partners interacting with each other, and these interactions need to be controlled in a secure manner to maintain isolation and traceability between services and resources. A service is any service (e.g., healthcare-related services such as data analysis or software as medical devices) that may be provided by one or more partners. A resource is generally the hardware and software resources (e.g., memory and processing units) that support the service. However, it should be understood that in certain examples, resources may also include data, algorithms, models, and the like (e.g., healthcare-related data stored in a data store). To control these interactions in a secure manner, pod-level security rules are provided that define which services are allowed to communicate with each other and which resources they are allowed to access. Additionally, security keys (e.g., public / private key pairs) are provided that allow services to access other services or resources. This two-tiered approach is facilitated by a centralized network mesh that has access to pod-level security rules and the location of each service on one or more distributed computing environments to maintain isolation and traceability between services and resources. For example, when a call for a service is received by the network mesh, the network mesh routes the call to the appropriate service based on information about the pod-level security rules and the location of the service, and the service can access other services and resources using one or more security keys and proxy calls through the network mesh to perform various operations to provide the service.

[0027] One exemplary embodiment of the present disclosure relates to a method that includes receiving a service request for a first service from a user in a network mesh and retrieving, by the network mesh, information related to the first service from a cache or service registry. The information includes an identification of a first pod that includes the first service and a location of the first pod within a first distributed computing environment. The method further includes retrieving, by the network mesh, security rules for the first pod using the location of the first pod. The security rules define (i) a unique address identifier for the first service and (ii) services with which the first service is authorized to communicate and access. The method further includes forwarding, by the network mesh, the service request to the first service using the unique address identifier for the first service, and receiving, by the network mesh, an access request from the first service to communicate with and access a second service. The access request includes a security key specific to the second service. The method further includes retrieving, by the network mesh, information related to the second service from a cache or service registry. The information includes an identification of a second pod including the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment. The method further includes obtaining, by the network mesh, security rules for the second pod using the location of the second pod. The security rules define (i) a unique address identifier for the second service and (ii) services with which the second service is authorized to communicate and access. The method further includes forwarding, by the network mesh, an access request from the first service to the second service based on the security rules for the first pod and the security rules for the second pod using the unique address identifier for the second service, and receiving, by the network mesh, a final result of the service request from the first service. The final result includes sub-results obtained from the second service.The method further includes forwarding, by the network mesh, the final result of the service request to the user. II. Digital Health Platform

[0028] FIG. 1 shows a simplified diagram of a digital health platform 100 for providing data-driven technology solutions according to various embodiments. In the illustrated embodiment, the digital health platform 100 includes client computing devices 105 coupled to a cloud-based infrastructure 110 via a network 115 including a network gateway 120 and a network mesh 125. The infrastructure 110 is adapted to run services or software applications within service pods 130 using resources provisioned within a deployment ring 135 by a cloud service provider 140 (e.g., a distributed computing environment) using various hardware and cloud infrastructures (e.g., private or on-premise cloud infrastructures and public cloud infrastructures). These services or software applications may be provided to users of the client computing devices 105 as web-based or cloud services, e.g., under an AaaS or SaaS model. Several providers offer cloud services, such as Amazon, Google, and Oracle. The term cloud service is generally used to refer to services made available to users on demand via a communications network, such as the Internet, by a service provider's system (e.g., infrastructure 110), such as a healthcare provider or government-regulated entity. Thus, consumers may utilize cloud services offered by service providers without having to purchase separate licenses, support, or hardware and software resources to support the services. For example, a cloud service provider's system may host one or more programs, and users may use the one or more programs, over the Internet, on-demand, without the users having to purchase infrastructure resources to run the one or more programs.Cloud services are designed to provide easy and scalable access to applications, resources, and services.

[0029] In some cases, a user (e.g., a software or service consumer) operating a client computing device 105 utilizes one or more client applications to consume software products, services, or systems provided by the various components 145 of the infrastructure 110. In other examples, a user (e.g., a developer) operating a client computing device 105 utilizes one or more client applications to upload source code for software products, services, or systems provided by the various components 145 of the infrastructure 110. The components 145 include software components that may be executed by one or more processors, hardware components, or combinations thereof. It should be understood that a variety of different system configurations are possible, which may differ from that depicted for the digital health platform 100. Thus, the embodiment depicted in FIG. 1 is an example of a distributed computing environment for implementing a digital health platform and is not intended to be limiting.

[0030] Client computing devices 105 include various types of computing systems, such as portable handheld devices, general-purpose computers such as personal computers and laptops, workstation computers, wearable devices, gaming systems, thin clients, various messaging devices, sensors or other sensing devices, etc. These computing devices may run various types and versions of software applications and operating systems (e.g., Microsoft Windows®, Apple Macintosh®, UNIX® or UNIX-like operating systems, Linux or Linux-like operating systems such as Google Chrome™ OS), including various mobile operating systems (e.g., Microsoft Windows Mobile®, iOS®, Windows Phone®, Android™, BlackBerry®, Palm OS®). Portable handheld devices may include mobile phones, smartphones (e.g., iPhone®), tablets (e.g., iPad®), personal digital assistants (PDAs), etc. Wearable devices may include virtual reality (VR) or augmented reality (AR) systems such as Fitbit Versa™ smartwatches, magic leap1®, HTC Vive®, and Oculus®, and other devices. Gaming systems may include various handheld gaming devices, internet-enabled gaming devices (e.g., Microsoft Xbox® game consoles with or without Kinect® gesture input devices, Sony PlayStation® systems, various gaming systems offered by Nintendo®, and others), and the like.The client device 105 may be capable of running a variety of different applications, such as various internet-related applications, communication applications (e.g., email applications, short message service (SMS) applications), etc., and may use a variety of communication protocols.

[0031] Network 115 may be any type of network familiar to those skilled in the art that is capable of supporting data communications using any of a variety of available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk®, etc. By way of example only, network 115 may be a local area network (LAN), Ethernet, token ring, wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating under any of the Institute of Electrical and Electronics Engineers (IEEE) 1002.11 suite of protocols, Bluetooth®, and / or any other wireless protocol), and / or any combination of these and / or other networks.

[0032] The network gateway 120 is a network node that forms a secure pathway between two or more of the networks 115 that operate on the same or different protocols. The network gateway 120 may provide network security using one or more of the following technologies: firewalls to monitor incoming and outgoing network traffic, virtual private networks to provide private, secure communication channels, security scans to identify security flaws in the network, access managers for authentication and authorization services, etc. The network gateway 120 routes network traffic using routers and service connectors that manage access to various software products, services, or systems (e.g., using a service subscription business model). The network mesh 125 is a local network topology in which the infrastructure 110 (e.g., bridges, switches, and other infrastructure devices) directly, dynamically, and non-hierarchically connect to as many other nodes as possible and cooperate with each other to efficiently route data between the devices and nodes. The network mesh 125 manages connectivity using one or more of techniques such as load balancing, product, service, or system discovery, network access, routing, and peering, traffic mirroring, etc. The network 115 , network gateway 120 , and network mesh 125 work in combination to manage all data flowing in and out of the infrastructure 110 .

[0033] Components 145 include one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, application-specific servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination of computers or systems operating individually or in combination to provide resources, data, services, or programs to client computing devices 105 over network 115. Components 145 may further include other computing architectures that involve virtualization, such as one or more virtual machines running virtual operating systems, or one or more flexible pools of logical storage that can be virtualized to maintain virtual storage. In various embodiments, components 145 are adapted to run one or more services or software applications that provide the functionality described in this disclosure.

[0034] Component 145 also includes one or more data repositories. These data repositories may, in various embodiments, be used to store data and other information. For example, one or more of the data repositories may be used to store information for providing data-driven technology solutions, such as Software as a Medical Device (SAMD), and for validating and deploying source code to implement the data-driven technology solutions. The data repositories may reside in various locations. For example, a data repository used by a component may be local to the component or may be remote from the component and communicate with the component via a network-based or dedicated connection. The data repositories may be of different types. In particular embodiments, the data repository used by the component may be a database, such as a centralized database, a distributed database, a NoSQL database, a relational database, or the like. One or more of these databases may be adapted to enable storage, updating, and retrieval of data to and from the database in response to SQL-formatted commands. In particular embodiments, one or more of the data repositories may also be used by an application to store application data. The data repositories used by the applications may be of different types, such as, for example, a key-value store repository, an object store repository, or a general storage repository backed by a file system.

[0035] Components 145 also include computing nodes adapted to run one or more programs, such as services or software applications (e.g., services or software applications offered as web-based or cloud services, or applications for implementing a continuous integration and continuous deployment (CI / CD) system) that provide the functionality described in this disclosure. Each node is a representation of a single machine, optionally implemented within a cluster of nodes. The single machine may be a physical machine (e.g., a server in a data center) with a set of available CPU and RAM resources or a virtual machine hosted on a cloud provider such as Amazon Web Services™ (AWS). In the cluster, nodes pool their resources to form a more powerful machine. When one or more programs are deployed on the cluster, the cluster intelligently handles distributing work to the individual nodes. As nodes are added or removed, the cluster can shift work as needed. Which individual machine actually runs the code is not important to the one or more programs or to infrastructure 110.

[0036] One or more programs deployed to one or more clusters are packaged as containers. Containers are a widely accepted standard, and various images can be defined for deploying one or more programs on the infrastructure 110. Containerization enables the infrastructure 110 to create self-contained execution environments. Any program and all of its dependencies can be packaged into a single file and then shared across the infrastructure 110. Container creation can be done programmatically, enabling powerful, fully automated CI / CD pipelines used to validate and deploy code on the infrastructure 110. Containers are wrapped into higher-level constructs known as pods 130. Containers within the same pod 130 can share the same resources and local network. In some cases, containers can communicate with other containers within the same pod 130 as if they were on the same machine, while maintaining a degree of isolation from others. Pods 130 are used as the unit of replication within the infrastructure 110. When a program or resource becomes overwhelmed with processing and a single pod 130 instance cannot carry the load, the infrastructure 110 can be configured to deploy new replicas of the pod 130 in a cluster as needed. Even when not under heavy load, it can be beneficial to have multiple copies of the pod 130 running at any time in a production system to enable load balancing and fault tolerance. One or more instances of the pod 130 are provisioned in a cloud infrastructure system provided by one or more cloud service providers 140.

[0037] The cloud infrastructure system provided by one or more cloud service providers 140 includes infrastructure resources utilized to facilitate the provisioning of one or more instances of pods 130 that support various cloud services provided by infrastructure 110. To facilitate efficient utilization of these resources for provisioning one or more instances of pods 130, the resources may be bundled into sets of resources or resource modules (also referred to as “deployment rings 135” or “stateful rings 135”). Each resource module or deployment ring 135 may include a pre-integrated and optimized combination of one or more types of resources. In certain examples, different deployment rings 135 may be pre-provisioned for different types of cloud services. For example, a first set of deployment rings 135 may be provisioned for SAMD services, a second set of deployment rings 135 may include a different combination of resources than the deployment rings 135 in the first set of deployment rings 135, may be provisioned for data analytics services, and so on. For some cloud services, resources allocated for provisioning services may be shared between services.

[0038] The digital health platform 100 further includes one or more kernels 150. The kernels 150 are adapted to run on each cloud infrastructure system provided by one or more cloud service providers 140. The kernels 150 are cluster managers that provide resource allocation and isolation across distributed applications or frameworks across the digital health platform 100. The kernels 150 provide an application programming interface (API) to one or more programs for orchestration of services and software, including resource management and scheduling. The architecture of the kernels 150 includes agent nodes for executing tasks, master nodes for sending tasks to agent nodes, a domain manager for election and for looking up addresses of master nodes, and a framework for coordinating with the master nodes to schedule tasks on agent nodes.

[0039] The digital health platform 100 further includes a CI / CD system 155. The CI / CD system 155 is implemented within a cloud infrastructure system, allowing the digital health platform 100 to frequently update, test, and distribute changes within the source code of a software product, service, or system. As described in detail herein, in healthcare, there are government regulations regarding data security (e.g., data integrity and data privacy) that software must comply with. The CI / CD system 155 can include these policy regulations in the code, allowing compliance to be automatically tracked, verified, and reconfigured. In the SAMD example, data storage locations, server access controls, and activity logging can be included in the source code to protect and manage user data during software use. Encryption and password-protected operations can further be included during continuous integration. During continuous delivery, security and monitoring tools can be used to track user activity and detect errors that may lead to security threats.

[0040] The CI / CD system 155 may also be used to provision machine learning models. Machine-learning models are initially trained using a dataset, but over time, the model may drift or the data may change, resulting in the need for an updated machine learning model. When a machine learning model runs within a software application, code associated with the software application may include triggers for when the machine learning model should be retrained. For example, the code may include instructions to retrain the machine learning model at predetermined time intervals, when new training data is available, or when the machine learning model's performance is determined to fall below a threshold. Additionally, software developers may explore variations in model architecture and hyperparameters in a test environment based on monitoring the performance of the machine learning model in a production environment or based on estimated improvements for model optimization. The CI / CD system 155 enables machine learning models to be easily built, tested, and deployed to a production environment when they are determined to meet performance requirements. III.Security System

[0041] FIG. 2 illustrates a simplified diagram of a security system 200 (including the network gateway 120, network mesh 125, and pods 130 described with reference to FIG. 1) for service-to-service communication and authentication via a centralized network mesh in a distributed computing environment 205, according to various embodiments. While only a single distributed computing environment is shown, it should be understood that multiple distributed computing environments may be implemented within the digital health platform, with each distributed computing environment having its own set of components shown in FIG. 2. In the illustrated embodiment, the security system 200 includes one or more client applications 210 (e.g., applications / software modules within devices operated by human actors, such as patients and / or service consumers), a Domain Name System (DNS) 215, a gateway 220, a network mesh 225, a public agent 230, and a private agent 235. The public agent 230 provides public services to the user 210. The private agent 235 includes a service pod 240, a vault 245, and a vault gateway 250 that cooperate to provide private services.

[0042] The client application 210 is operated by a user to consume software products, services, or systems provided by the digital health platform. The client application 210 may consume the software products, services, or systems by communicating (e.g., sending requests) with the digital health platform via a distributed computing environment connector and DNS 215. The DNS 215 is a hierarchical, distributed database that stores IP addresses and other data, allowing IP addresses to be looked up by name in order to forward calls to the IP address. For example, when a request from a user is received by the digital health platform, the distributed computing environment connector identifies a distributed computing environment that can fulfill the request and forwards the request and the distributed computing environment that can fulfill the request to the DNS 215, which looks up the IP address and other data associated with the distributed computing environment and forwards the request to the gateway endpoint of the gateway (e.g., gateway 220) of the associated distributed computing environment (e.g., distributed computing environment 205).

[0043] Once connected to the gateway endpoint, the client application 210 can communicate with an authorization unit (e.g., an access management system) to access one or more services within the session. For illustrative purposes, a "session" described herein includes a session or an access session that provides a user with access to one or more services. A session disclosed herein may be referred to, for example, as an SSO session, an authentication session, or any other type of session that provides a user with access. A service may include, but is not limited to, access and functionality provided by a file, a web page, electronic content, a document, web content, a computing resource, or an application. For example, a digital health platform may include accessible services such as a software product, a cloud service, or a system. A service may be requested and accessed using an application. For example, an application may request access to a service from a service server based on a URL that identifies the requested service. As used herein, when an action is "triggered" or "based on" something, this means that the action is triggered by or based at least in part on something. A service may be stored and / or managed by one or more computer systems, for example, a distributed computing system. The distributed computing system may facilitate or control access to one or more services upon authentication of a user via a client application 210.

[0044] To allow one of the services on a client computing device to be accessed by client application 210, a user is required to authenticate to establish a session (e.g., an SSO session) that provides the user with access to the service via client application 210. The client computing device initiates the authentication process by requesting access from an authorization department. The authentication process may include the client computing device displaying one or more GUIs to receive the user's authentication information and submitting a request for authentication to the authorization department. Authentication is established based on verifying the user's authentication information against the authentication defined for the service to which access is requested. When attempting to access a service, the user interacts with an application (e.g., part of client application 210 or a separate application) that manages access to the user's account via the authorization department. For example, the application may be an access management application that may present a GUI. Using the application and / or client application 210, the user requests access to one or more services, authenticates, and requests a change in authentication level.

[0045] Communications between a user's client computing device and the authorizer are received via gateway 220. Gateway 220 supports access management services. For example, the SSO gateway may implement one or more access agents to balance and / or process requests from client application 210 and the authorizer. The client computing device may send and receive one or more communications with an agent to facilitate access to one or more services by the client computing device. The authorizer may send and receive one or more communications with an agent to facilitate access to one or more services by the client computing device. The service may be accessible to client application 210 based on successful authentication of the authentication information. Upon receiving the authentication information, the authorizer verifies whether the requested service is a protected service that requires authentication information for access. The authorizer determines whether access to the service is protected. If the service is not protected, the authorizer authorizes access to the service (e.g., a public service). If the authorizer determines that access to the service is protected, the authorizer determines authentication of the user via client application 210 based on the authentication information. Specifically, the authorization unit may collect authentication information for one or more levels and / or one or more factors of authentication, and the authorization unit may verify whether the authentication information matches the authentication information registered to allow the user to access the service via the client application 210. Upon determining the user's authentication, the authorization unit may determine whether the user is authorized to access the service based on the access granted to the user. The authorization unit may send a communication to the client computing device to indicate the user's authorization regarding whether the user is authorized to access the service.The service is then enabled as a service accessible to the user via client application 210 upon determining that the user is authenticated and authorized to access the service at will.

[0046] When a service is enabled as an accessible service to client application 210, gateway 220 forwards the request to network mesh 225. Network mesh 225 is a dedicated layer embedded in a distributed computing environment that manages communication and networking concerns at the service level (e.g., how various services share data with each other). Ideally, the less communication between services, the better. However, avoidance is not always possible, as services often depend on each other to complete operations. In such cases, network mesh 225 manages and protects communication between services by (i) authenticating subsequent requests or interactions between users and various services using an authorization unit, (ii) optionally encrypting communication between services, and (iii) enforcing security rules or policies (e.g., pod-level security rules for communication between services within the same pod and between services in different pods). To facilitate these operations, network mesh 225 includes a router and one or more proxies adapted to intercept calls to and between services and is configured with security rules or policies for controlling and routing calls to and between services. In addition to managing and ensuring communication between services, network mesh 225 may also provide support for service discovery and load balancing. For example, network mesh 225 may obtain a corresponding pool of service instances from a pod endpoint. Network mesh 225 then sends or routes requests to specific service instances and records the resulting latency and response type. Network mesh 225 may select the instance most likely to return a fast response based on various factors, including the observed latency of recent requests.

[0047] Public agent 230 is adapted to provide one or more public services. Although these services are designated as public, this does not necessarily mean that authentication / authorization is not required to access the public service. In some cases, one or more levels or factors of authentication and / or authorization may be required to access the public service. Network mesh 225 manages and secures communications between client application 210 and public agent 230. In some cases, this includes authenticating requests or interactions between users and various public services using an authorization unit and routing calls to and between services provided by public agent 230 while enforcing security rules or policies.

[0048] Private agent 235 is adapted to provide one or more private services contained within service pod 240 (e.g., a first service with a first pod and a second service in a second pod). Network mesh 225 manages and secures communications between client application 210 and private agent 235. In some cases, this includes routing calls to and between services provided by private agent 235 while enforcing security rules or policies. Private agent 235 utilizes vault 245 and vault gateway 250 to manage and store security or access keys used by each service to communicate with and access other services. Vault gateway 250 is a network node that forms a secure pathway between services and vault 245. Vault gateway 250 may provide vault network security using one or more of the following technologies: firewalls to monitor incoming and outgoing network traffic, virtual private networks to provide private, secure communication channels, security scans to identify security flaws in the network, access managers for authentication and authorization services, etc. Vault gateway 250 routes vault traffic using routers and service connectors that manage access to the vault and various secrets, ie, security or access keys.

[0049] Vault 245 manages and stores security keys or access keys. A security key is short-term authentication information for a service to communicate with and access another service. A security key can be used to sign programmatic requests to another service (e.g., the service's application programming interface). A security key consists of an access identifier and a secret access key. Similar to a username and password, a service must use both the access identifier and the secret access key together to authenticate an access request. Security keys can be managed using one or more rules or policies stored in a data store ("policies") to control access to services. Policies define which other services can be accessed by each service. For example, an administrator may only allow certain services to be accessed by certain services to maintain separation and / or data privacy between services. Vault 245 determines which services obtain which security keys to access other services based on one or more of the policies. IV. Technology for deploying services on the digital health platform

[0050] 3 and 4 illustrate processes and operations for inter-service communication and authentication over a centralized network mesh. Individual embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. While the flowcharts describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed but may have additional steps not included in the diagrams. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to a calling function or a main function.

[0051] The processes and / or operations illustrated in FIGS. 3 and 4 may be implemented in software (e.g., code, instructions, programs) executed by one or more processing units (e.g., processor cores), hardware, or a combination thereof. The software may be stored in memory (e.g., on a memory device, on a non-transitory computer-readable storage medium). The particular sequence of processing steps in FIGS. 3 and 4 is not intended to be limiting. Other sequences of steps may be performed according to alternative embodiments. For example, in alternative embodiments, the steps outlined above may be performed in a different order. Furthermore, individual steps illustrated in FIGS. 3 and 4 may include multiple sub-steps that may be performed in various orders as appropriate for the individual step. Furthermore, additional steps may be added or deleted depending on the particular application. Those skilled in the art will recognize many variations, modifications, and alternatives.

[0052] 3 illustrates a process 300 for service-to-service communication and authentication in a digital health platform. The process illustrated in flowchart 300 is implemented by the architecture, systems, and techniques illustrated in FIGS. 1 and 2.

[0053] In step 305, the network mesh receives a service request (e.g., a request from a user for access to a service such as Service A). The network mesh resolves the request by determining whether the network mesh is familiar with the service. This determination may be made by determining whether the network mesh has data about the service in a cache. A cache is a hardware or software component that stores data (e.g., information about various services) so that future requests for that data can be processed more quickly. Data stored in a cache may be the result of a previous request for the service or a copy of the data stored elsewhere. If the network mesh has data about the service in its cache, the network mesh retrieves the data from the cache. The data includes identification of one or more pods (e.g., Pod A) that contain the service (e.g., Service A) and the location of the one or more pods within the distributed computing environment. The location may include a particular distributed computing environment, node, cluster of nodes, instance of a node or cluster, or a combination thereof, running the one or more pods. The data informs the network mesh which pods encapsulate services (e.g., manage services) and how to contact the pods encapsulating the services (e.g., the IP addresses of the pods in a distributed computing environment).

[0054] In step 310, if the network mesh does not have data on the service in its cache, the network mesh contacts a data registry to obtain the data on the service. The data registry is a single point of truth that stores data about all services running on a digital health platform (e.g., multiple distributed computing environments). Similar to a cache, the data informs the network mesh which pod encapsulates the service (e.g., manages the service) and how to contact the pod encapsulating the service (e.g., the IP address of the pod in the distributed computing environment). Data obtained by the network mesh from the registry may be stored in a cache for downstream processing and future requests.

[0055] In step 315, the network mesh communicates with one or more pods (e.g., Pod A) that encapsulate the services based on the data retrieved from the cache or registry. The communication includes a request from the network mesh for security rules for the one or more pods. The security rules define (i) a unique address identifier for the service and (ii) the services with which the service is allowed to communicate and access. For example, the security rules for Pod A define unique address identifiers for Service A and the services with which Service A is allowed to communicate and access. When each pod is created, it is assigned rules or policies that govern the other pods or services that may communicate with and access the service encapsulated by each pod. The one or more rules may be written by an administrator, such as an administrator of the digital health platform. Furthermore, when created, each service is assigned a unique address identifier address. This address is tied to the life of the service and does not change while the service is active. The network mesh and pods communicate with services via unique address identifiers, and that communication to services can be governed by rules or policies and automatically load balanced to instances of pods that encapsulate the services.

[0056] In step 320, security rules for one or more pods are obtained from one or more pods (e.g., pod A). The one or more pods receive a request from the network mesh for security rules, obtain the security rules from a data store, and forward the security rules to the network mesh.

[0057] In step 325, the service request is forwarded to a service (e.g., Service A) based on the security rules. For example, the network mesh uses a unique address identifier for the service to communicate with the resource request and forward the resource request to the resource. In some cases, the network mesh uses the unique address identifier and a proxy associated with the service to communicate with the service and forward the service request to the service. The proxy may then be used for any subsequent communication with the service regarding the service request.

[0058] At step 330, the service receives and processes the service request. Processing includes the service performing one or more programmatic operations to fulfill the service request. For example, for a service request, the service may perform one or more operations to provide a service, such as collecting medical data, transforming medical data, or communicating medical data. In some cases, as part of fulfilling the service request, the service may need to communicate with and access (e.g., retrieve data from a separate data store, such as Service B) another service on another pod (e.g., Pod B). In such a case, at step 335, the service connects to the vault to obtain a private key to communicate with and access another service on another pod.

[0059] In step 335, the vault connects to the service and controls access to the other service using one or more rules or policies stored in the data store. For example, upon connecting to the service, the vault determines whether the service is authorized to communicate with and access the other service based on one or more policies. If the service is authorized to communicate with and access the other service based on one or more of the policies, the vault obtains a security key for the other service and forwards the security key to the service in step 340. If the service is not authorized to communicate with and access the other service based on the one or more policies, the vault notifies the service that it is not authorized to communicate with and access the other service.

[0060] In step 345, if the service is authorized to communicate with and access another service, the service receives the security key of the other service and embeds the security key in an access request to the other service. For example, the service may generate an access request requesting the other service to perform one or more programmatic operations to assist in fulfilling the service request. The access request may be signed using the security key.

[0061] In step 350, the service communicates the access request with the network mesh. In some cases, the service communicates the access request with the network mesh through a proxy associated with the service. The service communicates the access request to the network mesh because (i) the service does not have a unique address identifier for the service and (ii) the network mesh allows the network mesh to maintain control and security over all inter-service communications.

[0062] The network mesh receives and processes the access request from the service in step 355. The processing of the access request is similar to the processing of the service request described with respect to steps 305-325 (not shown in FIG. 3).

[0063] In step 360, the network mesh forwards the access request from the service to another service based on the security rules of the pod (e.g., Pod A) associated with the service and the security rules of the pod (e.g., Pod B) associated with the other service. In some cases, the network mesh forwards the access request from the service to another service through a proxy associated with the service. Forwarding includes the network mesh determining whether the security rules of the pod (e.g., Pod A) define the other service (e.g., Service B) as a service with which the service (e.g., Service A) is authorized to communicate and access, and determining whether the security rules of the other pod (e.g., Pod B) define the service (e.g., Service A) as a service with which the other service (e.g., Service B) is authorized to receive communications and access. If the other service (e.g., Service B) is a service with which the service (e.g., Service A) is authorized to communicate and access, and the service (e.g., Service A) is a service with which the other service (e.g., Service B) is authorized to receive communications and grant access, the access request from the service is forwarded to the other service.

[0064] In step 365, the other service receives the access request from the network mesh and verifies the security key. If the security key is invalid, the other service notifies the service of the invalid security key directly. If the security key is valid, the other service processes the access request. The processing includes the other service performing one or more program operations to help fulfill the service request. For example, in the case of a service request, the service may perform one or more operations to provide a service such as collecting medical data, converting medical data, or communicating medical data.

[0065] The other service returns the results of processing the access request directly to the service in step 370. In some cases, the other service communicates the results of the access request with the service through a proxy associated with the service.

[0066] In step 375, the service receives the results of the access request and combines the results of the access request with the results of the service processing the service request to generate a final result for the service request. The service may then output the final result of the service request to the network mesh, which communicates the final result of the service request to the user, for example, via a network gateway.

[0067] 4 shows a process 400 for service-to-service communication and authentication over a centralized network mesh. In step 405, the network mesh receives a service request for a first service, for example, from a user. In some cases, the service request is a request for a service, and the first service is a first service. The first service may include one or more programs deployed on one or more clusters packaged as a first container or a first set of containers on a first distributed computing environment, and the first container or first set of containers may be packaged as a first pod, which is a high-level construct representing the one or more programs running on the one or more clusters.

[0068] In step 410, the network mesh retrieves information related to the first service from a cache or service registry. The information includes an identification of a first pod that includes the first service and a location of the first pod within the first distributed computing environment. Retrieving the information may include: (i) determining whether the information related to the first service is available from the cache; (ii) retrieving the information related to the first service from the cache if the information related to the first service is available from the cache; (iii) retrieving the information related to the first service from the registry if the information related to the first service is not available from the cache; and (iv) storing the information related to the first service in the cache for subsequent requests in response to retrieving the information related to the first service from the registry.

[0069] In step 415, the network mesh uses the location of the first pod to obtain security rules for the first pod. The security rules define (i) a unique address identifier for the first service and (ii) services that the first service is allowed to communicate with and access. In some cases, the security rules further define (iii) the number of instances available for the first service and (iv) which instances are available to process service requests.

[0070] In step 420, the network mesh forwards the service request to the first service based on the security rules for the first pod, including (i) determining an available instance to process the service request based on the security rules for the first pod, and (ii) forwarding the service request to at least one of the instances of the first service using a unique address identifier for the first service.

[0071] In step 425, the network mesh receives an access request from the first service to communicate with and access the second service. The second service may include one or more programs deployed on one or more clusters packaged as a second container or a second set of containers on the first distributed computing environment or the second distributed computing environment, and the second container or the second set of containers may be packaged as a second pod, which is a higher-level construct representing one or more programs running on the one or more clusters. The access request includes a security key specific to the second service. The security key is retrieved by the first service from the vault, and the first service embeds the security key in the access request. The access request may also include a request for the second service to perform one or more operations on behalf of the first service and / or obtain a service. In some cases, the access request is a request for a service, and the second service is a second service.

[0072] In step 430, the network mesh retrieves information related to the second service from a cache or service registry. The information includes an identification of a second pod including the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment. In some cases, the second pod is located in a second distributed computing environment different from the first distributed computing environment. Retrieving the information may include: (i) determining whether the information related to the second service is available from the cache; (ii) retrieving the information related to the second service from the cache if the information related to the second service is available from the cache; (iii) retrieving the information related to the second service from the registry if the information related to the second service is not available from the cache; and (iv) storing the information related to the second service in the cache for subsequent requests in response to retrieving the information related to the second service from the registry.

[0073] In step 435, the network mesh uses the location of the second pod to obtain security rules for the second pod. The security rules define (i) a unique address identifier for the second service and (ii) services that the second service is allowed to communicate with and access. In some cases, the security rules further define (iii) the number of instances available for the second service and (iv) which instances are available to process access requests.

[0074] In step 440, the network mesh forwards the access request to the second service based on the security rules for the first pod and the security rules for the second pod. The forwarding includes (i) determining whether the security rules for the second pod define the second service as a service with which the first service is permitted to communicate and access, (ii) determining whether the security rules for the second pod define the first service as a service with which the second service is permitted to receive communications and allow access, and (iii) if the second service is a service with which the first service is permitted to communicate and access and the first service is a service with which the second service is permitted to receive communications and allow access, forwarding the access request from the first service to the second service using a unique address identifier for the second service. In some cases, the forwarding further includes (iv) determining available instances to process the access request based on security rules for the second pod and forwarding the access request to at least one of the instances of the second service using a unique address identifier for the second service. The second service may perform one or more operations and / or obtain services on behalf of the first service and may generate sub-results based on the performance of the one or more operations and / or obtain services. The second service may verify a security key before performing the one or more operations and / or obtaining services on behalf of the first service.

[0075] In step 445, the network mesh receives a final result of the service request from the first service, the final result including the sub-results obtained from the second service.

[0076] In step 450, the network mesh outputs the final result of the service request and, in some cases, communicates the final result to, for example, a user. V. Further Considerations

[0077] Some embodiments of the present disclosure include a system including one or more data processors. In some embodiments, the system includes a non-transitory computer-readable storage medium including instructions that, when executed on the one or more data processors, cause the one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein. Some embodiments of the present disclosure include a computer program product tangibly embodied in a non-transitory machine-readable storage medium including instructions configured to cause one or more data processors to perform some or all of one or more methods and / or some or all of one or more processes disclosed herein.

[0078] The terms and expressions which have been employed are used as terms of description rather than of limitation, and there is no intention in the use of such terms and expressions to exclude any equivalents of the features shown and described, or portions thereof, but it is recognized that various modifications are possible within the scope of the invention as claimed. Thus, although the claimed invention has been specifically disclosed by embodiments and optional features, it will be understood that modifications and variations of the concepts disclosed herein may be resorted to by those skilled in the art, and that such modifications and variations are deemed to be within the scope of the invention as defined by the appended claims.

[0079] The following description provides only preferred exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of preferred exemplary embodiments will provide those skilled in the art with an enabling description for implementing various embodiments. It will be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the appended claims.

[0080] Specific details are given in the following description to provide a thorough understanding of the embodiments. However, it will be understood that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

Claims

1. 1. A computer-implemented method comprising: receiving a service request for a first service at a network mesh; retrieving, by the network mesh, information related to the first service from a cache or service registry, the information including an identification of a first pod that includes the first service and a location of the first pod within a first distributed computing environment; obtaining, by the network mesh, security rules for the first pod using the location of the first pod, the security rules defining (i) a unique address identifier for the first service and (ii) services that the first service is allowed to communicate with and access; forwarding, by the network mesh, the service request to the first service using the unique address identifier for the first service; receiving, by the network mesh, an access request from the first service to communicate with and access a second service, the access request including a security key specific to the second service; retrieving, by the network mesh, information related to the second service from the cache or the service registry, the information including an identification of a second pod that includes the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment; and obtaining, by the network mesh, security rules for the second pod using the location of the second pod, the security rules defining (i) a unique address identifier for the second service and (ii) services that the second service is allowed to communicate with and access; forwarding, by the network mesh, the access request from the first service to the second service based on the security rules for the first pod and the security rules for the second pod using the unique address identifier for the second service; receiving, by the network mesh, a final result of the service request from the first service, the final result including sub-results obtained from the second service; and outputting, by the network mesh, the final result of the service request.

2. obtaining the information related to the first service or obtaining the information related to the second service, determining whether the information related to the first service or the second service is available from the cache; and If the information related to the first service or the second service is available from the cache, obtaining the information related to the first service or the second service from the cache; if the information related to the first service or the second service is not available from the cache, obtaining the information related to the first service or the second service from the registry; 2. The computer-implemented method of claim 1, further comprising: in response to retrieving the information related to the first service or the second service from the registry, storing the information related to the first service or the second service in the cache for subsequent requests.

3. The computer-implemented method of claim 1 or 2, wherein the security key is obtained by the first service from a vault, and the first service embeds the security key in the access request.

4. 4. The computer-implemented method of claim 3, wherein the access request from the first service further comprises a request for the second service to perform one or more actions and / or obtain services on behalf of the first service.

5. 5. The computer-implemented method of claim 4, wherein the second service performs the one or more actions and / or obtains the service on behalf of the first service and generates the sub-result based on the performance of the one or more actions and / or obtains the service.

6. 6. The computer-implemented method of claim 5, wherein the second service verifies the security key before performing the one or more actions and / or before obtaining the service on behalf of the first service.

7. The computer-implemented method of claim 1 , wherein the second pod is located in the second distributed computing environment that is different from the first distributed computing environment.

8. the security rules for the first pod further define (i) a number of instances available for the first service, and (ii) which instances are available to process the service request, and forwarding the service request to the first service; determining the instances available to process the service request based on the security rules for the first pod; and forwarding the service request to at least one of the instances of the first service.

9. forwarding the access request from the first service to the second service; determining whether the security rules for the first pod define the second service as a service that the first service is allowed to communicate with and access; determining whether the security rules for the second pod define the first service as a service that is permitted to allow the second service to receive and access communications; 9. The computer-implemented method of claim 1, further comprising: forwarding the access request from the first service to the second service if the second service is a service with which the first service is authorized to communicate and access, and the first service is a service with which the second service is authorized to receive communications and grant access.

10. the security rules for the second pod further define (i) a number of instances available for the second service and (ii) which instances are available to process the access request, and forwarding the access request from the first service to the second service; determining the instance available to process the access request based on the security rules for the second pod; and 10. The computer-implemented method of claim 9, further comprising forwarding the access request to at least one of the instances of the second service.

11. the first service includes one or more programs deployed on one or more clusters packaged as a first container or a first set of containers on the first distributed computing environment, the first container or the first set of containers packaged as the first pod, which is a high-level construct representing the one or more programs running on the one or more clusters; 11. The computer-implemented method of claim 1, wherein the second service includes one or more programs deployed on one or more clusters packaged as a second container or a second set of containers on the first or second distributed computing environment, the second container or the second set of containers packaged as the second pod, which is a higher-level construct representing the one or more programs running on the one or more clusters.

12. 1. A system comprising: one or more data processors in a network mesh; A non-transitory computer-readable storage medium containing instructions that, when executed on the one or more data processors, cause the one or more data processors to: receiving a service request for a first service; retrieving information related to the first service from a cache or service registry, the information including an identification of a first pod that includes the first service and a location of the first pod within a first distributed computing environment; Using the location of the first pod, obtain security rules for the first pod, the security rules defining (i) a unique address identifier for the first service and (ii) services that the first service is allowed to communicate with and access; forwarding the service request to the first service using the unique address identifier for the first service; receiving an access request from the first service to communicate with and access a second service, the access request including a security key specific to the second service; retrieving information related to the second service from the cache or the service registry, the information including an identification of a second pod that includes the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment; Using the location of the second pod, obtain security rules for the second pod, the security rules defining (i) a unique address identifier for the second service and (ii) services that the second service is allowed to communicate with and access; forwarding the access request from the first service to the second service based on the security rules for the first pod and the security rules for the second pod using the unique address identifier for the second service; receiving a final result of the service request from the first service, the final result including sub-results obtained from the second service; and outputting the final result of the service request.

13. obtaining the information related to the first service or obtaining the information related to the second service, determining whether the information related to the first service or the second service is available from the cache; and If the information related to the first service or the second service is available from the cache, obtaining the information related to the first service or the second service from the cache; if the information related to the first service or the second service is not available from the cache, obtaining the information related to the first service or the second service from the registry; and in response to retrieving the information related to the first service or the second service from the registry, storing the information related to the first service or the second service in the cache for subsequent requests.

14. The system of claim 12 or 13, wherein the security key is obtained by the first service from a vault, and the first service embeds the security key in the access request.

15. 15. The system of claim 14, wherein the access request from the first service further comprises a request for the second service to perform one or more actions and / or obtain services on behalf of the first service.

16. The system of claim 15 , wherein the second service performs the one or more actions and / or obtains the service on behalf of the first service and generates the sub-result based on the performance of the one or more actions and / or the obtainment of the service.

17. 17. The system of claim 16, wherein the second service verifies the security key before performing the one or more actions and / or before obtaining the service on behalf of the first service.

18. 18. The system of claim 12, wherein the second pod is located in the second distributed computing environment that is different from the first distributed computing environment.

19. the security rules for the first pod further define (i) a number of instances available for the first service, and (ii) which instances are available to process the service request, and forwarding the service request to the first service; determining the instances available to process the service request based on the security rules for the first pod; and forwarding the service request to at least one of the instances of the first service.

20. forwarding the access request from the first service to the second service; determining whether the security rules for the first pod define the second service as a service that the first service is allowed to communicate with and access; determining whether the security rules for the second pod define the first service as a service that is permitted to allow the second service to receive and access communications; and forwarding the access request from the first service to the second service if the second service is a service with which the first service is authorized to communicate and access, and the first service is a service with which the second service is authorized to receive communications and grant access.

21. the security rules for the second pod further define (i) a number of instances available for the second service and (ii) which instances are available to process the access request, and forwarding the access request from the first service to the second service; determining the instance available to process the access request based on the security rules for the second pod; and 21. The system of claim 20, further comprising: forwarding the access request to at least one of the instances of the second service.

22. the first service includes one or more programs deployed on one or more clusters packaged as a first container or a first set of containers on the first distributed computing environment, the first container or the first set of containers packaged as the first pod, which is a high-level construct representing the one or more programs running on the one or more clusters; 22. The system of claim 12, wherein the second service includes one or more programs deployed on one or more clusters packaged as a second container or a second set of containers on the first or second distributed computing environment, the second container or the second set of containers packaged as the second pod, which is a higher-level construct representing the one or more programs running on the one or more clusters.

23. 1. A computer program product for causing one or more data processors of a network mesh to perform operations, said operations comprising: receiving a service request for a first service; retrieving information related to the first service from a cache or service registry, the information including an identification of a first pod that includes the first service and a location of the first pod within a first distributed computing environment; Using the location of the first pod, obtain security rules for the first pod, the security rules defining (i) a unique address identifier for the first service and (ii) services that the first service is allowed to communicate with and access; forwarding the service request to the first service using the unique address identifier for the first service; receiving an access request from the first service to communicate with and access a second service, the access request including a security key specific to the second service; retrieving information related to the second service from the cache or the service registry, the information including an identification of a second pod that includes the second service and a location of the second pod within the first distributed computing environment or the second distributed computing environment; Using the location of the second pod, obtain security rules for the second pod, the security rules defining (i) a unique address identifier for the second service and (ii) services that the second service is allowed to communicate with and access; forwarding the access request from the first service to the second service based on the security rules for the first pod and the security rules for the second pod using the unique address identifier for the second service; receiving a final result of the service request from the first service, the final result including sub-results obtained from the second service; and outputting the final result of the service request.

24. obtaining the information related to the first service or obtaining the information related to the second service, determining whether the information related to the first service or the second service is available from the cache; and If the information related to the first service or the second service is available from the cache, obtaining the information related to the first service or the second service from the cache; if the information related to the first service or the second service is not available from the cache, obtaining the information related to the first service or the second service from the registry; 24. The computer program product of claim 23, further comprising: in response to retrieving the information related to the first service or the second service from the registry, storing the information related to the first service or the second service in the cache for subsequent requests.

25. 25. The computer program product of claim 23 or 24, wherein the security key is obtained by the first service from a vault, and the first service embeds the security key in the access request.

26. 26. The computer program product of claim 25, wherein the access request from the first service further comprises a request for the second service to perform one or more actions and / or obtain services on behalf of the first service.

27. 27. The computer program product of claim 26, wherein the second service performs the one or more actions and / or obtains the service on behalf of the first service and generates the sub-result based on the performance of the one or more actions and / or the obtainment of the service.

28. 28. The computer program product of claim 27, wherein the second service verifies the security key before performing the one or more actions and / or before obtaining the service on behalf of the first service.

29. 29. The computer program product of claim 23, wherein the second pod is located in the second distributed computing environment that is different from the first distributed computing environment.

30. the security rules for the first pod further define (i) a number of instances available for the first service, and (ii) which instances are available to process the service request, and forwarding the service request to the first service; determining the instances available to process the service request based on the security rules for the first pod; and forwarding the service request to at least one of the instances of the first service.

31. forwarding the access request from the first service to the second service; determining whether the security rules for the first pod define the second service as a service that the first service is allowed to communicate with and access; determining whether the security rules for the second pod define the first service as a service that is permitted to allow the second service to receive and access communications; and forwarding the access request from the first service to the second service if the second service is a service with which the first service is authorized to communicate and access, and the first service is a service with which the second service is authorized to receive communications and grant access.

32. the security rules for the second pod further define (i) a number of instances available for the second service and (ii) which instances are available to process the access request, and forwarding the access request from the first service to the second service; determining the instance available to process the access request based on the security rules for the second pod; and 32. The computer program product of claim 31, further comprising forwarding the access request to at least one of the instances of the second service.

33. the first service includes one or more programs deployed on one or more clusters packaged as a first container or a first set of containers on the first distributed computing environment, the first container or the first set of containers packaged as the first pod, which is a high-level construct representing the one or more programs running on the one or more clusters; 33. The computer program of claim 23, wherein the second service includes one or more programs deployed on one or more clusters packaged as a second container or a second set of containers on the first or second distributed computing environment, the second container or the second set of containers packaged as the second pod, which is a higher-level construct representing the one or more programs running on the one or more clusters.

34. A non-transitory machine-readable storage medium having recorded thereon a computer program according to any one of claims 23 to 33.

Images