Patent Description:
Containerized microservices are becoming the preferred method of deploying complex enterprise applications. Rather than build a single monolithic application, container based microservices split the application into multiple smaller interconnected components.

<CIT> is directed to a method and a system for discrete data containerization for Information Rights Management. The system identifies based on a user request, data to be containerized. Further, the system receives at least one rule based on the data and attributes, which is to be used for containerizing the data. Further, using the rule, the system containerizes the data, wherein the data is containerized at individual data level.

<CIT> is directed to resource requests between software containers that are accepted or rejected based on whether the software containers are part of a same logical software application. A request to start a software container is accepted or rejected based on whether the software container is digitally signed. A request to perform a container operational action for a first software container is accepted or rejected based on whether a security registry includes a rule governing the requested container operational action for the first software container, and if the software container is already running, based also on what entity started the software container.

<CIT> is directed to method and system providing access control encryption for a file system. A resource management module manages access to data on a storage container and hosts a virtual file system including files representing the data on the storage container. An access control and encryption module encrypts each of the files with a respective file encryption key. The access control module generates a plurality of application containers each associated with a respective user and that include respective lists of files that the respective user is authorized to access. The access control and encryption module generates decrypts the files and allows access to files based on the lists of files in the application containers.

The detailed description set forth below is intended as a description of various configurations of the disclosed technology and is not intended to represent the only configurations in which the technology can be practiced. The detailed description includes specific details for the purpose of providing a more thorough understanding of the subject technology. However, it will be clear and apparent that the subject technology is not limited to the specific details set forth herein and may be practiced without these details. In some instances, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

Additional features and advantages of the disclosure will be set forth in the description which follows, and in part will be obvious from the description, or can be learned by practice of the disclosed principles.

Disclosed are systems, methods, and computer-readable storage media for enabling scalable and secure data retrieval between microservices, for example, such as between containers in a shared namespace in a cloud networking environment. In some aspects, a key management device (e.g., a server or microservice) can be configured to perform operations for 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 label and the second microservice is associated with a second attribute label, and generating a first key based on the first attribute label and a second key based on the second attribute label. In some aspects, the key management server can be further configured to perform and/or facilitate operations for associating a first data store with the first microservice, wherein the first data store is encrypted using the first key, associating a second data store with the second microservice, wherein the second data store is encrypted using the second key, and receiving an application request from a client, wherein the application request requires data retrieval from the first data store and the second data store.

Some conventional microservice encryption schemes make use of public key encryption, which requires generation of unique key pairs for each communicating entity, as well as an out-of-band key distribution means. As such, conventional encryption solutions are not scalable as the number of microservices, and resulting communication mesh between services grows exponentially.

Aspects of the disclosed technology address the foregoing limitations of conventional encryption methods by providing an encryption scheme that permits intra-container access to encrypted data stores using attribute-based keys. In some aspects, a key management device, such as a key management server or microservice, can be used to manage associations between entity attributes, e.g. client or microservice attributes, and encryption keys that unlock corresponding data stores. By using microservice attributes to mediate key generation and encrypted data access, the disclosed technology provides a scalable and highly-granular data protection scheme in which the retrieval of sensitive data can be de-coupled from the security credentials of the requesting entity, for example, by permitting the authorization of secure data request between microservices.

Additional details describing example systems and processes for implementing a microservice attribute-based encryption scheme are provided below. The disclosure now turns to an overview of a network environment in which some aspects of the technology may be implemented, as illustrated in <FIG>. Specifically, <FIG> illustrates an example network environment <NUM> that contains a network fabric suited for supporting various microservices (e.g., containers) that can be configured to utilize an attribute-based encryption process of the disclosed technology.

Network <NUM> includes Fabric <NUM> that represents a physical layer or infrastructure (underlay) of network <NUM>. Fabric <NUM> includes Spines <NUM> (e.g., spine routers or switches) and Leafs <NUM> (e.g., leaf routers or switches) that are interconnected for switching/routing traffic in Fabric <NUM>. Spines <NUM> interconnect Leafs <NUM> in Fabric <NUM>, and Leafs <NUM> connect Fabric <NUM> to the overlay portion of network <NUM>, which includes application services (APPs <NUM>), servers <NUM>, virtual machines (VMs) <NUM>, containers <NUM>, endpoints, endpoint groups (EPGs) <NUM>, etc. Thus, network connectivity in Fabric <NUM> can flow from Spines <NUM> to Leafs <NUM>, and vice versa. Leafs <NUM> 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.

Leafs <NUM> can be responsible for routing and/or switching tenant or customer packets and applying network policies. Network policies, such as authentication policies, can be driven by the one or more controllers <NUM> and/or the Leafs <NUM>. Leafs <NUM> can connect Servers <NUM>, Hypervisors <NUM>, Virtual Machines (VMs) <NUM>, Containers <NUM>, Applications <NUM>, Endpoints <NUM>, External Routers <NUM>, etc., with Fabric <NUM>. For example, Leafs <NUM> can encapsulate and decapsulate packets to and from Servers <NUM> in order to enable communications throughout network <NUM>, including Fabric <NUM>. Leafs <NUM> can also provide any other devices, services, tenants, or workloads with access to Fabric <NUM>.

VMs <NUM> can be virtual machines hosted by Hypervisors <NUM> running on Servers <NUM>. VMs <NUM> can include workloads running on a guest operating system on a respective server. Hypervisors <NUM> can provide a layer of software, firmware, and/or hardware that creates and runs the VMs <NUM>. Hypervisors <NUM> can allow VMs <NUM> to share hardware resources on Servers <NUM>, and the hardware resources on Servers <NUM> to appear as multiple, separate hardware platforms. Moreover, Hypervisors <NUM> on Servers <NUM> can each host one or more VMs <NUM>. Servers <NUM> and/or VMs <NUM> can be configured to host various applications that perform network functionality, such as, by virtualizing various routing, filtering and performing security functions. Network applications can include software applications, services, operators, containers (e.g., containerized microservices) <NUM>, container clusters (e.g., one or more pods) appliances, functions, service chains, etc. For example, Applications <NUM> can include a firewall, a database, a CDN server, an IDS/IPS, a deep packet inspection service, a message router, a virtual switch, etc..

In some cases, VMs <NUM> and/or Hypervisors <NUM> can be migrated to other Servers <NUM>. Servers <NUM> can similarly be migrated to other locations in the network environment <NUM>. For example, a server connected to a specific leaf can be changed to connect to a different or additional leaf. Such configuration or deployment changes can involve modifications to settings and policies that are applied to the resources being migrated.

In some cases, one or more Servers <NUM>, Hypervisors <NUM>, and/or VMs <NUM> can represent a tenant or customer space. Tenant space can include workloads, services, applications, devices, and/or resources that are associated with one or more clients or subscribers. Accordingly, traffic in network environment <NUM> can be routed based on specific tenant policies, spaces, agreements, configurations, etc. Moreover, addressing can vary between one or more tenants. In some configurations, tenant spaces can 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 can be managed by one or more controllers <NUM>.

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 <NUM> can define a policy model at the application level which defines policies and other settings for groups of applications or services, such as endpoint groups. In some addition, the Leafs <NUM>, as well as other physical devices such as physical servers or Spines <NUM>, can apply specific policies to traffic. For example, Leafs <NUM> can apply specific policies or contracts to traffic based on tags or characteristics of the traffic, such as protocols associated with the traffic, applications or endpoint groups associated with the traffic, network address information associated with the traffic, etc..

By way of example, a fabric controller may be implemented using ACI, which can provide an application policy-based solution through scalable distributed enforcement, and support integration of physical and virtual environments under a declarative policy model for networks, servers, services, security, requirements, etc. For example, the ACI framework implements End Point 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 that are connected to network <NUM>.

Endpoints can have one or more attributes such as VM name, guest OS name, a security tag, etc. Application policies can be applied between EPGs, instead of endpoints directly, for example, in the form of contracts. Leafs <NUM> can classify incoming traffic into different EPGs. The classification can be based on, for example, a network segment identifier such as a Virtual LAN (VLAN) ID, a Virtual Extensible LAN (VXLAN) Network Identifier (VNID), Network Virtualization using Generic Routing Encapsulation (NVGRE) Virtual Subnet Identifier (VSID), MAC address, IP address, etc..

Network <NUM> may deploy different hosts via the Leafs <NUM>, Servers <NUM>, Hypervisors <NUM>, VMs <NUM>, and other applications or processes such as containers, controllers, and/or endpoints. By way of example, hosts may be implemented as VMware ESXi hosts, Windows Hyper-V hosts, bare metal physical hosts, etc. Network <NUM> can interoperate with a wide variety of Hypervisors <NUM>, Servers <NUM> (e.g., physical and/or virtual servers), SDN orchestration platforms, etc. Network <NUM> may implement a declarative model to allow its integration with application design and holistic network policy.

Network <NUM> can include one or more different types of SDN solutions, hosts, etc. For the sake of clarity and explanation purposes, the examples in the following disclosure will be described in the context of an ACI solution implemented in the network <NUM>, and the one or more controllers <NUM> may be interchangeably referenced as APIC controllers. However, it should be noted that the technologies and concepts herein are not limited to ACI architectures and may be implemented in other architectures and configurations, including other SDN solutions as well as other types of networks which may not deploy an SDN solution.

Further, as referenced herein, the term "hosts" can refer to servers <NUM> (e.g., physical or logical), Hypervisors <NUM>, VMs <NUM>, containers <NUM> (e.g., Applications <NUM>), EPGs <NUM>, etc., and can run or include any type of server or application solution. Non-limiting examples of "hosts" can include virtual servers, bare metal physical hosts, VMs, Docker Containers, Virtual Routers/Switches (e.g., VPP), etc. Although containers <NUM> are illustrated as being instantiated on servers <NUM> it is understood that one or more of the VMs may be configured to host various containers. Additionally, applications <NUM>, can include or maybe composed of software routines running in one or more of containers <NUM> and/or VMs <NUM>.

Controllers <NUM> can provide centralized access to fabric information, application configuration, resource configuration, application-level policy modeling for a software-defined network (SDN) infrastructure, integration with management systems or servers, etc. Controllers <NUM> can form a control plane that interfaces with an application plane via northbound APIs and a data plane via southbound APIs. In some examples, controllers <NUM> can include SDN controllers or managers, such as an application policy infrastructure controller (APIC).

As previously noted, controllers <NUM> can define and manage application-level model(s) for policies in the network <NUM>. Application or device policies can also be managed and/or defined by other components in the network. For example, a hypervisor or virtual appliance, such as a container, container cluster, and/or VM can run a server or management tool to manage software and services in network <NUM>, including policies and settings for virtual appliances.

In some aspects, various microservices instantiated in fabric <NUM> can be configured to store and retrieve encrypted information payloads using an attribute-based encryption process of the disclosed technology. For example, microservices can include one or more containers <NUM> that are each associated with unique attributes, which can be identified by attribute labels. In some instances, an out-of-band device, such as one of controllers <NUM>, can be used to manage associations between microservice and attribute labels.

In practice, access to encrypted data stores associated with a particular microservice (container) can be restricted based on encryption keys resulting from a combination of one or more attributes, as defined by corresponding labels. For example, an encryption key for a first microservice, can be based on attribute labels corresponding with a service type (e.g., router) and position in a service chain (e.g., fifth service, in a SFC), for the first microservice. As such, access rights granted to the first microservice, e.g., by one or more other microservices, can be controlled by managing data that can be unlocked with the requisite key.

Additional examples of a microservice attribute-based encryption process are detailed with respect to <FIG>, and <FIG>, discussed below.

In particular, <FIG> illustrates an example of a basic architecture <NUM> in which various microservices are associated with encrypted data stores made available to clients via a gateway. Specifically, architecture <NUM> includes multiple containers <NUM> (e.g., containers 202A-202C), that are each associated with a respective microservice <NUM>, and encrypted data store <NUM>. 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, microservices <NUM> and their associated encrypted data stores <NUM> are exposed to clients <NUM> (e.g., Client <NUM>205A, Client <NUM>, 205B, Client n-<NUM>205C, and Client n 205D) via (API) gateway <NUM>. It is understood that the configuration of <FIG> is for illustrative purposes, and that other configurations may be implemented, without departure from the disclosed technology. For example, a greater (or fewer) number of microservices may be implemented. Additionally, containers <NUM> may be configured to instantiate more than one microservice, that may be associated with more than one encrypted data store, without departing from the scope of the technology.

Attributes associated with the various client devices <NUM> and microservices <NUM> can be used to generate keys for accessing encrypted data stores <NUM>. Attribute and attribute label management can be provided by an out of band system, such as a network controller (not illustrated), which maintains associations between various network devices and their attributes, which are identified by corresponding attribute labels. Device attributes can include any type of information that describes a characteristic or quality of a particular device, including a client, container, or microservice, etc. By way of example, client attributes may include without limitation: user access rights, tenant information, network domain information, device type, etc. By way of further example, microservice attributes may include without limitation: service function type, container location, position within a service chain (SFC), microservice priority, data owner (ID), namespace, assigned roll, area of responsibility, department, and/or celarence level, etc..

In practice, both client devices <NUM> and microservices <NUM> can access encrypted data stores <NUM> using attribute-based credentials. That is, client devices <NUM> can access encrypted data stores <NUM> given that keys generated from their corresponding attribute labels provide proper authentication credentials for the requested data. Similarly, microservices <NUM> can access encrypted data stores <NUM> associated with other microservices, given that keys generated from their associated labels are sufficient to provide proper authentication credentials for the requested data.

Attributed based encryption schemes provide highly granular and scalable secure data access for both clients and microservices, without the need for a key exchange, as would be necessary in a public-key encryption system. Additionally, attribute-based microservice encryption enables applications to function securely by providing the ability for encrypted data to be exchanged by certain microservices to facilitate application execution, without exposing secure data to clients and/or microservices that lack the requisite authentication credentials (attributes).

By way of example, Client <NUM>205A may execute an application that invokes microservices 204A, 204B, and 204C; however, Client <NUM> may not have authentication credentials for direct access to encrypted data store 206C. However, encrypted data 206C can be available to microservice 204B, based on attribute labels associated with microservice 204B. In this example, Client <NUM>205A can successfully execute the application, which requires encrypted data 206C be provided to microservice 204B, without directly receiving data from encrypted data store 206C.

<FIG> illustrates an example architecture <NUM> of a logical relationship between microservices, according to some aspects of the technology. As illustrated, various microservices (e.g., Microservice <NUM>, Microservice <NUM>, and Microservice <NUM>) are each contained within containers <NUM>, e.g., Container 203A, Container 203B, and Container 203C, respectively.

In some aspects, various microservices can be communicatively connected independent of their ability to retrieve data from one another. For example, Microservice <NUM> may be associated with attributed labels that permit retrieval of encrypted data from Microservice <NUM>, but not Microservice <NUM>. Additionally, Microservice <NUM> may be authorized to retrieve encrypted data from Microservice <NUM>, but not vice versa.

Authentication for access to various encrypted data stores can change as attribute labels for a given device (e.g., client, container, microservice, etc.) are updated by the key management server (not illustrated). In some implementations, network policy updates may affect attribute labeling, such that attribute-based authentication between devices in a shared namespace can be controlled via network policy. In some implementations, a container interface (I/F) can be used by an out-of-band key management server to identify/detect attributes for a given device (container/microservice), and/or to update keys associated with the microservice so that access rights may be updated/managed with respect to other devices.

<FIG> illustrates steps of an example process <NUM> for implementing a distributed, attribute-based microservices authentication process of the disclosed technology. Process <NUM> begins with step <NUM> 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 technology. By way of example, first and second microservices may be implemented in the same (or different containers), such as those described above with respect to any of <FIG>, <FIG> and/or 2B. Once the microservices are instantiated, both are then associated with respective labels based on their corresponding attributes. As discussed above, attribute detection, labeling, and encryption key management can be performed by an out of band device, such as a key management server, for example, that is implemented by a network controller. In other aspects, attribute labels may be assigned using a network policy, or may be manually configured, for example, by a system or network administrator.

Once attribute labels are identified/generated based on microservice attributes, encryption keys are then generated based on the attribute labels (<NUM>). That is, a first key is generated based on the first attribute label (i.e., one or more attribute labels associated with the first microservice), and a second key is generated based on the second attribute label (i.e., one or more attribute labels associated with the second microservice). Encryption keys produced from the associated attribute labels for each device/microservice can be managed by a key management server. In some instances, keys are distributed to prospective devices (microservices), so that authentication can be performed on a microservice-by-microservice basis.

Secure data stores are then associated with each microservice (<NUM>). That is, a first data store is associated with the first microservice and a second data store is associated with the second microservice. Each data store can be encrypted using keys generated from attribute labels of its corresponding microservice. That is, the first data store is encrypted using the key generated from attributes associated with the first microservice (i.e., the first microservice attribute labels), and the second data store is encrypted using keys generated based on attributes associated with the second microservice (i.e., the second microservice attribute labels).

As discussed above, attributes and corresponding labels can be associated with any type of network device. That is, attribute labels can be client specific, container specific, and/or microservice specific, etc. In instances where clients (client devices) issue requests for data contained in encrypted stores, a similar attribute-based encryption process is performed. By way of example, one or more client attributes are identified and used to generate a third key based on the client attributes (i.e., associated attribute labels). In some aspects the third key can permit client access to encrypted data, e.g., of the first data store, while also preventing direct access to encrypted data in the second data store (<NUM>).

Further to the above examples, the various microservices can also be configured to retrieve or access encrypted data associated with other (different) microservices, e.g., on the basis of their associated attribute labels. For example, the first microservice can be configured to retrieve data from the second microservice, if the second encrypted data store is secured using a key based on attribute labels of the first microservice. In such approaches, a client may execute an application that requires communication and secure data retrieval between microservices, without having direct access to encrypted data that is needed in the application execution.

<FIG> illustrates an example network device <NUM> suitable for implementing a microservices attribute-based encryption process of the subject technology. Device <NUM> includes central processing unit (CPU) <NUM>, network interfaces <NUM>, and a bus <NUM> (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU <NUM> is responsible for executing packet management, error detection, and/or routing functions. CPU <NUM> accomplishes all these functions under the control of software including an operating system and any appropriate applications software. CPU <NUM> may include one or more processors <NUM>, such as a processor from the INTEL X86 family of microprocessors. In some cases, processor <NUM> can be specially designed hardware for controlling the operations of network device <NUM>. In some cases a computer-readable memory, e.g., memory <NUM> (a non-volatile Random Access Memory (RAM), or a Read Only Memory (ROM), etc., also forms part of CPU <NUM>. However, there are many different ways in which memory could be coupled to the system.

Interfaces <NUM> can be provided as modular interface cards (sometimes referred to as "line cards"). They can control the sending and receiving of data packets over the network and sometimes support other peripherals used with network device <NUM>. Among the interfaces that may be provided are Ethernet interfaces, frame relay interfaces, cable interfaces, Digital Subscriber Line (DSL) interfaces, token ring interfaces, and the like.

In addition, various very high-speed interfaces may be provided such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, High Speed Serial Interfaces (HSSIs), POS interfaces, FDDI interfaces, WIFI interfaces, <NUM>/<NUM>/<NUM> cellular interfaces, CAN BUS, LoRA, and the like. Generally, these interfaces may include ports appropriate for communication with the appropriate media. In some cases, they may also include an independent processor and, in some instances, volatile RAM. The independent processors may control such communications intensive tasks as packet switching, media control, signal processing, crypto processing, and management. By providing separate processors for the communications intensive tasks, these interfaces allow the master microprocessor <NUM> to efficiently perform routing computations, network diagnostics, security functions, etc..

Although the system shown in <FIG> is one specific network device of the disclosed embodiments, it is by no means the only network device architecture on which aspects of the disclosed technology can be implemented. For example, an architecture having a single processor that handles communications as well as routing computations, etc., is often used. Further, other types of interfaces and media could also be used with the network device <NUM>.

Regardless of the network device's configuration, it may employ one or more non-transitory computer readable media, e.g., memories or memory modules, such as, memory <NUM>, and/or secondary storage <NUM>, that are configured to store program instructions for the general-purpose network operations and mechanisms for roaming, route optimization and routing functions described herein. Additionally, secondary storage <NUM> may be used as a distributed data store.

In some implementations, the program instructions may be configured to cause CPU <NUM> and/or processor/s <NUM> to perform operations for implementing an attribute based microservices encryption scheme of the disclosed technology. For example, CPU <NUM> and/or processor/s <NUM> can be configured to implement operations for 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 label and the second microservice is associated with a second attribute label, generating a first key based on the first attribute label and a second key based on the second attribute label, associating a first data store with the first microservice, wherein the first data store is encrypted using the first key, and associating a second data store with the second microservice, wherein the second data store is encrypted using the second key. In some aspects, the CPU/processors can be further configured to implement operations for receiving an application request from a client, wherein the application request requires data retrieval from the first data store and the second data store, 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 access by the client to at least a portion of the first data store, wherein the third key does not permit the client to access the second data store.

In some aspects, the processors can be further configured to perform operations including generating a derivative application request by the first microservice in response to the application request, wherein the derivative application request comprises a fourth key based on the first attribute label associated with the first microservice, and accessing, by the first microservice, the second data store associated with the second microservice using the fourth key.

In other aspects, the processors can be further configured to perform operations including providing an application response to the client, wherein the application response comprises data from the first data store that is accessed by the client using the third key, and data from the second data store that is accessed by the first microservice using the fourth key.

In some aspects, as discussed above, attribute labels can serve to identify a function type associated with a microservice, such as, the first microservice discussed above. In other approaches, an attribute label (e.g., the second attribute label) identifies a position of the second microservice in a service chain that comprises the first microservice and one or more other microservices.

Network device <NUM> can also include an application-specific integrated circuit (ASIC), which can be configured to perform routing and/or switching operations. The ASIC can communicate with other components in the network device <NUM> via the bus <NUM>, to exchange data and signals and coordinate various types of operations by the network device <NUM>, such as routing, switching, and/or data storage operations, for example.

Methods according to the above-described examples can be implemented using computer-executable instructions that are stored or otherwise available from non-transitory forms of computer-readable media.

Claim 1:
A system (<NUM>) for authenticating distributed microservices, the system
comprising: one or more processors;
a network interface coupled to the one or more processors; and
a computer-readable memory coupled to the one or more processors, the memory comprising instructions configured to cause the one or more processors to perform operations comprising:
instantiating (<NUM>) 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 label and the second microservice is associated with a second attribute label;
generating (<NUM>) a first key based on the first attribute label and a second key based on the second attribute label;
associating (<NUM>) a first data store with the first microservice, wherein the first data store is encrypted using the first key;
associating (<NUM>) a second data store with the second microservice, wherein the second data store is encrypted using the second key; and
receiving an application request from a client, wherein the application request requires data retrieval from the first data store and the second data store.