Patent Publication Number: US-10789179-B1

Title: Decentralized access management in information processing system utilizing persistent memory

Description:
CROSS REFERENCE TO RELATED APPLICATION 
     The present application is a continuation-in-part of, and therefore claims priority to, U.S. patent application Ser. No. 15/727,280, entitled “Data Routing in Information Processing System Utilizing Persistent Memory” filed Oct. 6, 2017, the disclosure of which is incorporated by reference herein in its entirety. 
    
    
     FIELD 
     The field relates generally to information processing systems, and more particularly to techniques for access management in information processing systems that utilize persistent memory. 
     BACKGROUND 
     By way of example, an information processing system may comprise a set of computing devices (e.g., servers) that host one or more application programs (applications) that utilize and generate data that is stored in a data storage system. In information processing systems that implement virtualization to provide a layer of abstraction over the physical server hardware, the applications are typically executed by one or more compute nodes in virtual processing elements or virtual processors such as, for example, containers or virtual machines. The input and output data associated with execution of an application is stored or persisted within the particular data storage system implemented by the information processing system. 
     Furthermore, the set of computing devices of the information processing system may be part of a data center in the form of a cloud-based computing environment which hosts applications for multiple tenants. The cloud-based computing environment may employ existing cloud services such as Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) that enable efficient development and deployment of applications for application developers and owners. 
     As new applications are composed (e.g., microservices) or imposed (e.g., monolithic or legacy applications) via containers and onto a PaaS or IaaS, this creates challenges to the binding of applications to persistent data. Today&#39;s containers are distributed across available infrastructure components, and binding is carried out via centralized non-volatile primary storage. The binding is called out in manifests when the applications are composed. The current method of binding containers to primary storage is based upon existing data access methods (e.g., retrieve from primary storage such as storage arrays and load into memory resident on the host). 
     Thus, applications have typically stored their data between two tiers, i.e., a memory tier and a storage tier. However, persistent storage (referred to as PMEM) has begun to find use in some information processing systems. PMEM is accessed in a similar manner as volatile memory (e.g., dynamic random-access memory or DRAM) using processor load and store instructions; however, PMEM persists data in a non-volatile manner similar to a storage array. 
     While information processing systems utilizing PMEM have been proposed, access by unauthorized containers is realized to be a problem. 
     SUMMARY 
     Embodiments of the invention provide techniques for decentralized access management in information processing systems that utilize persistent memory. 
     For example, in one illustrative embodiment, a method comprises the following steps. In an information processing system comprising a set of computing devices wherein each computing device comprises a set of persistent memory modules resident in the computing device, and wherein one or more data structures associate one or more application programs executing on the set of computing devices with one or more memory regions of the set of persistent memory modules such that the one or more data structures are utilized to route data between a given one of the application programs and at least one memory region, the method comprises maintaining a distributed ledger system with a plurality of nodes, wherein the set of computing devices is operatively coupled to the plurality of nodes of the distributed ledger system. The method further comprises managing one or more data access requests by a given application program to a memory region of a persistent memory module in consultation with the distributed ledger system by storing transaction data in the distributed ledger system that represents at least one of routing information, identity information, and binding information associated with the one or more application programs and the set of persistent memory modules. 
     Advantageously, in illustrative embodiments, the distributed ledger system provides a secure and immutable decentralized mechanism for managing data access in an information processing system that utilizes persistent memory. 
     These and other features and advantages of the invention will become more readily apparent from the accompanying drawings and the following detailed description. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates a server configuration with persistent memory in accordance with which one or more illustrative embodiments may be implemented. 
         FIG. 2  illustrates routing structures used to identify persistent memory locations, according to an illustrative embodiment. 
         FIG. 3  illustrates a process of embedding application and tenant identifiers into a routing structure, according to an illustrative embodiment. 
         FIG. 4  illustrates a process of application region mapping via hash values, according to an illustrative embodiment. 
         FIG. 5  illustrates a process of leveraging hash values to map applications to data centers, according to an illustrative embodiment. 
         FIG. 6  illustrates an example of a malicious container attempting to access data stored in persistent memory in an information processing system within which one or more illustrative embodiments may be implemented. 
         FIG. 7  illustrates a system for decentralized access management in an information processing system that utilizes persistent memory, according to an illustrative embodiment. 
         FIG. 8  illustrates a ledger transaction containing persistent memory routing information, according to an illustrative embodiment. 
         FIG. 9  illustrates a ledger transaction containing identity registration information, according to an illustrative embodiment. 
         FIG. 10  illustrates a ledger transaction containing binding information, according to an illustrative embodiment. 
         FIG. 11  illustrates an example of ledger consultation associated with a persistent memory allocation request, according to an illustrative embodiment. 
         FIG. 12  illustrates a processing platform used to implement an information processing system that utilizes persistent memory as a primary data store with decentralized access management, according to an illustrative embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     Illustrative embodiments will be described herein with reference to exemplary information processing systems and associated host devices, storage devices and other processing devices. It is to be appreciated, however, that embodiments are not restricted to use with the particular illustrative system and device configurations shown. Accordingly, the term “information processing system” as used herein is intended to be broadly construed, so as to encompass, for example, processing systems comprising cloud computing and storage systems, as well as other types of processing systems comprising various combinations of physical and virtual computing resources. An information processing system may therefore comprise, for example, a cloud infrastructure hosting multiple tenants that share cloud computing resources. Such systems are considered examples of what are more generally referred to herein as cloud-based computing environments. Some cloud infrastructures are within the exclusive control and management of a given enterprise, and therefore are considered “private clouds.” The term “enterprise” as used herein is intended to be broadly construed, and may comprise, for example, one or more businesses, one or more corporations or any other one or more entities, groups, or organizations. An “entity” as illustratively used herein may be a person or system. On the other hand, cloud infrastructures that are used by multiple enterprises, and not necessarily controlled or managed by any of the multiple enterprises but rather are respectively controlled and managed by third-party cloud providers, are typically considered “public clouds.” Examples of public clouds may include, but are not limited to, Amazon Web Services® (AWS), Google Compute Engine® (GCE), and Windows Azure® Services platforms. Thus, enterprises can choose to host their applications or services on private clouds, public clouds, and/or a combination of private and public clouds (hybrid clouds) with a vast array of computing resources attached to or otherwise a part of the infrastructure. 
     As mentioned above in the background section, information processing systems utilizing DRAM currently use existing data access methods to bind containers to centralized non-volatile primary storage. However, it is realized that persistent memory (PMEM) may be used to replace DRAM and further, because of its non-volatile persistent nature, PMEM allows for persistent storage inside each server (i.e., decentralized storage) that is byte addressable and thus can also serve as a replacement for primary data storage. However, it is also realized that as PMEM becomes the primary data store, several challenges arise, for example: (i) data access semantics will no longer be block/file/object; (ii) data will be stored in decentralized servers, not centralized storage devices such as storage arrays; (iii) applications will no longer be able to directly access stored bytes via the use of universal resource identifiers or URIs (e.g., file/directory names); (iv) orchestration systems, which are not currently PMEM-aware, will either need to place containers physically proximate to the stored bytes or will at least need to know where the data is physically located during container placement; (v) as data becomes increasingly distributed across multiple PMEM systems, managing a uniform data access methodology and understanding physical mappings across private and public domains is currently not possible; (vi) PMEM-based storage does not currently have the ability to be partitioned among multiple tenants so as to prevent unauthorized access on shared PMEM storage; and (vii) PMEM-based storage presents a data protection challenge in that it currently has no ability to track where redundant copies are located and how those copies are being updated and/or synchronized. 
     The above-referenced U.S. patent application Ser. No. 15/727,280, entitled “Data Routing in Information Processing System Utilizing Persistent Memory,” filed Oct. 6, 2017, the disclosure of which is incorporated by reference herein in its entirety, describes techniques to overcome the above and other drawbacks associated with replacing existing centralized primary storage with PMEM-based storage. More particularly, illustrative embodiments provide techniques for routing data in information processing systems that utilize PMEM as primary data storage. Some embodiments of these routing techniques are described below in the context of  FIGS. 1-5 . 
       FIG. 1  illustrates a server configuration with PMEM serving as primary data storage in accordance with which one or more illustrative embodiments may be implemented. As shown, network-connected server configuration  100  comprises a root bridge  210  operatively coupling a set of servers  120 - 1 ,  120 - 2 ,  120 - 3  and  120 - 4 . Of course, the number of servers may be more or less than the illustrative number shown in  FIG. 1 . Each server includes a set of dual inline memory module (DIMM) slots that each contain a PMEM module. Thus, as shown, servers  120 - 1 ,  120 - 2 ,  120 - 3  and  120 - 4  respectively include a set of DIMM slots  130 - 1 ,  130 - 2 ,  130 - 3  and  130 - 4  with PMEM installed. Again, while each set of DIMM slots is illustrated with four slots (0, 1, 2, and 3), there can be more or less slots in a given server configuration. Note that each server is designated with a host media access control (HMAC) address, i.e., server  120 - 1  as HMAC1, server  120 - 2  as HMAC2, server  120 - 3  as HMAC3, and server  120 - 4  as HMAC4. A HMAC address is typically associated with a server&#39;s network interface controller (NIC) and is used to uniquely identify the server for data communication purposes. 
     In accordance with illustrative embodiments, routing structures (constructs) are used to identify any given memory region within the PMEM modules at any of the servers depicted in  FIG. 1 . By way of example only, such a routing structure can be used to identify memory region  140  highlighted in HMAC4:DIMM3 of  FIG. 1 . These networking constructs, which allow for the binding of source and destination addresses, can be used to bind and accurately map applications to their PMEM data locations. 
       FIG. 2  illustrates examples of two such routing structures that can be used to identify persistent memory locations, according to an illustrative embodiment. The two routing structures are illustrated in the context of the Open Systems Interconnection (OSI) model including the data-link layer (layer 2) and the network layer (layer 3). It is to be appreciated, however, that alternative embodiments may have routing structures that are different than the OSI examples shown in  FIG. 2 . It is to be further understood that the routing structures, in illustrative embodiments, serve as headers for packet content and may be appended to or otherwise associated with packet data structures. 
     As shown, layer 3 routing structure  210  comprises a Version field  211 , an Identifier field  212 , a Host MAC (HMAC) field  213 , a Host Internet Protocol (IP) address field  214 , a Root Bridge identifier (ID) field  215 , a DIMM Slot Number field  216 , an Address Range field  217  and a second (optional) Address Range field  218 . Layer 2 routing structure  220  comprises a Version field  221 , an Identifier field  222 , a Host MAC (HMAC) field  223 , a Root Bridge identifier (ID) field  224 , a DIMM Slot Number field  225 , an Address Range field  226  and a second (optional) Address Range field  227 . It is to be appreciated that the routing structures shown in  FIG. 2  may have additional fields that are not shown for the sake of simplicity of illustration and explanation. One of ordinary skill in the art will appreciate which additional fields that are not expressly shown may be part of the routing structure. 
     The Version field ( 211  and  221 ) specifies the IP version of the given network in which the servers are deployed. The Identifier field ( 212  and  222 ) specifies the entity or function with which corresponding packets are associated. The HMAC field ( 213  and  223 ) specifies the Host MAC address of a given server. The Host IP field ( 214 ) specifies the IP address of a given server (note that this field is present in the network layer routing structure  210  but not the data link layer routing structure  220 ). The Root Bridge ID field ( 215  and  224 ) specifies the identifier for the root bridge connecting a given set of servers. The DIMM Slot Number field ( 216  and  225 ) specifies the DIMM slot in which a given PMEM module is installed. The Address Range field ( 217  and  226 ) specifies the address range of a specific memory region on a given PMEM module. The (optional) Address Range  2  field ( 218  and  227 ) specifies the address range of another specific memory region on a given PMEM module. 
     One key aspect of an illustrative embodiment is the embedding of application and tenant information into the Identifier field ( 212  and  222 ). This approach allows for specific PMEM memory regions to be dedicated to tenants that are running specific applications.  FIG. 3  illustrates a process of embedding application and tenant tags (identifiers) into a routing structure, according to an illustrative embodiment. More particularly, process  300  in  FIG. 3  depicts how two different tenants  302  and  304  (e.g., Tenant A and Tenant B, respectively) running the same application (MarketingApp or MA) can be described within the Identifier field of a given routing structure (e.g., routing structure  210  in  FIG. 2 ). It is to be appreciated that the data within the field  212  can be represented in any suitable data format (e.g., bits, ascii, etc.). 
     It is to be appreciated that the use of such routing structures (or more generally, data structures) described above results in many benefits for an information processing system that employs PMEM as primary data storage. 
     For example, illustrative embodiments depicted in and described in the context of  FIG. 2  enable global data reachability at the data addressability layer. Furthermore, by building application/tenancy information into the routing structure, this global data reachability can be constrained to specify tenant ownership of specific persistent memory locations. Still further, the routing structures described in the context of  FIG. 2  represent a uniform application/tenant/PMEM binding approach for identifying any PMEM memory region across any data center (as well as tying that region to a specific tenant and application). 
     In accordance with one or more illustrative embodiments, a routing structure shown in  FIG. 2  ( 210  or  220 ), or a portion thereof, can be represented as a unique hash value. This hash value can be used as a “shorthand” way to track the mappings. It is to be understood that the mapping or binding created herein refers to the association created within the routing structure between a given application/tenant and a specific PMEM memory region location in a specific server. Therefore, a set of PMEM locations can be associated with a certain application/tenant, as further explained in the context of  FIG. 4 . 
       FIG. 4  illustrates a process  400  of application region mapping via hash values, according to an illustrative embodiment. More particularly, for each of a set of PMEM locations respectively represented by routing structures  402 -A,  402 -B,  402 -C and  402 -D, a hash function  404  is applied to the routing structure to generate a respective set of hash values  406 , i.e., hash value A corresponds to routing structure  402 -A, hash value B corresponds to routing structure  402 -B, hash value C corresponds to routing structure  402 -C, and hash value D corresponds to routing structure  402 -D. These hash values are thus hashes of the PMEM location mappings for a given application for a given tenant. The given application and tenant are specified in the ID field of the routing structure as illustrated and previously described above in the context of  FIGS. 2 and 3 . 
     It is to be appreciated that the hash function  404  applied to each routing structure can be a conventional hash function, and can be different for two or more of the routing structures. Also, in a similar manner as shown in process  400 , routing structures that relate to the same application but different tenants can be mapped to the given application. Still further, routing structures for the same tenant but different applications can be mapped to the given tenant. 
     Advantageously, the routing structures according to illustrative embodiments provide the following important information about each PMEM memory region distributed across a set of servers in an information processing system: (i) a unique memory address (extended as needed for a given data set); (ii) location (how to reach the memory region); and (iii) identification (which host or server the memory region is in). 
     This information allows the creation of a routing table built as a distributed hash table (DHT), which allows the information processing system to pinpoint a particular host for a specific PMEM memory address space. Recall that the information processing system could be implemented as a public cloud, a private cloud, or some hybrid combination of both. 
     When an application is scheduled to begin running, the orchestration software of the information processing system can access the hash values assigned to a given application and tenant. These hash values allow the orchestration software to know: (i) the network path; and (ii) the physical PMEM locations that have been allocated specifically to that application.  FIG. 5  illustrates a process  500  of leveraging hash values to map applications to data centers, according to an illustrative embodiment. As shown, assume that for a given application and tenant  502 , a set of hash values  504  are generated (as described above) for a set of PMEM memory regions in which data is persisted for the given application/tenant. Process  500  in  FIG. 5  highlights the ability of networking orchestration software  506  to choose the appropriate data center among a set of data centers  508 - 1 ,  508 - 2  and  508 - 3  based on the hash values  504 . Note that each data center in  FIG. 5  is illustratively represented by an information processing system  100  as shown in  FIG. 1 , although a given data center may have more or less servers with PMEM used for primary data storage. Note also that two or more of the data centers can be at different geographic locations. Likewise, two or more servers within a given data center can be at different geographic locations. 
     By utilizing the above-described allocation of PMEM storage to a given application, containers can then be instantiated and mapped to their corresponding PMEM locations using a DHT. These containers can then begin to access persistent storage using byte-addressable semantics. 
     Changes to the routing structure, to the memory structure, concatenation/expansion of data, movement of data (e.g. from DIMM1 to DIMM4), etc., all cause a recalculation of the hash and hash table. Changes to the hash and the hash table can be trapped and trigger communication with management and orchestration (M&amp;O) frameworks and/or applications/application management systems. 
     Accordingly, the PMEM routing framework described above in the context of  FIGS. 1-5  allows an application (e.g., one or more containers) to be placed onto the specific server facilitating local load/store semantics to the application tenant&#39;s persistent data. Such an approach enables applications to find their persistent memory through the use of routing constructs (e.g.,  FIG. 2 ) that specify root bridge, server, and memory bank pathing. This decentralized approach, however, can lead to challenges in preventing unauthorized access during system operation. These problems are described below. 
     Recall that  FIG. 1  depicts a configuration with a server (HMAC4) containing PMEM (slots 0-3) with a storage segment  140  dedicated to a specific application and tenant (PMEM slot 3). 
       FIG. 6  illustrates an example  600  with further details of the HMAC 4 server. More particularly, the server  610  comprises a container framework  620  with two different containers, i.e., a tenant container  622  and a malicious container  624 , attempting to access the data fragment  640  in PMEM 3 (part of the set of PMEM modules  630  in server  610 ). Note that the container framework  620  operates functionally on top of the host operating system (OS)  626 . 
     Traditional (centralized) persistent storage implementations use a variety of approaches to prevent unauthorized (malicious) persistent storage access (e.g., access control lists (ACLs) on network attached storage (NAS) file systems). The shift towards persistent memory raises a number of access challenges, which are described below. 
     Tenant Identity During Container Instantiation 
     PMEM routing tables, as described above, support the dedication of PMEM regions to specific tenants running specific applications. However, there is currently no mechanism for local servers to verify the container&#39;s tenant identity during container instantiation. 
     Tenant Impersonation 
     If a malicious actor is able to impersonate a tenant (in the form of a malicious container such as  624  in  FIG. 6 ), they will have unauthorized access to the PMEM storage. 
     Accessible Tenancy/Application Catalogue 
     Each local server will need to consult a catalogue of known tenant/application pairings. There is currently no such catalogue to consult for the PMEM data routing framework. 
     Removals/Additions of Tenants 
     As the PMEM data routing framework allocates new application and tenant pairings to introduce into the system, there is no mechanism for proliferating this information as part of a distributed catalog that is accessible to all data centers that are accessible to those tenants. 
     Similarly, if a tenant/application is removed from the system there is no mechanism to record this fact across all data centers. This could result in a malicious actor attempting to use a stale tenant/application handle in order to access PMEM storage. 
     Shared PMEM Storage 
     Should multiple applications desire to share PMEM storage access, there is currently no way to allow multiple applications to share access to the PMEM storage location. 
     Hardware Impersonation 
     PMEM data center providers use root bridge and HMAC routing tables to specify routing access to PMEM data. A malicious data center operator can attempt to duplicate that configuration as a way of steering data center requests to a rogue data center. 
     Illustrative embodiments overcome these and other challenges by providing decentralized access management in information processing systems utilizing PMEM and implementing a PMEM data routing framework as described above in the context of  FIGS. 1-5 . 
     As will be explained in detail below, illustrative embodiments provide a secure, distributed ledger system that is locally accessible to all PMEM servers (e.g., all servers in each data center shown in  FIG. 5 ). The ledger system provides a trusted view into the currently approved list of tenants/applications and the PMEM regions that are accessible to them. In some illustrative embodiments, the ledger system may employ Blockstack and blockchain technologies, although alternative embodiments are not limited thereto. Thus, before describing illustrative embodiments of the ledger system in the context of  FIGS. 7-11 , some general concepts associated with Blockstack and blockchain technologies will first be described. 
     In one or more illustrative embodiments, a decentralized identity management system known as “Blockstack” is adapted for use in the PMEM data routing framework described herein. Blockstack is described in detail, for example, in M. Ali et al., “Blockstack: A Global Naming and Storage System Secured by Blockchains,” Proceedings of the 2016 USENIX Annual Technical Conference, p. 181-194, June 2016, the disclosure of which is incorporated by reference herein in its entirety. However, it is to be appreciated that embodiments are not limited to using Blockstack as a decentralized identity management system, and thus embodiments are more generally applicable to any other suitable, non-Blockstack based, decentralized identity management system. 
     In general, Blockstack uses a blockchain to bind a digital property, such as a name, to a given value. Immutability and therefore trust are provided in a decentralized manner by allowing for any new node in the system to independently verify data bindings through a blockchain layer. 
     As used herein, the terms “blockchain,” “digital ledger” and “blockchain digital ledger” may be used interchangeably. As is known, the blockchain or digital ledger protocol is implemented via a distributed, decentralized computer network of compute nodes. The compute nodes are operatively coupled in a peer-to-peer communications protocol. In the computer network, each compute node is configured to maintain a blockchain which is a cryptographically secured record or ledger of data blocks that represent respective transactions within a given computational environment. The blockchain is secured through use of a cryptographic hash function. A cryptographic hash function is a cryptographic function which takes an input (or “message”) and returns a fixed-size alphanumeric string, which is called the hash value (also a message digest, a digital fingerprint, a digest, or a checksum). Each blockchain is thus a growing list of data records hardened against tampering and revision, and typically includes a timestamp, current transaction data, and information linking it to a previous block. More particularly, each subsequent block in the blockchain is a data block that includes a given transaction(s) and a hash value of the previous block in the chain, i.e., the previous transaction. That is, each block is typically a group of transactions. Thus, advantageously, each data block in the blockchain represents a given set of transaction data plus a set of all previous transaction data. 
     In the case of a “bitcoin” type implementation of a blockchain distributed ledger, the blockchain contains a record of all previous transactions that have occurred in the bitcoin network. The bitcoin system was first described in S. Nakamoto, “Bitcoin: A Peer to Peer Electronic Cash System,” 2008, the disclosure of which is incorporated by reference herein in its entirety. 
     A key principle of the blockchain is that it is trusted. That is, it is critical to know that data in the blockchain has not been tampered with by any of the compute nodes in the computer network (or any other node or party). For this reason, a cryptographic hash function is used. While such a hash function is relatively easy to compute for a large data set, each resulting hash value is unique such that if one item of data in the blockchain is altered, the hash value changes. However, it is realized that given the constant generation of new transactions and the need for large scale computation of hash values to add the new transactions to the blockchain, the blockchain protocol rewards compute nodes that provide the computational service of calculating a new hash value. In the case of a Bitcoin network, a predetermined number of bitcoins are awarded for a predetermined amount of computation. The compute nodes thus compete for bitcoins by performing computations to generate a hash value that satisfies the blockchain protocol. Such compute nodes are referred to as “miners.” Performance of the computation of a hash value that satisfies the blockchain protocol is called “proof of work.” While bitcoins are one type of reward, blockchain protocols can award other measures of value (monetary or otherwise) to successful miners. 
     It is to be appreciated that the above description represents an illustrative implementation of the blockchain protocol with a Blockstack naming system and that embodiments of the invention are not limited to the above or any particular blockchain protocol or naming system implementation. As such, other appropriate processes may be used to securely maintain and add to a set of data in accordance with embodiments of the invention. For example, distributed ledgers such as, but not limited to, R3 Corda, Ethereum, and Hyperledger may be employed in alternative embodiments. 
     Turning now to  FIG. 7 , a system  700  for decentralized access management in an information processing system that utilizes persistent memory is shown. More particularly, system  700  illustrates a PMEM data routing framework similar to that the one illustrated in  FIG. 5 . That is, management and orchestration (M&amp;O) system  702  represents networking orchestration software ( 506  in  FIG. 5 ) that is configured to, in response to an application deployment request or a container deployment request, choose the appropriate data center among a set of data centers  704 - 1 ,  704 - 2  and  704 - 3  based on hash values ( 504  in  FIG. 5 ) representing PMEM data routing information generated and stored as explained above. 
     As further shown, the PMEM data routing framework in  FIG. 7  comprises a distributed ledger system  710  with a plurality of ledger nodes  712 - 1 ,  712 - 2 ,  712 - 3  and  712 - 4 . Ledger nodes  712 - 1 ,  712 - 2 ,  712 - 3  and  712 - 4 , in one or more illustrative embodiments, are a plurality of blockchain nodes operatively coupled to form a distributed data access management ledger system (i.e., ledger system  710 ). A given blockchain node or BCN in the ledger system serves as a local BCN for a given one of the data centers  704 - 1 ,  704 - 2  and  704 - 3  or M&amp;O system  702 . In addition, in one or more illustrative embodiments, each BCN is further configured to support a distributed identity system such as the above-mentioned Blockstack identity system. 
     Still further, each data center operator providing PMEM service (e.g.,  704 - 1 ,  704 - 2  and  704 - 3  in  FIG. 7 ) is assigned a unique cryptographic key pair with a public key and a private key. Each data center uses its private key to digitally publish (and sign) their data center configurations through their local ledger node onto the distributed ledger system  710 . Advantageously, a ledger is created which is exclusively dedicated to the operation of the PMEM data routing framework. This ledger can be constructed based on the number of root bridge nodes that participate in the PMEM data routing configuration. 
     Each data center operator providing PMEM services (e.g., data center location  704 - 1  referenced as “Location 1 DC”) creates a ledger transaction highlighting the routing information for their PMEM configurations. An example of Location 1 publishing this information (and signing using their private key) is illustrated as ledger transaction  800  in  FIG. 8 . 
     In addition to digitally signing the core routing IP addresses, the data center provider can also provide other security information that can be recorded in the ledger including, but not limited to: (i) signed information identifying hardware (HW)/built-in operating system (BIOS)/firmware; and (ii) a signed OS image. 
     Furthermore, each application/tenant possesses a private key (part of a public key/private key pair) known only by either the user of the system (e.g., data center) and/or the M&amp;O system  702 . For example, an enterprise resource planning (ERP) application can be run by a tenant known as “Tenant B”. The “ERP/Tenant B” identity can be “registered” on the distributed ledger  710  that spans the PMEM data routing framework depicted in  FIG. 7 . In one or more illustrative embodiments, this registration can occur using techniques such as those employed by the Blockstack identity system. This results in the “ERP/Tenant B” identity being associated with a public key within a ledger entry, depicted in ledger transaction  900  in  FIG. 9 . 
     Still further, when a set of PMEM storage locations are bound to an application/tenant identity, this binding can also be stored into the ledger, and the binding is also digitally signed using a private key (of a public/private key pair) of the application/tenant. Using the PMEM hashes depicted in  FIG. 4  as an example, a PMEM allocation entry is created for the binding. An example of this is shown as ledger transaction  1000  in  FIG. 10 . 
     In one or more illustrative embodiments, in addition to the information provided above, the container (or a micro-service) may have a signed application image as well. 
     When an application is deployed by the M&amp;O system  702  ( FIG. 7 ) to a server that contains the PMEM storage for that application, it is accompanied by a digital signature which contains the public key. For example, if the ERP application is assigned as a set of containers to server “HMAC4,” the public key for identity “ERP/Tenant B” also accompanies the container assignment request. 
     When a signed container allocation request is received by a server, it can consult the ledger to verify that the public key accompanying the request correctly identifies the application and tenant that has been bound to the PMEM locations. Example  1100  in  FIG. 11  shows this ledger consultation for the server  610  from  FIG. 6 . Recall that the server  610  has two containers executing, i.e., the legitimate tenant container  622  and the malicious container  624 . The example shows the server accessing the ledger system  710  to verify the ledger transactions  900  (allocation/tenant identity ledger entry) and  1000  (PMEM allocation entry is created for the binding) to determine that the access request from tenant container  622  is an authentic request while the access request from malicious container  624  is a malicious request. 
     Thus, advantageously, when the application arrives at the correct data center containing the correct PMEM data slots, the mapping of the application to those PMEM locations is carried out and then recorded in the distributed ledger system ( 710  in  FIG. 7 ) using the data center operator&#39;s private key. This signature proves that a rogue operator (e.g., malicious container  624 ) did not impersonate the hardware (because they do not possess the correct private key). 
     In one or more further illustrative embodiments, if a tenant/application identity wishes to extend access to a second entity, they can extend permissions to that entity by generating a signed transaction specifying access privileges to the second identity. This means that the validating server must consult the ledger system ( 710  in  FIG. 7 ) and locate this “extend permissions” transaction to validate the second application/tenant. 
     At least portions of the information processing systems and processes shown in  FIGS. 1-11  may be implemented using one or more processing platforms. In some embodiments, a given such processing platform comprises at least one processing device comprising a processor coupled to a memory. The processor and memory in some embodiments comprise respective processor and memory elements of a virtual machine or container provided using one or more underlying physical machines. The term “processing device” as used herein is intended to be broadly construed so as to encompass a wide variety of different arrangements of physical processors, memories and other device components as well as virtual instances of such components. For example, a “processing device” in some embodiments can comprise or be executed across one or more virtual processors. Processing devices can therefore be physical or virtual and can be executed across one or more physical or virtual processors. It should also be noted that a given virtual device can be mapped to a portion of a physical one. In many embodiments, logic may be executed across one or more physical or virtual processors. In certain embodiments, a virtual processor may be mapped to and executed on or across a portion of one or more virtual or physical processors. An illustrative embodiment of a processing platform will now be described in greater detail in conjunction with  FIG. 12 . 
     As is apparent from the above, one or more of the processing modules or other components of the information processing systems and processes shown in  FIGS. 1-11  may each run on a computer, server, storage device or other processing platform element. A given such element may be viewed as an example of what is more generally referred to herein as a “processing device.” An example of such a processing platform is processing platform  1200  shown in  FIG. 12 . 
     The processing platform  1200  in this embodiment comprises a plurality of processing devices, denoted  1202 - 1 ,  1202 - 2 ,  1202 - 3 , . . .  1202 -N, which communicate with one another over a network  1204 . 
     The network  1204  may comprise any type of network, including by way of example a global computer network such as the Internet, a WAN, a LAN, a satellite network, a telephone or cable network, a cellular network, a wireless network such as a WiFi or WiMAX network, or various portions or combinations of these and other types of networks. 
     As mentioned previously, some networks utilized in a given embodiment may comprise high-speed local networks in which associated processing devices communicate with one another utilizing Peripheral Component Interconnect Express (PCIe) cards of those devices, and networking protocols such as InfiniBand, Gigabit Ethernet or Fibre Channel. 
     The processing device  1202 - 1  in the processing platform  1200  comprises a processor  1210  coupled to a memory  1212 . 
     The processor  1210  may comprise a microprocessor, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other type of processing circuitry, as well as portions or combinations of such circuitry elements. 
     The memory  1212  may comprise random access memory (RAM), read-only memory (ROM) or other types of memory, in any combination. The memory  1212  and other memories disclosed herein should be viewed as illustrative examples of what are more generally referred to as “processor-readable storage media” storing executable program code of one or more software programs. 
     Articles of manufacture comprising such processor-readable storage media are considered embodiments of the present disclosure. A given such article of manufacture may comprise, for example, a storage array, a storage disk or an integrated circuit containing RAM, ROM or other electronic memory, or any of a wide variety of other types of computer program products. The term “article of manufacture” as used herein should be understood to exclude transitory, propagating signals. Numerous other types of computer program products comprising processor-readable storage media can be used. 
     Also included in the processing device  1202 - 1  of the example embodiment of  FIG. 12  is network interface circuitry  1214 , which is used to interface the processing device with the network  1204  and other system components, and may comprise conventional transceivers. 
     The other processing devices  1202  of the processing platform  1200  are assumed to be configured in a manner similar to that shown for processing device  1202 - 1  in the figure. 
     Again, this particular processing platform is presented by way of example only, and other embodiments may include additional or alternative processing platforms, as well as numerous distinct processing platforms in any combination, with each such platform comprising one or more computers, servers, storage devices or other processing devices. 
     For example, other processing platforms used to implement embodiments of the disclosure can comprise different types of virtualization infrastructure, in place of or in addition to virtualization infrastructure comprising virtual machines. Such virtualization infrastructure illustratively includes container-based virtualization infrastructure configured to provide Docker containers or other types of Linux containers (LXCs). 
     The containers may be associated with respective tenants of a multi-tenant environment of an information processing system(s), although in other embodiments a given tenant can have multiple containers. The containers may be utilized to implement a variety of different types of functionality within the system. For example, containers can be used to implement respective cloud compute nodes or cloud storage nodes of a cloud computing and storage system. The compute nodes or storage nodes may be associated with respective cloud tenants of a multi-tenant environment. Containers may be used in combination with other virtualization infrastructure such as virtual machines implemented using a hypervisor. 
     As another example, portions of a given processing platform in some embodiments can comprise converged infrastructure such as VxRail™, VxRack™ or Vblock® converged infrastructure commercially available from VCE, the Virtual Computing Environment Company, now the Converged Platform and Solutions Division of Dell EMC. For example, portions of an information processing system of the type disclosed herein can be implemented utilizing converged infrastructure. 
     It should therefore be understood that in other embodiments different arrangements of additional or alternative elements may be used. In many embodiments, at least a subset of these elements may be collectively implemented on a common processing platform, or each such element may be implemented on a separate processing platform. 
     Also, in other embodiments, numerous other arrangements of computers, servers, storage devices or other components are possible in the information processing systems and processes described herein. Such components can communicate with other elements of the system over any type of network or other communication media. 
     As indicated previously, in some embodiments, components of information processing systems and processes as disclosed herein can be implemented at least in part in the form of one or more software programs stored in memory and executed by a processor of a processing device. For example, at least portions of the execution environment or other system components are illustratively implemented in one or more embodiments the form of software running on a processing platform comprising one or more processing devices. 
     It should again be emphasized that the above-described embodiments of the disclosure are presented for purposes of illustration only. Many variations and other alternative embodiments may be used. For example, the disclosed techniques are applicable to a wide variety of other types of information processing systems. Also, the particular configurations of system and device elements, associated processing operations and other functionality illustrated in the drawings can be varied in other embodiments. Moreover, the various assumptions made above in the course of describing the illustrative embodiments should also be viewed as exemplary rather than as requirements or limitations of the embodiments. Numerous other alternative embodiments within the scope of the appended claims will be readily apparent to those skilled in the art.