Attribute-based encryption for microservices

Abstract

The disclosed technology provides a solution for enabling scalable and secure data retrieval between microservices by encrypting a container-based data storage device using microservice attributes. The process of the technology may include steps for the following operations: instantiating a first microservice and a second microservice in a cloud environment, wherein the first microservice is associated with a first attribute tag and the second microservice is associated with a second attribute tag; generating a first key based on the first attribute tag and generating a second key based on the second attribute tag; associating a first data storage device with the first microservice, wherein the first data storage device is encrypted using the first key; and associating a second data storage device with the second microservice, wherein the second data storage device is encrypted using the second key. Systems and machine-readable media are also provided.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. Non-Provisional Patent Application No. 16 / 105,898, filed on August 20, 2018, entitled “ATTRIBUTE-BASED ENCRYPTION FOR MICROSERVICES,” the contents of which are expressly incorporated herein by reference in their entirety. Background Art 1. Technical Field

[0004] The present disclosure relates generally to the field of computer networks, and more particularly to using attribute-based encryption to protect data requests made to microservices (eg, containers) in a cloud environment.

[0005] 2. Introduction

[0006] Containerized microservices are becoming the preferred method for deploying complex enterprise applications. Instead of building a single monolithic application, container-based microservices split applications into multiple smaller interconnected components. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] In order to describe the manner in which the above and other advantages and features of the present disclosure can be obtained, a more particular description of the principles briefly described above will be presented, which is done by reference to specific embodiments thereof shown in the accompanying drawings. Understanding that these drawings depict only exemplary embodiments of the present disclosure and are not therefore to be considered limiting of its scope, the principles herein are described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0008] Figure 1 An example network environment is shown in which certain aspects of the technology may be implemented.

[0009] Figure 2A An example of a basic architecture is shown in which various microservices are associated with corresponding encrypted data stores.

[0010] Figure 2B An example of logical relationships between microservices in accordance with certain aspects of the technology is shown.

[0011] Figure 3 The steps of an example process for implementing a distributed microservices authentication process of the disclosed technology are shown.

[0012] Figure 4 An example network device is shown in accordance with various embodiments. DETAILED DESCRIPTION

[0013] The detailed description set forth below is intended as a description of various configurations of the disclosed technology, rather than being intended to represent the only configuration in which the technology can be practiced. The accompanying drawings are incorporated herein and constitute a part of the detailed description. For the purpose of providing a more thorough understanding of the subject technology, the detailed description includes specific details. However, it will be clear and apparent that the subject technology is not limited to these specific details set forth herein, and can be practiced without these details. In some cases, structures and components are shown in block diagram form to avoid blurring the concepts of the subject technology.

[0014] Additional features and advantages of the present disclosure will be set forth in the following description, and in part will be apparent from the description, or may be understood by practicing the principles disclosed. The features and advantages of the present disclosure may be realized and obtained by means of the tools and combinations specifically pointed out in the appended claims. These and other features of the present disclosure will become more fully apparent from the following description and the appended claims, or may be understood by practicing the principles set forth herein.

[0015] Overview

[0016] Systems, methods, and computer-readable storage media are disclosed for enabling scalable and secure data retrieval between microservices, such as, for example, between containers in a shared namespace in a cloud networking environment. In some aspects, a key management device (e.g., a server or microservice) may be configured to perform operations for performing the following steps: instantiating a first microservice and a second microservice in a shared namespace of a cloud environment, wherein the first microservice is associated with a first attribute tag and the second microservice is associated with a second attribute tag; and generating a first key based on the first attribute tag and generating a second key based on the second attribute tag. In some aspects, the key management server may also be configured to perform and / or facilitate operations for performing the following steps: associating a first data storage device with the first microservice, wherein the first data storage device is encrypted using a first key; associating a second data storage device with the second microservice, wherein the second data storage device is encrypted using a second key; and receiving an application request from a client, wherein the application request requires data retrieval from the first data storage device and the second data storage device.

[0017] describe

[0018] Some conventional microservice encryption schemes use public key encryption, which requires the generation of a unique key pair for each communicating entity and requires an out-of-band key distribution device. Therefore, conventional encryption solutions cannot scale with the number of microservices, resulting in an exponential growth in the communication network between services.

[0019] Various aspects of the disclosed technology address the aforementioned limitations of conventional encryption methods by providing an encryption scheme that permits in-container access to encrypted data storage devices using attribute-based keys. In some aspects, a key management device such as a key management server or microservice can be used to manage the association between entity attributes (e.g., client or microservice attributes) and encryption keys that unlock corresponding data storage devices. By coordinating key generation and encrypted data access using microservice attributes, the disclosed technology provides a scalable and highly granular data protection scheme in which retrieval of sensitive data can be decoupled from the security credentials of the requesting entity, such as by permitting authorization of secure data requests between microservices.

[0020] Additional details are provided below, which describe example systems and processes for implementing an encryption scheme based on microservice attributes. The present disclosure now turns to an overview of a network environment in which certain aspects of the technology can be implemented, such as Figure 1 shown. Specifically, Figure 1 An example network environment 100 is shown that includes a network fabric suitable for supporting various microservices (eg, containers) that may be configured to utilize the attribute-based encryption process of the disclosed techniques.

[0021] The network 100 includes a fabric 112 representing the physical layer or infrastructure (underlying layer) of the network 100. The fabric 112 includes spines 102 (e.g., spine routers or switches) and leaves 104 (e.g., leaf routers or switches) that are interconnected for switching / routing traffic in the fabric 112. The spines 102 interconnect the leaves 104 in the fabric 112, and the leaves 104 connect the fabric 112 to the overlay portion of the network 100, which includes application services (APPs 117), servers 106, virtual machines (VMs) 110, containers 115, endpoints, endpoint groups (EPGs) 118, etc. Thus, network connectivity in the fabric 112 can flow from the spine 102 to the leaves 104 and vice versa. The leaves 104 can be, for example, top-of-rack (ToR) switches, aggregation switches, gateways, ingress and / or egress switches, provider edge devices, and / or any other type of routing or switching device(s).

[0022] The leaves 104 may be responsible for routing and / or switching tenant or customer packets and applying network policies. Network policies, such as authentication policies, may be driven by one or more controllers 116 and / or the leaves 104. The leaves 104 may connect servers 106, hypervisors 108, virtual machines (VMs) 110, containers 115, applications 117, endpoints 118, external routers 114, etc., to the fabric 112. For example, the leaves 104 may encapsulate and decapsulate packets to and from the servers 106 to enable communication throughout the network 100 (including the fabric 112). The leaves 104 may also provide access to the fabric 112 to any other device, service, tenant, or workload.

[0023] VM 110 may be a virtual machine hosted by a hypervisor 108 running on a server 106. VM 110 may include a workload running on a guest operating system on a corresponding server. Hypervisor 108 may provide a software layer, a firmware layer, and / or a hardware layer that creates and runs VM 110. Hypervisor 108 may allow VM 110 to share hardware resources on server 106 and allow hardware resources on server 106 to appear as multiple separate hardware platforms. In addition, hypervisors 108 on servers 106 may each host one or more VM 110. Servers 106 and / or VM 110 may be configured to host various applications that perform network functions, for example, by virtualizing various routing, filtering, and performing security functions. Network applications may include software applications, services, operators, containers (e.g., containerized microservices) 115, container clusters (e.g., one or more small clusters (pods)) devices, functions, service chains, etc. For example, application 117 may include a firewall, a database, a CDN server, an IDS / IPS, a deep packet inspection service, a message router, a virtual switch, etc.

[0024] In some cases, VMs 110 and / or hypervisors 108 may be migrated to other servers 106. Servers 106 may similarly be migrated to other locations in network environment 100. For example, a server connected to a particular leaf may be changed to connect to a different or additional leaf. Such configuration or deployment changes may involve modifications to settings and policies that apply to the resources being migrated.

[0025] In some cases, one or more servers 106, hypervisors 108, and / or VMs 110 may represent tenant or customer spaces. A tenant space may include workloads, services, applications, devices, and / or resources associated with one or more clients or subscribers. Thus, traffic in the network environment 100 may be routed based on specific tenant policies, spaces, agreements, configurations, and the like. Additionally, addressing may vary between one or more tenants. In some configurations, a tenant space may be divided into logical segments and / or networks and separated from logical segments and / or networks associated with other tenants. Addressing, policy, and configuration information between tenants may be managed by one or more controllers 116.

[0026] Policies, configurations, settings, etc. in the network can be implemented at the application level, the physical level, and / or both. For example, one or more controllers 116 can define a policy model at the application level that defines policies and other settings for applications or service groups (e.g., endpoint groups). In addition, leaves 104 and other physical devices such as physical servers or spines 102 can apply specific policies to traffic. For example, a leaf 104 can apply a specific policy or contract to traffic based on the markings or characteristics of the traffic (e.g., a protocol associated with the traffic, an application or endpoint group associated with the traffic, network address information associated with the traffic, etc.).

[0027] As an example, ACI can be used to implement a fabric controller, where ACI can provide application policy-based solutions through scalable distributed implementations and support the integration of physical and virtual environments under a declarative policy model for networks, servers, services, security, requirements, etc. For example, the ACI framework implements endpoint groups (EPGs), which can include a collection of endpoints or applications that share common policy requirements (such as security, QoS, services, etc.). Endpoints can be virtual / logical or physical devices, such as VMs and bare-metal physical servers connected to the network 100.

[0028] An endpoint may have one or more attributes, such as a VM name, a guest OS name, a security tag, etc. Application policies may be applied between EPGs, for example, in the form of contracts, rather than being applied directly to endpoints. Leaf 104 may classify incoming traffic to different EPGs. Classification may be based on, for example, a network segment identifier, such as a virtual LAN (VLAN) ID, a virtual extensible LAN (VXLAN) network identifier (VNID), a network virtualization using generic routing encapsulation (NVGRE) virtual subnetwork identifier (VSID), a MAC address, an IP address, etc.

[0029] The network 100 can be deployed to different hosts via leaves 104, servers 106, hypervisors 108, VMs 110, and other applications or processes such as containers, controllers, and / or endpoints. As an example, the host can be implemented as a VMware ESXi host, a Windows Hyper-V host, a bare metal physical host, etc. The network 100 can interoperate with a variety of hypervisors 108, servers 106 (e.g., physical and / or virtual servers), SDN orchestration platforms, etc. The network 100 can implement a declarative model to allow its integration with application design and overall network strategy.

[0030] The network 100 may include one or more different types of SDN solutions, hosts, etc. For purposes of clarity and explanation, the examples in the following disclosure will be described in the context of an ACI solution implemented in the network 100, and the one or more controllers 116 may be interchangeably referred to as APIC controllers. It should be noted, however, that the techniques and concepts herein are not limited to the ACI architecture and may be implemented in other architectures and configurations, including other SDN solutions as well as other types of networks where an SDN solution may not be deployed.

[0031] In addition, as referred to herein, the term "host" may refer to a server 106 (e.g., physical or logical), a hypervisor 108, a VM 110, a container 115 (e.g., an application 117), an EPG 118, etc., and may run or include any type of server or application solution. Non-limiting examples of a "host" may include a virtual server, a bare metal physical host, a VM, a Docker container, a virtual router / switch (e.g., a VPP), etc. Although the container 115 is shown as being instantiated on the server 106, it is understood that one or more of the VMs may be configured to host various containers. In addition, the application 117 may include, or may consist of, software routines running in one or more containers 115 and / or VMs 110.

[0032] The controller 116 may provide centralized access to fabric information, application configuration, resource configuration, application-level policy modeling for a software-defined network (SDN) infrastructure, integration with a management system or server, etc. The controller 116 may form a control plane that interfaces with an application plane via a northbound API and interfaces with a data plane via a southbound API. In some examples, the controller 116 may include an SDN controller or manager, such as an application policy infrastructure controller (APIC).

[0033] As previously described, the controller 116 may define and manage application-level model(s) for policies in the network 100. Application or device policies may also be managed and / or defined by other components in the network. For example, a hypervisor or virtual device such as a container, container cluster, and / or VM may run a server or management tool to manage software and services in the network 100, including policies and settings for the virtual device.

[0034] In some aspects, various microservices instantiated in fabric 112 can be configured to store and retrieve encrypted information payloads using the attribute-based encryption process of the disclosed technology. For example, a microservice can include one or more containers 115, where each container is associated with a unique attribute that can be identified by an attribute tag. In some cases, an out-of-band device such as one of controllers 116 can be used to manage the association between the microservice and the attribute tag.

[0035] In practice, access to an encrypted data storage device associated with a particular microservice (container) can be restricted based on an encryption key generated from a combination of one or more attributes defined by corresponding tags. For example, an encryption key for a first microservice can be based on attribute tags that correspond to the service type (e.g., router) and position in the service chain (e.g., fifth service in an SFC) for the first microservice. In this way, the access rights granted (e.g., by one or more other microservices) to the first microservice can be controlled by managing data that can be unlocked with the necessary keys.

[0036] The following will be about Figure 2A , Figure 2B ,and Figure 3 Additional examples detailing the encryption process based on microservice attributes.

[0037] In particular, Figure 2AAn example of a basic architecture 200 is shown in which various microservices are associated with encrypted data stores that are available to clients via a gateway. Specifically, the architecture 200 includes multiple containers 202 (e.g., containers 202A-202C), each of which is associated with a corresponding microservice 204 and an encrypted data store 206. That is, container 202A includes microservice 204A and encrypted data 206A; container 202B includes microservice 204B and encrypted data 206B; and container 202C includes microservice 204C and encrypted data 206C. As depicted, the microservices 204 and their associated encrypted data stores 206 are exposed to clients 205 (e.g., client 1 205A, client 2 205B, client n-1 205C, and client n 205D) via an (API) gateway 203. It should be understood that Figure 2A The configuration is for illustrative purposes, and other configurations may be implemented without departing from the disclosed technology. For example, a greater (or lesser) number of microservices may be implemented. In addition, without departing from the scope of the present technology, the container 202 may be configured to instantiate more than one microservice, which may be associated with more than one encrypted data storage device.

[0038] Attributes associated with various client devices 205 and microservices 204 may be used to generate keys for accessing encrypted data storage devices 206. Attribute and attribute tag management may be provided by an out-of-band system such as a network controller (not shown) that maintains associations between various network devices and their attributes, where the attributes are identified by corresponding attribute tags. Device attributes may include any type of information describing the characteristics or qualities of a particular device, including a client, container, or microservice, etc. As an example, client attributes may include, but are not limited to: user access rights, tenant information, network domain information, device type, etc. As a further example, microservice attributes may include, but are not limited to: service function type, container location, location in a service chain (SFC), microservice priority, data owner (ID), namespace, assigned list (roll), responsibility area, department, and / or celarence level, etc.

[0039] In practice, both client device 205 and microservice 204 can use attribute-based credentials to access encrypted data storage device 206. That is, client device 205 can access encrypted data storage device 206, assuming that the key generated from its corresponding attribute tag provides appropriate authentication credentials for the requested data. Similarly, microservice 204 can access encrypted data storage devices 206 associated with other microservices, assuming that the key generated from its associated tag is sufficient to provide appropriate authentication credentials for the requested data.

[0040] Attribute-based encryption schemes provide highly granular and scalable secure data access to both clients and microservices without requiring key exchange, which may be necessary in public key cryptographic systems. Furthermore, attribute-based microservice encryption enables applications to operate securely by providing the ability to facilitate application execution for encrypted data to be exchanged by certain microservices without exposing secure data to clients and / or microservices that lack the necessary authentication credentials (attributes).

[0041] As an example, client 1 205A may execute an application that calls microservices 204A, 204B, and 204C; however, client 1 may not have authentication credentials for directly accessing encrypted data storage device 206C. However, based on the attribute tags associated with microservice 204B, encrypted data 206C may be available to microservice 204B. In this example, client 1 205A may successfully execute the application, which requires encrypted data 206C to be provided to microservice 204B without receiving data directly from encrypted data storage device 206C.

[0042] Figure 2B An example architecture 201 showing logical relationships between microservices according to certain aspects of the technology is shown. As shown, various microservices (e.g., microservice 1, microservice 2, and microservice 3) are each contained in a container 203, for example, respectively contained in container 203A, container 203B, and container 203C.

[0043] In some aspects, various microservices can be communicatively connected independent of their ability to retrieve data from each other. For example, microservice 1 can be associated with an attribute tag that permits retrieval of encrypted data from microservice 2 but not microservice 3. Additionally, microservice 2 can be authorized to retrieve encrypted data from microservice 1, but not vice versa.

[0044] Authentication for access to various encrypted data storage devices can change as attribute tags for a given device (e.g., client, container, microservice, etc.) are updated by a key management server (not shown). In some implementations, network policy updates can affect attribute annotations so that attribute-based authentication between devices in a shared namespace can be controlled via network policy. In some implementations, an out-of-band key management server can use a container interface (I / F) to identify / detect attributes for a given device (container / microservice) and / or update keys associated with the microservice so that access permissions can be updated / managed for other devices.

[0045] Figure 3The steps of an example process 300 are shown for implementing a distributed, attribute-based microservice authentication process of the disclosed technology. The process 300 begins with step 302, in which first and second microservices are instantiated in a cloud environment. In some aspects, the first and second microservices are instantiated in the same namespace; however, the first and second microservices can exist in different namespace locations in the cloud environment without departing from the present technology. As an example, the first and second microservices can be implemented in the same (or different) containers, such as described above with respect to Figure 1 , Figure 2A and / or Figure 2B Once the microservices are instantiated, the two microservices are associated with corresponding tags based on their corresponding attributes. As described above, attribute detection, labeling, and encryption key management can be performed by an out-of-band device (such as a key management server, which is implemented, for example, by a network controller). In other aspects, attribute tags can be assigned using network policies, or can be manually configured, for example, by a system or network administrator.

[0046] Once the attribute tags are identified / generated based on the microservice attributes, encryption keys are then generated based on the attribute tags (304). That is, a first key is generated based on a first attribute tag (i.e., one or more attribute tags associated with the first microservice), and a second key is generated based on a second attribute tag (i.e., one or more attribute tags associated with the second microservice). The encryption keys generated from the associated attribute tags for each device / microservice can be managed by a key management server. In some cases, the keys are distributed to the intended devices (microservices) so that authentication can be performed on a microservice-by-microservice basis.

[0047] A secure data storage device is then associated with each microservice (306). That is, a first data storage device is associated with the first microservice, and a second data storage device is associated with the second microservice. Each data storage device may be encrypted using a key generated from the attribute tag of its corresponding microservice. That is, the first data storage device is encrypted using a key generated from the attribute associated with the first microservice (i.e., the first microservice attribute tag), and the second data storage device is encrypted using a key generated based on the attribute associated with the second microservice (i.e., the second microservice attribute tag).

[0048] As described above, attributes and corresponding tags can be associated with any type of network device. That is, attribute tags can be client-specific, container-specific, and / or microservice-specific, etc. In the event that a client (client device) issues a request for data contained in an encrypted storage device, a similar attribute-based encryption process is performed. As an example, one or more client attributes are identified and used to generate a third key based on the client attributes (i.e., the associated attribute tags). In some aspects, the third key can permit the client to access encrypted data of, for example, a first data storage device, while also preventing direct access to encrypted data in a second data storage device (308).

[0049] Further to the above example, various microservices can also be configured to retrieve or access encrypted data associated with other (different) microservices, for example based on their associated attribute tags. For example, a first microservice can be configured to retrieve data from a second microservice when the second encrypted data storage device is protected using a key based on the attribute tags of the first microservice. In such an approach, a client can execute an application that requires communication between microservices and secure data retrieval without having direct access to the encrypted data required in the execution of the application.

[0050] Figure 4 An example network device 410 is shown, which is suitable for implementing the encryption process based on microservice attributes of the subject technology. Device 410 includes a central processing unit (CPU) 462, a network interface 468, and a bus 415 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, CPU 462 is responsible for performing packet management, error detection, and / or routing functions. CPU 462 completes all these functions under the control of software including an operating system and any appropriate application software. CPU 462 may include one or more processors 463, such as processors from the INTEL X86 series of microprocessors. In some cases, processor 463 may be hardware specially designed for controlling the operation of network device 410. In some cases, computer readable memory (e.g., memory 461 (non-volatile random access memory (RAM), or read-only memory (ROM) etc.)) also forms part of CPU 462. However, there are many different ways to couple memory to the system.

[0051] Interfaces 468 may be provided as modular interface cards (sometimes referred to as "line cards"). They may control the sending and receiving of data packets on the network and sometimes support other peripheral devices used with network device 410. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, digital subscriber line (DSL) interfaces, token ring interfaces, etc.

[0052] In addition, various ultra-high-speed interfaces can be provided, such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, high-speed serial interfaces (HSSI), POS interfaces, FDDI interfaces, WIFI interfaces, 3G / 4G / 5G cellular interfaces, CAN buses, LoRA, etc. Typically, these interfaces may include ports suitable for communicating with appropriate media. In some cases, they may also include independent processors and, in some cases, volatile RAM. The independent processors may control communication-intensive tasks such as packet switching, media control, signal processing, cryptographic processing, and management. By providing separate processors for communication-intensive tasks, these interfaces allow the main microprocessor 463 to efficiently perform routing calculations, network diagnostics, security functions, and the like.

[0053] Although in Figure 4 The system shown in is one specific network device of the disclosed embodiment, but it is by no means the only network device architecture on which various aspects of the disclosed technology can be implemented. For example, an architecture with a single processor is often used, which handles communications as well as routing calculations, etc. In addition, other types of interfaces and media can also be used with network device 410.

[0054] Regardless of the configuration of the network device, it can use one or more non-transitory computer-readable media, such as memory or memory modules (such as memory 461 and / or auxiliary storage device 481), which are configured to store the following program instructions: These program instructions are used for general network operations and for the mechanisms of roaming, route optimization and routing functions described herein. For example, program instructions can control the operation of an operating system and / or one or more applications. One or more memories can also be configured to store tables such as mobility binding, registration, and association tables. Memory 461 can also save various software containers and virtualized execution environments and data. In addition, auxiliary storage device 481 can be used as a distributed data storage device.

[0055] In some implementations, the program instructions may be configured to cause the CPU 462 and / or (one or more) processors 463 to perform operations for implementing the attribute-based microservice encryption scheme of the disclosed technology. For example, the CPU 462 and / or (one or more) processors 463 may be configured to implement operations for performing the following steps: instantiating a first microservice and a second microservice in a shared namespace of a cloud environment, wherein the first microservice is associated with a first attribute tag and the second microservice is associated with a second attribute tag; generating a first key based on the first attribute tag and generating a second key based on the second attribute tag; associating a first data storage device with the first microservice, wherein the first data storage device is encrypted using the first key; and associating a second data storage device with the second microservice, wherein the second data storage device is encrypted using the second key. In some aspects, the CPU / processor may also be configured to implement operations for performing the following steps: receiving an application request from a client, wherein the application request requires data retrieval from a first data storage device and a second data storage device; identifying one or more client attributes associated with the client; and generating a third key based on the client attributes, wherein the third key permits the client to access at least a portion of the first data storage device, wherein the third key does not permit the client to access the second data storage device.

[0056] In some aspects, the processor may also be configured to perform operations including: generating, by the first microservice in response to the application request, a derived application request, wherein the derived application request includes a fourth key based on a first attribute tag associated with the first microservice; and accessing, by the first microservice, a second data storage device associated with the second microservice using the fourth key.

[0057] In other aspects, the processor may be further configured to perform operations including providing an application response to the client, wherein the application response includes data from the first data storage device accessed by the client using a third key, and data from the second data storage device accessed by the first microservice using a fourth key.

[0058] In some aspects, as described above, the attribute tag can be used to identify the type of function associated with a microservice (such as the first microservice discussed above). In other methods, the attribute tag (e.g., the second attribute tag) identifies the position of the second microservice in a service chain including the first microservice and one or more other microservices.

[0059] The network device 410 may also include an application specific integrated circuit (ASIC), which may be configured to perform routing and / or switching operations. The ASIC may communicate with other components in the network device 410 via the bus 415 to exchange data and signals, and coordinate various types of operations performed by the network device 410, such as routing, switching, and / or data storage operations.

[0060] For clarity of explanation, in some cases, the technology may be presented as including separate functional blocks, including functional blocks comprising devices, device components, steps or routines in a method embodied in software, or a combination of hardware and software.

[0061] In some embodiments, computer-readable storage devices, media, and memories may include: wired or wireless signals including bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly excludes media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0062] The methods according to the above examples can be implemented using computer executable instructions, which are stored in or otherwise available from a non-transitory form of computer readable media. Such instructions may include, for example, instructions and data that cause or otherwise configure a general purpose computer, a special purpose computer, or a special purpose processing device to perform a specific function or group of functions.

[0063] Portions of the computer resources used may be accessible via a network. Computer executable instructions may be, for example, binary, intermediate format instructions such as assembly language, firmware, or source code. Examples of computer readable media that can be used to store instructions, information used, and / or information created during the methods according to the described examples include: magnetic or optical disks, flash memory, USB devices provided with non-volatile memory, networked storage devices, etc.

[0064] The equipment according to these disclosure implementation methods may include hardware, firmware and / or software, and may adopt any of various form factors. Typical examples of this form factor include: laptop computers, smart phones, small form factor personal computers, personal digital assistants, rack-mounted devices, stand-alone devices, etc. The functions described herein may also be embodied in peripheral devices or add-on cards. As a further example, such functions may also be implemented on circuit boards between different chips or different processes executed in a single device.

[0065] Instructions, media for transmitting such instructions, computing resources for executing them, and other structures for supporting such computing resources are the means for providing the functions described in these disclosures.

[0066] Although various examples and other information are used to explain various aspects within the scope of the appended claims, limitations on the claims should not be implied based on the specific features or arrangements in these examples, because ordinary technicians will be able to use these examples to derive a variety of implementations. In addition, although a subject matter may have been described in language specific to examples of structural features and / or method steps, it should be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or actions. For example, such functions may be distributed differently or performed in components other than those identified herein. Instead, the described features and steps are disclosed as examples of components of systems and methods within the scope of the appended claims.

Claims

1. A system for authenticating distributed microservices, the system comprising: one or more processors; as well as A computer-readable medium comprising instructions stored therein, which, when executed by the one or more processors, cause the one or more processors to: Instantiating, in the cloud environment, a first application service associated with the first attribute tag and a second application service associated with the second attribute tag; generating a first key based on the first attribute tag, and generating a second key based on the second attribute tag; Associating the first data storage device with the first application service by encrypting the first data storage device using the first key, wherein the first application service is configured to access first data stored in the first data storage device through the first key based on the first attribute tag; Associating the second data storage device with the second application service by encrypting the second data storage device using the second key, wherein the second application service is configured to access second data stored in the second data storage device through the second key based on the second attribute tag; receiving, from a client, an application service request invoking execution of the first application service and the second application service, the application service request including access credentials for the first data storage device but lacking access credentials for the second data storage device; and Based on the first attribute tag, the application service request for the first application service from the client is filled by providing the first application service with access to the first data storage device via the first key and access to the second data storage device via the second key, while avoiding providing the client with access to the second data storage device.

2. The system according to claim 1, wherein: When executed by the one or more processors, the instructions also cause the one or more processors to: based on the second attribute tag, fill an application service request for the second application service from the client by providing the second application service with access to the second data via the second key while avoiding providing the client with access to the second data.

3. The system according to claim 1, wherein: The client lacks authentication credentials for directly accessing either or both of the first data and the second data.

4. The system according to claim 1, wherein: The first attribute tag and the second attribute tag are provided by an out-of-band system.

5. The system according to claim 1, wherein: Based on one or more network policies for the cloud environment, the first attribute tag is assigned to the first application service, and the second attribute tag is assigned to the second application service.

6. The system according to claim 1, wherein: The instructions, when executed by the one or more processors, further cause the one or more processors to: identifying one or more client attributes associated with the client; and A third key is generated based on the one or more client attributes, wherein the third key permits access by the client to at least a portion of the first data storage device, and wherein the third key does not permit the client to access the second data storage device.

7. The system according to claim 1, wherein: The instructions, when executed by the one or more processors, further cause the one or more processors to: determining whether the second data storage device is encrypted using a key generated based on an attribute tag associated with the first application service; as well as Based on whether the second data storage device is encrypted using a key generated based on a property tag associated with the first application service, the first application service is provided with access to at least a portion of the second data storage device.

8. The system according to claim 1, wherein: The first attribute tag identifies a function type associated with the first application service.

9. The system according to claim 1, wherein: The second attribute tag identifies a priority of the second application service in a service chain including the second application service.

10. A method for authenticating a distributed microservice, comprising: Instantiating, in the cloud environment, a first application service associated with the first attribute tag and a second application service associated with the second attribute tag; generating a first key based on the first attribute tag, and generating a second key based on the second attribute tag; Associating the first data storage device with the first application service by encrypting the first data storage device using the first key, wherein the first application service is configured to access first data stored in the first data storage device through the first key based on the first attribute tag; Associating the second data storage device with the second application service by encrypting the second data storage device using the second key, wherein the second application service is configured to access second data stored in the second data storage device through the second key based on the second attribute tag; receiving, from a client, an application service request invoking execution of the first application service and the second application service, the application service request including access credentials for the first data storage device but lacking access credentials for the second data storage device; and Based on the first attribute tag, the application service request for the first application service from the client is filled by providing the first application service with access to the first data storage device via the first key and access to the second data storage device via the second key, while avoiding providing the client with access to the second data storage device.

11. The method according to claim 10, further comprising: Based on the second attribute tag, an application service request from the client for the second application service is filled by providing the second application service with access to the second data via the second key while avoiding providing the client with access to the second data.

12. The method according to claim 10, wherein: The client lacks authentication credentials for directly accessing either or both of the first data and the second data.

13. The method according to claim 10, wherein: The first attribute tag and the second attribute tag are provided by an out-of-band system.

14. The method according to claim 10, wherein: Based on one or more network policies for the cloud environment, the first attribute tag is assigned to the first application service, and the second attribute tag is assigned to the second application service.

15. The method according to claim 10, further comprising: identifying one or more client attributes associated with the client; as well as A third key is generated based on the one or more client attributes, wherein the third key permits access by the client to at least a portion of the first data storage device, and wherein the third key does not permit the client to access the second data storage device.

16. The method according to claim 10, further comprising: determining whether the second data storage device is encrypted using a key generated based on an attribute tag associated with the first application service; as well as Based on whether the second data storage device is encrypted using a key generated based on a property tag associated with the first application service, the first application service is provided with access to at least a portion of the second data storage device.

17. The method according to claim 10, wherein: The first attribute tag identifies a function type associated with the first application service.

18. The method according to claim 10, wherein: The second attribute tag identifies a priority of the second application service in a service chain including the second application service.

19. A non-transitory computer-readable storage medium comprising instructions stored therein, which, when executed by one or more processors, cause the one or more processors to: Instantiating, in the cloud environment, a first application service associated with the first attribute tag and a second application service associated with the second attribute tag; generating a first key based on the first attribute tag, and generating a second key based on the second attribute tag; Associating the first data storage device with the first application service by encrypting the first data storage device using the first key, wherein: The first application service is configured to access first data stored in the first data storage device through the first key based on the first attribute tag; Associating the second data storage device with the second application service by encrypting the second data storage device using the second key, wherein the second application service is configured to access second data stored in the second data storage device through the second key based on the second attribute tag; receiving, from a client, an application service request that invokes execution of the first application service and the second application service, the application service request including access credentials for the first data storage device but lacking access credentials for the second data storage device; as well as Based on the first attribute tag, the application service request for the first application service from the client is filled by providing the first application service with access to the first data storage device via the first key and access to the second data storage device via the second key, while avoiding providing the client with access to the second data storage device.

20. The non-transitory computer-readable storage medium of claim 19, wherein: The instructions also cause the one or more processors to, based on the second attribute tag, fill an application service request from the client for the second application service by providing the second application service with access to the second data via the second key while avoiding providing the client with access to the second data.

Images