Managing secret computations

Abstract

The method may include receiving a read request from a client program. The method may further include retrieving one or more secrets from a secret store in response to receiving the read request. The retrieving may include storing the one or more secrets in a storage location. The method may further include initiating transmission of the one or more secrets to the client program in response to the read request. The method may further include deleting the one or more secrets from the storage location.

Description

[Technical Field]

[0001] The present disclosure relates to communication between computing system components, and more particularly to managing secret computations. [Background technology]

[0002] A computing system, such as one having a multi-tier architecture, can be configured such that discrete system components communicate with each other through external interfaces. For security purposes, such discrete system components can be configured to obtain secrets, such as tokens, keys, or passwords, or a combination thereof, from other system components before granting access to the data. Such secrets can verify the identity and / or authenticity of a first system component attempting to access data of a second system component. Summary of the Invention

[0003] According to an embodiment of the present disclosure, a method may include receiving a read request from a client program. The method may further include retrieving one or more secrets from a secrets store. The retrieving may be performed in response to receiving the read request. The retrieving may include storing the one or more secrets in a storage location. The method may further include initiating transmission of the one or more secrets to the client program. The initiating may be performed in response to the read request. The method may further include deleting the one or more secrets from the storage location.

[0004] Systems and computer program products corresponding to the above-described methods are also included herein.

[0005] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

[0006] The drawings included in this application are incorporated into and form a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the disclosure. The drawings are merely illustrative of particular embodiments and do not limit the disclosure. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an exemplary computing environment having a secrets engine, according to an embodiment of the present disclosure. [Figure 2] 1 is a flowchart of an example method for performing secret management, according to an embodiment of the present disclosure. [Figure 3] FIG. 1 illustrates exemplary major components of a computer system that may be used in accordance with embodiments of the present disclosure. [Figure 4] FIG. 1 illustrates a cloud computing environment according to an embodiment of the present disclosure. [Figure 5] FIG. 1 illustrates abstraction model layers according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0008] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular described embodiments. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

[0009] Aspects of the present disclosure relate to communication between computing system components, and more particularly to managing secret computations. While the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure may be appreciated through the discussion of various examples using this context.

[0010] A computing system, such as one having a multi-tier architecture, can be configured such that discrete system components communicate with each other through external interfaces. For security purposes, such discrete system components can be configured to obtain secrets, such as tokens, keys, or passwords, or a combination thereof, from other system components before granting access to the data. Such secrets can verify the identity and / or authenticity of a first system component attempting to access data of a second system component.

[0011] In some examples, a computing system can be configured such that secrets are stored in file system objects, such as computer files. Such file system objects can be stored in one or more discrete system components. In these examples, a first discrete system component (e.g., a client system) that stores such a file system object can obtain the secret by reading the file system object. The first system component can then transmit the secret to a second system component (e.g., a provider system). In response to receiving the secret, the second system component can verify the identity of the first system component and authorize the first system component to access the information.

[0012] Storing secrets in such file system objects can make a computing system vulnerable to intrusion because the file system objects can potentially remain accessible indefinitely at discrete system components. Thus, secrets can be susceptible to security breach whenever the discrete system components are susceptible to security breach. Additionally, modifying such a computing system to store and / or access secrets from locations external to the discrete system components may require custom programming for multiple discrete system components. Such modifications may involve introducing additional interface, behavior, and synchronization parameters between each discrete system component and one or more external devices that may store secrets. Consequently, such modifications may be cumbersome to implement and maintain.

[0013] To address these and other challenges, embodiments of the present disclosure include a secret engine. In some embodiments, the secret engine can abstract the management of secrets in computing systems configured to utilize secrets stored in file system objects. More specifically, in some embodiments, the secret engine can retrieve a secret from a secret store, present the secret as the data content of a pseudo-filesystem object, and delete the secret. In some embodiments, the pseudo-filesystem object can be configured to have functionality and appearance similar to the functionality and appearance of the file system object that stores the secret. Thus, in some embodiments, the secret engine can perform operations such as retrieving and presenting a secret in response to one or more operations by a computer program to read the pseudo-filesystem object. Hence, in some embodiments, the secret engine can replace such file system objects in a manner that cannot be recognized by one or more system components.

[0014]

[0013] Embodiments of the present disclosure may include multiple advantages. For example, in some embodiments, a secret engine may retrieve a secret in response to a read request and delete the secret in response to an indication that the secret has been read. Thus, embodiments of the present disclosure may limit the presence of secrets on discrete system components, which may reduce one or more vulnerabilities to intrusion of the discrete system components and / or the corresponding computing system.

[0015] In some embodiments, the secret engine's program instructions can enable discrete system components to retrieve secrets from one or more secret stores. Such enablement can serve discrete system components without the need to introduce modifications, such as custom changes, to the discrete system components' program instructions to enable communication with one or more secret stores. Accordingly, embodiments of the present disclosure can facilitate efficient integration with existing computing systems. Additionally, such integration can be facilitated solely by the secret engine's ability to perform secret management based on one or more read operations targeted at pseudo file system objects. As a result, embodiments of the present disclosure can enable discrete system components of a computing system to communicate efficiently and with improved security.

[0016] Referring to the figures, FIG. 1 illustrates a computing environment 100 including one or more of each of a secret engine 105, a client system 125, a secret store 140, a provider system 150, or a network 160, or a combination thereof. In some embodiments, at least one secret engine 105, a client system 125, a secret store 140, or a provider system 150, or a combination thereof, can exchange data with at least one other through at least one network 160. For example, in some embodiments, at least one secret engine 105 can exchange data with at least one secret store 140 through at least one network 160. One or more of each of the secret engine 105, the client system 125, the secret store 140, the provider system 150, or a network 160, or a combination thereof, can include a computer system, such as computer system 301 discussed with respect to FIG. 3.

[0017] In some embodiments, the secret engine 105 may be included in software installed on the computer system of the client system 125. For example, in some embodiments, the secret engine 105 may be included as a plug-in software component of software installed on the client system 125. The secret engine 105 may include program instructions executed by a processor, such as the processor of the client system 125, to perform one or more of the operations discussed with respect to FIG.

[0018] In some embodiments, secret engine 105 may be a computer program that may include one or more modules, such as one or more of pseudo file system objects 110, daemons 115, and / or timing manager 120. In some embodiments, one or more of pseudo file system objects 110, daemons 115, and / or timing manager 120 may be integrated into a single module. In some embodiments, one or more of pseudo file system objects 110, daemons 115, and / or timing manager 120 may include program instructions executed by a processor, such as a processor of client system 125, to perform one or more operations discussed with respect to FIG. 2. For example, in some embodiments, pseudo file system object 110 may include program instructions for performing operation 205 of FIG. 2. In some embodiments, daemon 115 may include program instructions for performing operations 215 and 225-235 of FIG. 2. In some embodiments, timing manager 120 may include program instructions for performing operations 210 and 220 of FIG. 2.

[0019] 1, in some embodiments, pseudo file system object 110 may mimic a file system object, such as a computer file that stores data (e.g., secrets). Mimicking a file system object may refer to pseudo file system object 110 exhibiting one or more properties and / or characteristics of the file system object.

[0020] For example, in some embodiments, like a file system object, pseudo file system object 110 can receive requests from computer programs, such as client program 130, to read (e.g., to present data to the computer program). In response, like a file system object, pseudo file system object 110 can present data to such computer programs. In another example, in some embodiments, a computer program requesting data from pseudo file system object 110 can open a file descriptor, just as a computer program requesting data from a file system object can include a computer program opening a file descriptor. Continuing this example, the computer program can close the file descriptor corresponding to pseudo file system object 110 in response to the computer program retrieving data from pseudo file system object 110. Such closing can be similar to a computer program closing a file descriptor corresponding to a file system object in response to the computer program retrieving data from the file system object. In some embodiments, the file descriptor can include an identification, such as an alphanumeric code, corresponding to the file system object accessed by the computer program.Thus, opening a file descriptor may include the computer program generating and storing such an identification when the computer program accesses a file system object or pseudo file system object, and closing a file descriptor may include the computer program removing such identification (e.g., deleting the file descriptor and / or removing the association between the file descriptor and the file system object) in response to retrieving data from the file system object or pseudo file system object. Thus, in some embodiments, by mimicking a file system object, pseudo file system object 110 may present data to a computer program in response to an action by the computer program to read pseudo file system object 110, and such data presentation may be substantially similar to the file system object presenting data to a computer program when the computer program reads the file system object.

[0021] As another example, in some embodiments, pseudo file system object 110 may be stored in a manner similar to the manner in which a file system object may be stored. For example, in some embodiments, pseudo file system object 110 may be stored in a location where file system objects are typically stored. As another example, in some embodiments, pseudo file system object 110 may include a file name that is identical or substantially similar to the file name of a file system object. Thus, in some embodiments, by mimicking a file system object, pseudo file system object 110 may have functionality and appearance similar to the functionality and appearance of a file system object.

[0022] In some embodiments, the daemon 115 may perform an operation such as obtaining an indication of an open file descriptor, obtaining one or more secrets 145, initiating the transmission of one or more secrets 145, obtaining an indication of a closed file descriptor, or deleting one or more secrets 145, or a combination thereof. In some embodiments, the daemon 115 may perform such an operation with respect to a corresponding pseudo file system object 110 of the secret engine 105. In some embodiments, the timing manager 120 may start a timer and determine when a threshold time expires.

[0023] In some embodiments, client system 125 may include a computing device configured to retrieve data 155 from provider system 150. Client system 125 may include client program 130 and storage location 135. In some embodiments, client program 130 may include a computer program having program instructions for performing operations such as reading a file system object (e.g., retrieving data from the file system object), retrieving one or more secrets, sending the one or more secrets to provider system 150, retrieving data 155, opening a file descriptor, or closing a file descriptor, or a combination thereof. In some embodiments, storage location 135 may include memory, such as memory 320 discussed with respect to FIG. 3 , and in some embodiments, storage location 135 may include random access memory (“RAM”) of client system 125.

[0024] In some embodiments, secret store 140 may include a computing device, such as a web server, that may store one or more secrets 145. In some embodiments, secret store 140 may utilize multiple data security features, such as one or more layers of encryption, to restrict access to one or more secrets 145. Secrets 145 may include data used by an entity, such as client program 130, to access data, such as data 155. For example, in some embodiments, secrets 145 may include data such as a password, a connection string, a username, a key, or a token, or a combination thereof.

[0025] In some embodiments, provider system 150 may include a computing device, such as a web server, that may store data 155. In some embodiments, provider system 150 may grant access to data 155 in response to receiving one or more secrets 145 from client program 130 of client system 125.

[0026] In some embodiments, network 160 may be a wide area network (WAN), a local area network (LAN), the Internet, or an intranet. In some embodiments, network 160 may be substantially similar to or the same as cloud computing environment 50 discussed with respect to FIG.

[0027] In an exemplary operation of the secret engine 105, the client system 125 may be an automated teller machine ("ATM") configured to retrieve data 155 (e.g., account balance data) from a provider system 150 (e.g., a server of a financial institution) over a network 160. Further, in this example, the client system 125 may be configured to store a file system object (e.g., a computer file), which may store a secret (e.g., an authentication code for accessing the data 155 of the provider system 150). The client program 130 may be configured to retrieve the secret by reading the file system object. However, in this example, by using the secret engine 105, the client system 125 does not store such a file system object containing such a secret. Instead, in this example, the client program 130 may retrieve such a secret by sending a read request to the pseudo file system object 110. In response to such a read request, daemon 115 may retrieve secret 145 (e.g., an authentication code) from secret store 140 (e.g., a secure web server) and store secret 145 in storage location 135 (e.g., RAM of client system 125). Further, in this example, daemon 115 may present secret 145 as the content of pseudo file system object 110, which may be retrieved by client program 130. As a result, in this example, pseudo file system object 110 may act in place of a file system object that stores secrets. Continuing with this example, in response to receiving an indication that client program 130 has retrieved secret 145 (e.g., an indication that a file descriptor has been closed), daemon 115 may delete secret 145 from storage location 135.Continuing with this example, client program 130 can transmit secret 145 (e.g., an authentication code) to provider system 150 (e.g., a financial institution's server) to access data 155 (e.g., account balance data). Further operations of the present disclosure are discussed below with respect to FIG. 2.

[0028] 2 illustrates a flowchart of an example method 200 for managing one or more secrets according to an embodiment of the present disclosure. The method 200 may be performed by a secret engine, such as the secret engine 105 of FIG.

[0029] Referring back to FIG. 2 , at operation 205, the secret engine may receive a read request. In some embodiments, the read request may refer to a request issued by a computer program, such as client program 130 of FIG. 1 , to obtain data from a file system object. In some embodiments, the read request may refer to a command issued by such a computer program for a file system object to provide data to the computer program. In some embodiments, operation 205 may include the secret engine initially obtaining an indication that a file descriptor has been opened. In these embodiments, such a file descriptor may correspond to a pseudo file system object of the secret engine.

[0030] For example, in some embodiments, a pseudo file system object of the secret engine may receive a read request from a client program of a client system. The read request may be based on the client program requesting data from the pseudo file system object. In some embodiments, the client program may open a file descriptor when requesting data from the pseudo file system object. The client program may store the file descriptor in a discrete system component, such as client system 125 of FIG. 1. In these embodiments, a daemon of the secret engine may include program instructions to monitor a discrete system component, such as a client system, to detect when a file descriptor corresponding to the pseudo file system object is opened (e.g., when an alphanumeric code corresponding to the pseudo file system object is generated, stored, or both).

[0031] In operation 210, the covert engine may start a timer. For example, in response to operation 205, a timing manager of the covert engine may start a timer to monitor elapsed time and determine when a threshold time, such as 5 seconds, has expired. In some embodiments, the threshold time may be selected by an entity such as a programmer of the covert engine.

[0032] In operation 215, the secret engine may retrieve one or more secrets from a secret store, such as secret store 140 of FIG. 1 . In some embodiments, operation 215 may include the secret engine accessing secrets stored in the secret store and storing one or more secrets from the secret store. In some embodiments, the secret engine may perform operation 215 in response to receiving a read request in operation 205. In some embodiments, the secret engine may perform operation 215 in response to receiving an indication that a file descriptor corresponding to a pseudo file system object is open in operation 205. In some embodiments, operation 215 may include the secret engine daemon retrieving the one or more secrets from the secret store through one or more encrypted channels. In some embodiments, operation 215 may include the secret engine daemon temporarily storing the one or more secrets in a storage location, such as memory, of the client system.

[0033] In operation 220, the secrecy engine may determine whether the threshold time has expired. If in operation 220 the secrecy engine determines that the threshold time has expired, the secrecy engine may proceed to operation 235. Alternatively, if the secrecy engine determines that the threshold time has not expired, the secrecy engine may proceed to operation 225.

[0034] For example, in operation 220, the timing manager of the secret engine may determine whether the elapsed time after starting the timer in operation 210 equals a threshold time. In this example, the threshold time expires when the elapsed time equals the threshold time. In some embodiments, operation 220 may provide additional security to the secret management performed by the secret engine because operation 220 may prevent one or more secrets from remaining accessible indefinitely at discrete system components.

[0035] In operation 225, the secret engine may initiate transmission of the one or more secrets obtained in operation 215 in response to the read request received in operation 205. In some embodiments, such initiating may include the secret engine daemon presenting the one or more secrets within the pseudo file system object as data content of the pseudo file system object. In some embodiments, operation 215 may include the secret engine daemon presenting the one or more secrets in encoded text, such as base 64 encoded text. In some embodiments, in operation 225, the secret engine may enable a computer program, such as client program 130 of FIG. 1, to retrieve the one or more secrets from the pseudo file system object.

[0036] In operation 230, the secret engine may obtain an indication of a file descriptor corresponding to the pseudo file system object being closed. In some embodiments, the secret engine may obtain such an indication at a second time after the initial time. For example, in some embodiments, a computer program (e.g., client program 130 of FIG. 1 ) may close a file descriptor in response to retrieving one or more secrets from a pseudo file system object. In these embodiments, a secret engine daemon may include program instructions to monitor a discrete system component (e.g., client system 125 of FIG. 1 ) to detect when a file descriptor corresponding to a pseudo file system object is closed (e.g., when the file descriptor, or the association between the file descriptor and the pseudo file system object, or both, are deleted).

[0037] In operation 235, the secret engine may delete the one or more secrets stored in operation 215. In some embodiments, the secret engine may perform operation 235 in response to receiving an indication in operation 230 that a file descriptor corresponding to the pseudo file system object has been closed. In some embodiments, operation 235 may include a secret engine daemon removing the one or more secrets from an internal representation of the pseudo file system object as data content. In some embodiments, operation 235 may include a secret engine daemon removing the one or more secrets from a storage location. In some embodiments, operation 235 may include a secret engine timing manager ending monitoring of elapsed time.

[0038] FIG. 3 illustrates representative major components of an exemplary computer system 301 that can be used in accordance with embodiments of the present disclosure. The specific components illustrated are presented solely for illustrative purposes, and such variations are not required. Computer system 301 can include a processor 310, memory 320, an input / output interface (also referred to herein as I / O or I / O interface) 330, and a main bus 340. Main bus 340 can provide a communication path to other components of computer system 301. In some embodiments, main bus 340 can be connected to other components, such as a dedicated digital signal processor (not shown).

[0039] The processor 310 of the computer system 301 may be comprised of one or more CPUs 312. The processor 310 may additionally be comprised of one or more memory buffers or caches (not shown) that provide temporary storage of instructions and data to the CPU 312. The CPU 312 may execute instructions on input provided from the cache or memory 320 and output results to the cache or memory 320. The CPU 312 may be comprised of one or more circuits configured to perform one or more methods consistent with embodiments of the present disclosure. In some embodiments, the computer system 301 may include multiple processors 310, which is typical of relatively large systems. However, in other embodiments, the computer system 301 may be a single processor with only one CPU 312.

[0040] The memory 320 of the computer system 301 may comprise a memory controller 322 and one or more memory modules (not shown) for temporarily or permanently storing data. In some embodiments, the memory 320 may include a random-access semiconductor memory, storage device, or storage medium (either volatile or nonvolatile) for storing data and programs. The memory controller 322 may communicate with the processor 310 and facilitate the storage and retrieval of information in the memory module. The memory controller 322 may communicate with the I / O interface 330 and facilitate the storage and retrieval of input or output in the memory module. In some embodiments, the memory module may be a dual in-line memory module.

[0041] I / O interface 330 may include I / O bus 350, terminal interface 352, storage interface 354, I / O device interface 356, and network interface 358. I / O interface 330 may connect main bus 340 to I / O bus 350. I / O interface 330 may route instructions and data from processor 310 and memory 320 to various interfaces of I / O bus 350. I / O interface 330 may also route instructions and data from various interfaces of I / O bus 350 to processor 310 and memory 320. The various interfaces may include terminal interface 352, storage interface 354, I / O device interface 356, and network interface 358. In some embodiments, the various interfaces may include a subset of the foregoing interfaces (e.g., an embedded computer system in an industrial application may not include terminal interface 352 and storage interface 354).

[0042] Logical modules throughout computer system 301 (including, but not limited to, memory 320, processor 310, and I / O interface 330) can communicate faults and changes to one or more components to a hypervisor or operating system (not shown). The hypervisor or operating system can allocate the various resources available to computer system 301 and track the location of data in memory 320 and processes assigned to the various CPUs 312. In embodiments that combine or rearrange elements, aspects of the functionality of the logical modules can be combined or redistributed. These modifications will be apparent to those skilled in the art.

[0043] Although this disclosure includes detailed descriptions of cloud computing, it should be understood in advance that implementations of the teachings detailed herein are not limited to cloud computing environments. Rather, embodiments of the present invention can be implemented in conjunction with any other type of computing environment now known or later developed.

[0044] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal administrative effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0045] The features are as follows:

[0046] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capabilities such as server time and network storage automatically as needed, without the need for human interaction with the provider of the service.

[0047] Pervasive Network Access: Functionality is available across the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0048] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated on demand. Consumers typically have no control or knowledge over the exact location of the resources provided, although there is a sense of location independence in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0049] Rapid Elasticity: Capabilities can be rapidly and elastically provisioned and rapidly scaled out, and rapidly released and rapidly scaled in, sometimes automatically. To the consumer, the capabilities available for provisioning often appear unlimited and can be purchased in any quantity at any time.

[0050] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at an abstraction level appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0051] The service model is as follows:

[0052] Software as a Service (SaaS): The functionality offered to the consumer is the use of a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, except for the possibility of limited user-specific application configuration settings.

[0053] Platform as a Service (PaaS): The capability offered to the consumer is the deployment of consumer-created or acquired applications written using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the application hosting environment configuration.

[0054] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processing, storage, network, and other basic computing resources onto which they can deploy and run any software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but they do have control over the operating systems, storage, deployed applications, and in some cases, limited control over selected networking components (e.g., host firewalls).

[0055] The deployment model is as follows:

[0056] Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0057] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with shared concerns (e.g., mission, security requirements, policy, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0058] Public Cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by organizations that sell cloud services.

[0059] Hybrid Cloud: A cloud infrastructure is a composite of two or more clouds (private, community, or public) that remain unique entities but are joined by standard or proprietary technologies that allow for data and application portability (e.g., cloud bursting for load balancing between clouds).

[0060] Cloud computing environments are service-oriented with an emphasis on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0061] Referring now to FIG. 4, an exemplary cloud computing environment 50 is shown. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or mobile phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or combinations thereof, can communicate. The nodes 10 can communicate with each other. The nodes 10 may be physically or virtually grouped in one or more networks, such as the previously described private cloud, community cloud, public cloud, or hybrid cloud, or combinations thereof (not shown). This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without the cloud consumer having to maintain resources on their local computing device. It should be understood that the types of computing devices 54A-54N shown in FIG. 4 are intended to be exemplary only, and that computing node 10 and cloud computing environment 50 can communicate with any type of computerized device over any type of network and / or network-addressable connection (e.g., using a web browser).

[0062] Referring now to Figure 5, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 4) is shown. It should be understood in advance that the components, layers, and functions shown in Figure 5 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As shown, the following layers and corresponding functions are provided:

[0063] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframe 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0064] The virtualization layer 70 provides an abstraction layer that can comprise the following examples of virtual entities: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0065] In one example, the management layer 80 may provide the following functions: Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and bills or invoices for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks and protection of data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management to ensure required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides proactive provisioning and procurement of cloud computing resources in anticipation of future demand according to SLAs.

[0066] The workload layer 90 provides examples of functions that can utilize a cloud computing environment. Examples of workloads and functions that can be provided from this layer include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and secret management logic 96.

[0067] As discussed in more detail herein, it is contemplated that some or all of the operations of some of the method embodiment described herein may be performed in an alternate order or not at all, and furthermore, that multiple operations may be performed simultaneously or as part of a larger process.

[0068] The present invention may be a system, method, or computer program product, or a combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0069] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge structures in grooves on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as being ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through fiber optic cable), or electrical signals transmitted through electrical wires.

[0070] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to each computing / processing device or to an external computer or storage device over a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, fiber optic transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage on a computer-readable storage medium within the respective computing / processing device.

[0071] Computer-readable program instructions for carrying out operations of the present invention can be either source code or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or object-oriented programming languages ​​such as Smalltalk®, C++, etc., and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions can execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can execute computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry to perform aspects of the present invention.

[0072] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0073] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams, to produce a machine. These computer-readable program instructions may also be stored on a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular way, such that the computer-readable storage medium on which the instructions are stored constitutes an article of manufacture containing instructions implementing aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0074] The computer-readable program instructions may further be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be executed by the computer, other programmable apparatus, or other device, thereby resulting in a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device may perform the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0075] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may actually be performed as a single step that is executed concurrently, substantially concurrently, partially, or completely in a time-overlapping manner, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or operations or executes a combination of dedicated hardware instructions and computer instructions.

[0076] The description of various embodiments of the present disclosure has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many variations and modifications will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been chosen to explain the principles of the embodiments, practical applications, or technical improvements to technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method, comprising: receiving a read request from a client program in a client system; In response to receiving the read request, starting a timer; responsive to said receiving said read request, retrieving from said secret store one or more secrets stored in one or more file system objects in said secret store; said obtaining includes temporarily storing the one or more secrets read by one or more pseudo-file system objects configured outside the secret store in a storage location; determining that the timer has exceeded a threshold time; In response to the read request, upon determining that the timer has not exceeded the threshold time, initiate transmission of the one or more secrets to the client program for storage at the storage location; deleting the one or more secrets from the storage location in response to the client program retrieving the secrets; A computer-implemented method for causing a

2. 2. The computer-implemented method of claim 1, wherein said receiving the read request comprises obtaining a first indication at a first time that a file descriptor is open.

3. 3. The computer-implemented method of claim 2, wherein the file descriptor corresponds to the pseudo-file system object.

4. obtaining a second indication at a second time that the file descriptor is closed; further comprising the second time is a time after the first time; 3. The computer-implemented method of claim 2, wherein the deleting the one or more secrets from the storage location is performed in response to obtaining the second indication that the file descriptor has been closed.

5. the read request is received by the pseudo-filesystem object; 2. The computer-implemented method of claim 1, wherein said retrieving said one or more secrets is performed by a daemon corresponding to said pseudo-file system object.

6. said storing said one or more secrets includes said daemon storing said one or more secrets in said storage location; 6. The computer-implemented method of claim 5, wherein the storage location comprises random access memory.

7. 6. The computer-implemented method of claim 5, wherein initiating the transmission of the one or more secrets comprises the daemon presenting the one or more secrets so that the one or more secrets can be retrieved by the client program from the pseudo-file system object.

8. 2. The computer-implemented method of claim 1, wherein the one or more secrets are selected from the group consisting of a password, a connection string, a username, a key, and a token.

9. the read request is received by the pseudo-filesystem object; 2. The computer-implemented method of claim 1, wherein the pseudo-filesystem object mimics a filesystem object.

10. 1. A system comprising: a processor; a memory in communication with the processor, the memory including program instructions configured, when executed by the processor, to cause the processor to perform a method, the method including: receiving a read request from a client program in a client system; In response to receiving the read request, starting a timer; responsive to said receiving said read request, retrieving from said secret store one or more secrets stored in one or more file system objects in said secret store; said obtaining includes temporarily storing the one or more secrets read by one or more pseudo-file system objects configured outside the secret store in a storage location; determining that the timer has exceeded a threshold time; In response to the read request, upon determining that the timer has not exceeded the threshold time, initiate transmission of the one or more secrets to the client program for storage at the storage location; deleting the one or more secrets from the storage location in response to the client program retrieving the secrets; A system that executes the following.

11. The system of claim 10 , wherein the receiving the read request includes obtaining a first indication at a first time that a file descriptor is open.

12. 12. The system of claim 11, wherein the file descriptor corresponds to the pseudo-file system object.

13. The method comprises: obtaining a second indication at a second time that the file descriptor is closed; further comprising the second time is a time after the first time; 12. The system of claim 11, wherein the deleting the one or more secrets from the storage location is performed in response to obtaining the second indication that the file descriptor has been closed.

14. the read request is received by the pseudo-filesystem object; 11. The system of claim 10, wherein said retrieving said one or more secrets is performed by a daemon corresponding to said pseudo-file system object.

15. the read request is received by the pseudo-filesystem object; 11. The system of claim 10, wherein the pseudo file system object mimics a file system object.

16. A computer program executed by a computer, the computer comprising: receiving a read request from a client program in a client system; In response to receiving the read request, starting a timer; responsive to said receiving said read request, retrieving from said secret store one or more secrets stored in one or more file system objects in said secret store; said obtaining includes temporarily storing the one or more secrets read by one or more pseudo-file system objects configured outside the secret store in a storage location; determining that the timer has exceeded a threshold time; In response to the read request, upon determining that the timer has not exceeded the threshold time, initiate transmission of the one or more secrets to the client program for storage at the storage location; deleting the one or more secrets from the storage location in response to the client program retrieving the secrets; A computer program that executes the following:

17. 17. The computer program product of claim 16, wherein the receiving the read request comprises obtaining a first indication at a first time that a file descriptor is open.

18. 18. The computer program product of claim 17, wherein the file descriptor corresponds to the pseudo-file system object.

19. The computer, obtaining a second indication at a second time that the file descriptor is closed; Then run the second time is a time after the first time; 18. The computer program product of claim 17, wherein the deleting the one or more secrets from the storage location is performed in response to obtaining the second indication that the file descriptor has been closed.

20. the read request is received by the pseudo-filesystem object; 17. The computer program product of claim 16, wherein the pseudo file system object mimics a file system object.

Images