Dynamic access control in service mesh with service broker

One example method includes performing dynamic access control in a computing network. A computing environment is configured such that an application can access a service without specifying secrets. The secrets needed to access the service are obtained and stored in a credential store. The secrets can be obtained using the service mesh in a manner that isolates the application from the secrets.

FIELD OF THE INVENTION

Embodiments of the present invention generally relate to access control and access control operations. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for performing dynamic access control operations in a service mesh.

BACKGROUND

Many applications are constructed to user services and there is, as a result, a need to communicate with various services. For example, an online retail application may have a component that allows a user to browse products. This application, however, may need to know whether a particular product is actually in stock. Thus, the retail application may need to communicate with a service such as a database that stores inventory information.

Rather than coding the online application directly to communicate with the database, a service mesh is often used. A service mesh allows some aspects of the application related to communication between services, to be abstracted to the infrastructure. More specifically, a service mesh can take the details of how a request gets from the retail application to the database out of the retail application's logic. This function is abstracted to an infrastructure layer—the service mesh. Without a service mesh, each application (e.g., microservice) would include logic to control service-to-service communication. This clearly complicates application development.

Even though a service mesh provides various advantages, conventional service meshes have trouble handling situations where secrets (e.g., credentials) are required. For example, in order to use third-party services, code must be added to an application such that secrets can be handled. For example, the application must be configured to read the secrets from environment variables, configuration files, or command line arguments.

This code complicates the development of the application, prolongs the development cycle, and forces the developer to learn details about the third-party service. For example, an authentication mechanism may differ based on service provider—even for the same service type. A database service from Azure, for example may have different authentication mechanisms than database services from other providers.

Further, current methods for using services, including third-party services, include storing the secrets by the application. For example, Kubernetes implements a service catalog, which is an example of a service broker. In this example, the service catalog may request the secrets and the secrets may be stored in an API server (a server that allows applications to each other). If any of the components are compromised, the secrets may be exposed in this environment.

Another problem facing developers is the need to compare third-party services for cost or performance. This is typically done by the developer and requires time. Further, each time the services changes, the developer may be required to invest more time researching the cost and performance of the third-party services.

In addition, application programming interfaces (APIs) and services are being updated more frequently. Applications that use these APIs and services are therefore required to react to these changes. This can impact the cost of development and maintenance.

DETAILED DESCRIPTION OF SOME EXAMPLE EMBODIMENTS

Embodiments of the present invention generally relate to dynamic access control. More particularly, at least some embodiments of the invention relate to systems, hardware, software, computer-readable media, and methods for controlling access and secrets in a service mesh with a service broker.

Embodiments of the invention allow authentication operations including dynamic access control to be abstracted to the service mesh. Embodiments of the invention improve service meshes and service brokers such that services, including third-party services, can be consumed without requiring applications to include code to read the configurations required by the third-party services and without requiring applications to handle the associated secrets. As used herein, secrets may refer to various types of credentials and tokens (e.g., username/password, access token). This advantageously allows developers to spend more time on developing the application itself.

Without embodiments of the invention, a common approach to credentials and service consumption is to place the credentials into user-space containers as environment variables. However, this requires the application to be configured to handle the credentials and thus presents a security risk should the user-space container be compromised. Embodiments of the invention reduce the risk of attack by isolating the secrets from containers executing in user space. Thus, even if a user space container is compromised, the vulnerability does not expand to other containers, services, or platforms.

FIG.1Aillustrates an example of a computing environment configured to perform dynamic access control operations. WhileFIG.1Ais discussed with reference to Kubernetes, embodiments are not limited thereto and may be implemented in other environments including containerized environments or environments that implement a service mesh and/or service brokers.

The environment100includes an API102(e.g., Kubernetes API). In one example, the API102may be an API server that functions as a control plane. Users may access a cluster through the API102and allows users, external components, and components of the cluster to communicate with each other.

The environment100, which may be an example of a cluster, includes a service mesh98and a service mesh controller118. The service mesh128allows different parts (e.g., components or services) of an application to share data or communicate. In one example, the service mesh128includes network proxies (e.g., a sidecar) that can be controlled by a service mesh controller118and policies126. The policies126may define how services or applications communicate with each other and external systems. Without the service mesh128, the applications would need to be configured to control communications (e.g., application to service or service to service).

The environment may also include a service catalog104and a service broker106. In one example, the service catalog104is an intermediary between the API102and the service broker106. Using the service catalog104, services offered by or accessible through a service broker106can be browsed. Thus, the service catalog104allows an application to provision and connect to services such as databases, queues, messaging, and the like.

The service mesh128may be combined with the service broker106to secure the connection between an application and services. The service mesh128, for example, may use the mTLS (Mutual Transport Layer Security) to ensure that the application114can only access the services that have provisioned and bound to the application114. Thus, a service such as the service122can only be accessed by subscribed applications. In embodiments of the invention, secrets are not passing between components that could lead to a security issue. Without embodiments of the invention, the service mesh configuration of each container is developer configured. This may lead to misconfigurations and errors and is a potential source of security issues.

In contrast, by integrating the service mesh controller118with the service broker106as in embodiments of the invention, the connection of each container is automatically configured such that each container or application can only access destinations or services configured in the service mesh128by the service broker106.

Embodiments further perform token management in the service mesh traffic. This secures third-party services even in the context of scaling applications, services, or the platform itself. Embodiments of the invention allow authentication and connection mechanisms to be performed outside of user space, which reduces security risks.

The authentication and connection mechanisms disclosed herein in the context of a service broker and a service mesh allow developers to be further de-coupled from cloud service providers. By isolating secrets, containers running in user-space are further separated from the administrator space.

FIG.1Athus discloses aspects of dynamic access control using a service mesh in a containerized platform. The ability to provide dynamic access control includes several components that are included in or added to the platform100.FIG.1illustrates a sidecar124that has been customized according to embodiments of the invention. Thus, the sidecar124is both similar to and distinct from the sidecar116.

In one example, the sidecars116and124may be proxy servers that are configured to redirect traffic based on policies126defined in and maintained by a service mesh controller118. The sidecar116and124, for example, may handle application layer traffic in protocols such as HTTP. The sidecar124, however, is customized and is deployed along with a service122, which is an example of a third-party service.

The sidecar124is further configured to listen for all requests for the service122, translate the original application layer request, and establish a secure connection with the service122. For example, if the service122is a database service (e.g., MongoDB), the sidecar124may receive an SQL query that is secured by TLS. The sidecar124may receive the SQL query and send the same SQL query to the service122secured by secrets. This allows the sidecar124to be involved in the secrets associated with the service122.

The service mesh controller118is also configured in accordance with embodiments of the invention. In this example, the service mesh controller118injects the sidecar116into the pod112where a container (e.g., the application114) is created. Network policies for services across the service mesh are controlled through the sidecar116. The service mesh controller118may also inject the sidecar124into the pod120of the service122, which may be a third-party service.

The service broker106is also customized in embodiments of the invention. The service broker106is a middleman between the service requesters and the service providers (e.g., following Open Service Broker API). The service broker106can send a request to the service provisioner110to provision a dedicated or shared third-party service. The service broker106advantageously has an endpoint for authentication for applications including applications that have bond services. This allows the service broker106to participate in secret handling and secret related operations.

FIG.2discloses aspects of a provisioning workflow that includes dynamic access control. Initially, services are provisioned200in the method200andFIG.1Billustrates the provisioning workflow (labeled with a P) in a computing environment. Initially, a request may be sent to API102to provision a service122. Provisioning a service202may include browsing the service catalog104and issuing a request for a service. The service catalog104may forward the request to a service broker106, which sends the request to a service provisioner110. The service provisioner110automatically spawns a new service instance (service122) in a pod120with a customized sidecar124. The sidecar124may be injected by the service mesh controller118. The sidecar124is available on the service mesh128operating in the platform100. The service provisioner110then stores credentials in the credential store108. These credentials or other secrets are not stored or maintained by the application114.

Once the service122is provisioned, the application114is bound204to the service122. Binding is illustrated with a B in the corresponding path inFIG.1C. Initially, a developer may send a request to bind the provisioned service122to the application114. The bind request is forwarded, by the service catalog104, to the service broker106. The service broker106stores the binding information. The service broker106then connects with the service mesh controller118to add a policy to the policies126that that only the application114is allowed to visit the provisioned service122. Details regarding the communication may also be stored by the service mesh controller118.

Next, the application is deployed206as depicted using arrows labeled D inFIG.1D. A request may be sent to the API102to deploy the application114to the pod112. The sidecar116for the application114is deployed alongside the container application114by the service mesh controller116in the pod1112. However, the service122is not configured in the application114. In other words, the application114is not configured to store or handle the secrets needed to access and use the service122.

FIG.3discloses aspects of a runtime workflow that provides dynamic access control using a service mesh. The operation is further disclosed with reference toFIG.1Eusing an RT label on the path.

In this example, the application114may send302or generate a request for the service122. In this example, the application114does not provide secrets or credentials. The application114may only need to specify the name of the service122(e.g., Mongo DB). This illustrates that the secrets are not stored by the application114and the secretes are not compromised if the application114is compromised.

The sidecar116may catch or intercept this request and forward304the request to the sidecar124, which is customized in accordance with embodiments of the invention. Because the policies126allow the connection between the sidecar114and the sidecar124, the sidecar124receives the request.

The sidecar124then checks306to determine whether an access token is available. If the access token is available (Y at306), the request is forwarded316to the service using the access token (or other credentials). If the access token is not available (N at306), a token request is sent308to the service broker106. The service broker106determines whether the application114is subscribed310to the service122. If the application is not subscribed (N at310), the request is rejected.

If the application114is subscribed to the service122(Y at310), the service broker106retrieves the credentials from the credential store108and authenticates312with the service122to receive an access token. The access token is then returned to or sent314to the sidecar124. And the request originating from the application114is forwarded to the service122by the sidecar124using the access token from the service122.

Thus,FIG.3(andFIGS.1A-1E) illustrate a process of using or accessing a service without sending credentials and illustrates how various aspects of the environment100are configured to implement the method ofFIG.3. Thus, the sidecar124, which is customized and deployed along with the service122, can listen for all requests for the target service, translate the original application layer request, and establish a secure connection with the target service. The service mesh controller118is customized and configured to inject a sidecar116into the container with the application114and control network policies for services across the service mesh through the sidecar116and124.

The service broker106is also customized. In addition to being able to request and provision a dedicated or third-party service, the service broker106is configured to provide an endpoint for authentication services for applications that have bond services. Thus, the application114is bound to the service122. Using the service mesh128, the service broker and the sidecar124can perform authentication. Advantageously, the application114does not require code to perform authentication operations, but only needs to identify the service in the request.

FIG.4discloses aspects of dynamic access control for cloud services. InFIG.4, an application114may access a cloud service404,406, or408. For example, the cloud services404,406and408may be the same service type, but provided by different providers. In this example, provisioning and binding processed may be performed to bind an application to a service.

FIG.5discloses aspects of dynamic access control for cloud services and is described with respect toFIG.4. In the method500, a request is sent502for a service (e.g., a service of optical character recognition for an image) without specifying the cloud provider and without specifying credentials for the cloud provider. The application114accesses the service by only providing the service name corresponding to the name of the third-party service in the service broker106.

The request is received504by the sidecar and forwarded to the express gateway402using the service mesh128(seeFIG.1A). In one example, policies126set by the service broker106allow this type of traffic. As a result, the express gateway402receives the request and applies any predefined policies or trained machine learning models to decide which of the cloud services404,406, and408to use. The machine learning model or policy may allow the cloud service404,406, or408to be selected on a basis of performance, cost, or the like. In either case, a cloud service is selected. In this example, the cloud service406is selected for example only.

The express gateway402may check506to determine if an access token is available. If an access token is not available, a token request is sent508to the service broker106. The service broker106determines whether the application114has subscribed510to the requested service. The request for an access token is rejected518if the application114is not subscribed or bound to the service406. If the application114has subscribed to the service406, the service broker106requests credentials from the credential store108and requests512a token from the targeted cloud service (cloud service406in this example).

The service broker106forwards514the token to the express gateway402. If the token is valid, the original request may be translated to a request that can be received by the selected cloud service406and the request516is sent to the service with the access token. If no access token is received, the request from the application is dropped.

In the foregoing examples, when an access token is obtained by the sidecar124or the express gateway402, the access can be stored by the sidecar124or the express gateway402. Requests that may need the stored access token can be identified based on the TLS protocol, which allows the requesting application and requested service to be identified. Once identified, the access token, if already present, may be used at least until it expires. Alternatively, the access token can be provided to the application and included in future requests until it expires or for other reason.

New and/or modified data collected and/or generated in connection with some embodiments, may be stored in a data protection environment that may take the form of a public or private cloud storage environment, an on-premises storage environment, and hybrid storage environments that include public and private elements. Any of these example storage environments, may be partly, or completely, virtualized. The storage environment may comprise, or consist of, a datacenter which is operable to service read, write, delete, backup, restore, and/or cloning, operations initiated by one or more clients or other elements of the operating environment. Where a backup comprises groups of data with different respective characteristics, that data may be allocated, and stored, to different respective targets in the storage environment, where the targets each correspond to a data group having one or more particular characteristics.

Particularly, devices in the operating environment may take the form of software, physical machines, or VMs, containers or any combination of these, though no particular device implementation or configuration is required for any embodiment.

As used herein, the term ‘backup’ is intended to be broad in scope. As such, example backups in connection with which embodiments of the invention may be employed include, but are not limited to, full backups, partial backups, clones, snapshots, and incremental or differential backups.

It is noted with respect to the example method of Figure(s) XX that any of the disclosed processes, operations, methods, and/or any portion of any of these, may be performed in response to, as a result of, and/or, based upon, the performance of any preceding process(es), methods, and/or, operations. Correspondingly, performance of one or more processes, for example, may be a predicate or trigger to subsequent performance of one or more additional processes, operations, and/or methods. Thus, for example, the various processes that may make up a method may be linked together or otherwise associated with each other by way of relations such as the examples just noted. Finally, and while it is not required, the individual processes that make up the various example methods disclosed herein are, in some embodiments, performed in the specific sequence recited in those examples. In other embodiments, the individual processes that make up a disclosed method may be performed in a sequence other than the specific sequence recited.

Embodiment 1. A method, comprising: sending a request, by an application, to a service without sending secrets needed to access the service, receiving the request at a first sidecar associated with the service, determining whether the application has an access token and whether the application is subscribed to the service, retrieving the secrets from a credential store when the application is subscribed to the service, providing the access token to the first sidecar, and forwarding the request, by the first sidecar, to the application with the access token.

Embodiment 2. The method of embodiment 1, further comprising receiving the request at a second sidecar associated with the application.

Embodiment 3. The method of embodiment 1 and/or 2, further comprising forwarding the request, by the second sidecar, to the first sidecar associated with the service according to a policy in a service mesh.

Embodiment 4. The method of embodiment 1, 2 and/or 3, further comprising sending a token request, by the first sidecar, to a service broker.

Embodiment 5. The method of embodiment 1, 2, 3, and/or 4, further comprising authenticating with the service, by the first sidecar, to receive the access token from the service.

Embodiment 6. The method of embodiment 1, 2, 3, 4, and/or 5, further comprising determining, by the first sidecar, whether the application is allowed to communicate with the service based on policies of a service mesh.

Embodiment 7. The method of embodiment 1, 2, 3, 4, 5, and/or 6, further comprising provisioning the service, wherein provisioning the service includes binding the application to the service and obtaining credentials, wherein the credentials are stored in the credential store, which is separate from a user space of the application.

Embodiment 6. A method comprising: provisioning a service in a computing environment that includes a service mesh, storing credentials to access the service in a credential store, binding the service to an application in the service mesh, deploying the application to the computing environment, wherein a first sidecar is associated to the application and a second side car is associated to the service, sending a request to the service using the service mesh without including the credentials, when an access token in not available, obtaining, by a service broker, the access token using the credentials stored in the credential store and providing the access token to the second sidecar, and forwarding the request to the service by the second sidecar along with the access token.

Embodiment 7. The method of embodiment 6, wherein the request for the service is received by the first sidecar and transmitted to the second sidecar in accordance with policies of the service mesh, further comprising sending a token request to the service broker.

Embodiment 8. The method of embodiment 6 and/or 7, further sending the request, from the application, by specifying a name of the service.

Embodiment 9. The method of embodiment 6, 7, and/or 8, wherein the application is isolated from the credential store and is not configured to directly access the service other than generate the request.

Embodiment 10. The method of embodiment 6, 7, 8, and/or 9, wherein the second sidecar is configured differently from the first sidecar and is configured to obtain the access token, wherein the service broker is further configured as an endpoint for authentication.

Embodiment 11. A method for performing any of the operations, methods, or processes, or any portion of any of these, disclosed herein or in embodiments 1-10.

Any one or more of the entities disclosed, or implied, by the Figures and/or elsewhere herein, may take the form of, or include, or be implemented on, or hosted by, a physical computing device. As well, where any of the aforementioned elements comprise or consist of a virtual machine (VM) or container, that VM or container may constitute a virtualization of any combination of the physical components disclosed herein.

In the example, the physical computing device includes a memory which may include one, some, or all, of random-access memory (RAM), non-volatile memory (NVM) such as NVRAM for example, read-only memory (ROM), and persistent memory, one or more hardware processors, non-transitory storage media, UI device, and data storage. One or more of the memory components of the physical computing device may take the form of solid-state device (SSD) storage. As well, one or more applications may be provided that comprise instructions executable by one or more hardware processors to perform any of the operations, or portions thereof, disclosed herein.