Integrated Authentication for Container-Based Environments

Abstract

Techniques for providing integrated authentication for a container-based environment are described herein. One aspect includes accessing, by an application running within a container within the container environment hosted by a hypervisor on a host system, an authentication module located within the container environment. Another aspect includes invoking an authentication handler within the container environment based on the access to the authentication module. Another aspect includes passing control from the authentication handler to a hypervisor. Another aspect includes retrieving, by the hypervisor, a security artifact from a security database of the host system. Another aspect includes providing the retrieved security artifact to the application via the authentication handler. Another aspect includes performing an authentication operation by the application using the security artifact.

Description

[Technical field]

[0001] The present invention relates generally to computer systems, and more particularly to integrated authentication for container-based environments. [Background technology]

[0002] In a cloud computing environment, computing is delivered as a service rather than a product, whereby shared resources, software, and information are provided to computers and other devices as a metered service over a network such as the Internet. In such an environment, computation, software, data access, and storage services are provided to users without the users needing knowledge of the physical location or configuration of the systems providing the services.

[0003] A physical computer that is part of a virtualized computer environment may be referred to as a host. A virtualized computer environment, such as that implemented within a physical cloud computing node of a cloud computing environment, may include a host operating system (OS) and one or more guest OSs. The host operating system may include a common base portion that supports a set of virtualized container environments that run on the physical computer. The common base portion may also be referred to as a hypervisor. Each container environment may run guest operating systems and may support multiple containers. Each container may support one or more applications. Summary of the Invention

[0004]

[0003] Embodiments of the present invention relate to providing integrated authentication for a container-based environment. As a non-limiting example, a computer-implemented method includes accessing, by an application executing within a container within a container environment hosted by a hypervisor on a host system, an authentication module located within the container environment. The method also includes invoking an authentication handler within the container environment based on the access to the authentication module. The method also includes passing control from the authentication handler to the hypervisor. The method also includes retrieving, by the hypervisor, a security artifact from a security database of the host system. The method also includes providing the retrieved security artifact to the application via the authentication handler. The method also includes performing an authentication operation by the application using the security artifact.

[0005] Other embodiments of the present invention implement features of the above-described methods in computer systems and computer program products.

[0006] Further technical features and advantages are realized by the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, reference should be made to the detailed description and drawings. [Brief description of the drawings]

[0007] The particulars of the exclusive rights set forth herein are particularly pointed out and distinctly claimed in the claims at the end of the specification. The above and other features and advantages of embodiments of the present invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings.

[0008] [Figure 1A] FIG. 1 is a block diagram illustrating components of a system for providing federated authentication for a container-based environment in accordance with one or more embodiments of the present invention. [Figure 1B]FIG. 1 is a block diagram illustrating components of a system for providing federated authentication for a container-based environment in accordance with one or more embodiments of the present invention. [Figure 2A] 1 is a flowchart illustrating a process for providing integrated authentication for a container-based environment in accordance with one or more embodiments of the present invention. [Figure 2B] 1 is a flowchart illustrating a process for providing integrated authentication for a container-based environment in accordance with one or more embodiments of the present invention. [Diagram 3] FIG. 1 illustrates a cloud computing environment in accordance with an embodiment of the present invention. [Figure 4] FIG. 2 illustrates abstraction model layers according to one embodiment of the present invention. [Diagram 5] FIG. 1 is a block diagram of an exemplary computer system for use in one or more embodiments of integrated authentication for container-based environments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] One or more embodiments of the present invention provide integrated authentication for container-based environments. In order to perform authentication operations in a virtualized container environment, duplication of public and private certificate security artifacts (e.g., certificates and / or private keys) may be required. The replicated security artifacts may be copied to well-known directory and file locations inside the guest OS, so that the guest OS and associated containers in the virtualized container environment can use these security artifacts for certificate validation and authentication. During provisioning of the virtual environment, copies of any certificates may be injected into the virtual environment, which can place these certificates in the appropriate directory locations. However, for a cloud system that includes multiple instances of guest OSes, security artifacts may be copied separately to each instance. In this case, active management of the copied security artifacts may be required to ensure that the copied security artifacts are up-to-date throughout the operation of the cloud system. Management of such security artifacts may be relatively complex, especially for a virtualized container environment in an immutable appliance form.

[0010] In an embodiment of the integrated authentication for container-based environment, authentication operations for a virtualized container environment including a guest OS can be directly integrated into an underlying host OS security database (DB) that stores security artifacts without duplicating the security artifacts within the virtualized container environment. The authentication operations can include, but are not limited to, a Transport Layer Security / Secure Sockets Layer (TLS / SSL) connection, a Lightweight Directory Access Protocol (LDAP) connection, and a Hypertext Transfer Protocol Secure (HTTPS) proxy server connection. The guest OS and the host OS can each be any suitable OS, and in some embodiments of the present invention, the host OS can be z / OS and the guest OS can be Linux.

[0011] An embodiment of an integrated authentication for a container-based environment may include an authentication module including an authentication file or file system and an authentication handler. The authentication file or file system may include a mapping of security artifacts, such as, but not limited to, certificates and key rings (e.g., resource access control facility (RACF) key rings), provided as placeholders in any suitable directory location in the guest OS. When the authentication file or file system is accessed by an application running in a container in the virtualized container environment, the authentication handler is invoked to communicate locally with the underlying host OS and request a security artifact corresponding to the access from the underlying host security database (DB). Multiple instances of the guest OS may access the security artifacts in the security DB through their respective authentication handlers. This may eliminate the need to provide system-wide copies of the security artifacts. In some embodiments, the authentication handler may implement a store hypervisor information (STHYI) instruction that allows the guest OS to communicate directly with the host OS environment without requiring network access. The virtualized container environment can run as a started task under a user identifier (ID) on the host environment, and the user ID can be used to authenticate with a security DB to access the requested security artifact and convert the security artifact into any format required by the virtualized container environment.

[0012] An embodiment of the present invention allows multiple instances of guest OSes to transparently access in real time through the guest OSes' native interfaces a secure centralized security DB including certificate and key stores that belong to the hypervisor (i.e., the host operating system) and are stored in the hypervisor's native storage format. This eliminates the need to statically export and store keys and certificates in a format used by the guest OSes. The conversion of security artifacts between the hypervisor's native format and the format used by the guest OSes can be performed in real time by an authentication handler, and security artifacts can be converted from any storage format used by the security DB to any appropriate format required by the guest OSes' instances. The security DB can be access controlled by the hypervisor to restrict access to the centralized certificate and key store based on an identity (e.g., user ID) associated with a request from a guest OS.

[0013] 1A is a schematic diagram of a system 100A including integrated authentication for a container-based environment, according to one or more embodiments of the present invention. An embodiment of the system 100A may correspond to a cloud computing environment, as described below with reference to FIGS. 3 and 4, and may be implemented with any suitable computer system, such as, but not limited to, computer system 500 of FIG. 5. The system 100A includes a host system. The host system includes resources, such as address space 101, central processing unit (CPU) pool 102, data set 111, and network 112, running a host OS virtualization layer 110 (also referred to as a hypervisor). An embodiment of the host OS virtualization layer 110 may include any suitable OS, such as, but not limited to, z / OS. The host OS virtualization layer 110 supports multiple virtualized container environments 103A-N. Each virtualized container environment of the virtualized container environments 103A-N runs a guest OS, such as guest OS 106, as shown in the virtualized container environment 103A. Guest OS 106 may include any suitable OS, such as, but not limited to, Linux. As shown in container environment 103A, each of container environments 103A-N hosts a respective set of containers, such as containers 104A-N. Each of containers 104A-N may host one or more applications. Containers 104A-N are supported by container runtime environment 105. In some embodiments of the present invention, container runtime environment 105 may include Docker®. Container runtime environment 105 is hosted by guest OS 106 and guest OS virtualization layer 108. Each of container environments 103A-N may include respective instances of container runtime environment 105, guest OS 106, and guest OS virtualization layer 108, as shown in container environment 103A. Container environments 103A-N may access resources of the host system via guest OS virtualization layer 108 and host OS virtualization layer 110.

[0014] The security DB 113 may include a stored set of security artifacts (such as, but not limited to, certificates and keys) for use in authentication operations. As shown in FIG. 1A, applications hosted in containers 104A-N in container environment 103A may access security artifacts in security DB 113 via an authentication module including authentication file 107A and authentication handler 109A. Each of container environments 103A-N may include a respective authentication file, such as authentication file 107A, and authentication handler, such as authentication handler 109A, for communicating with security DB 113. Authentication operations that may be performed via authentication file 107A and authentication handler 109A in an embodiment of system 100A include, but are not limited to, TLS / SSL connections from a virtual environment Docker daemon (e.g., container runtime environment 105) to an external Docker registry, an LDAP server for user authentication, or an HTTP / HTTPS proxy server. The operation of authentication file 107A and authentication handler 109A is described further below with reference to method 200A of FIG. 2A.

[0015] In some embodiments of the present invention, the names of security artifacts in security DB 113 can be provided to container environment 103A via authentication file 107A. During provisioning of container environment 103A, the names of any security artifacts can be provided to guest OS 106. Container environment 103A can create a mapping of security artifacts from security DB 113 to one or more authentication files, such as authentication file 107A, and place one or more authentication files, such as authentication file 107A, in appropriate directory locations as placeholders. For example, in some embodiments of the present invention, for a private Docker registry, authentication file 107A can be placed under the / etc / docker / certs.d directory, for an LDAP server, authentication file 107A can be placed under / etc / ldap / ldap-ca, and for an HTTP / HTTPS proxy server, authentication file 107A can be placed under / etc / certs.d / docker-proxy-ca. When an authentication file, such as authentication file 107A, is accessed by any of containers 104A-N, authentication handler 109A may be invoked by the access to communicate locally with the underlying host OS virtualization layer 110 to request a security artifact corresponding to the access from the underlying security DB 113. Authentication file 107A may have a special predefined file extension, and the invocation of authentication handler 109A may be performed by guest OS 106 based on the predefined file extension of authentication file 107A. Authentication handler 109A may include an extended STHYI instruction that allows guest OS 106 to communicate directly with host OS virtualization layer 110 without requiring network access.The container environment 103A may run as a started task associated with a user ID on the host OS virtualization layer 110, and the authentication handler 109A may use the user ID to authenticate against the security DB 113 and obtain the requested CA certificate from the appropriate key ring. The authentication handler 109A may convert the requested certificate from the format used by the security DB 113 to any appropriate format required by the container environment 103A.

[0016] In some embodiments of the system 100A, the security artifacts in the security DB 113 may include certificates and cleartext or encrypted private keys (e.g., those used by the Integrated Cryptographic Service Facility (ICSF)) for use by server-side applications deployed in the virtual environment and applications running inside the containers 104A-N supported by the guest OS 106. In some embodiments of the system 100A, the RACF may be a security product of the underlying host OS implemented in the security DB 113 and may use a real key ring and a virtual key ring to store the certificates and private keys. A real key ring is explicitly defined and configured to include a specific certificate and private key corresponding to a user ID. A RACF virtual key ring is the set of all certificates and private keys owned by a user ID in the host environment corresponding to the host OS virtualization layer 110. The set of certificates in the RACF key ring may be used by a user or server application to determine the trustworthiness of a client or peer. Each RACF user ID can be associated with a virtual key ring. A dedicated Certificate Authority (CERTAUTH) virtual key ring can contain all trusted CA certificates in the RACF database that make up security DB 113 and can be accessed by any user ID. The certificates associated with the key ring are associated with the user ID, stored in security DB 113, and can be retrieved for application use and peer validation via authentication file 107A and authentication handler 109A.

[0017] The RACF database, from which an embodiment of the security DB 113 may be implemented, may store certificates in an internal binary format, such as privacy-enhanced mail (PEM) format and Base64 encoded X.509 certificates. The PEM and Base64 formats are text formats and may be transmitted as text by the authentication handler 109A. In some embodiments of the present invention, the authentication handler 109A may perform a conversion from extended binary coded decimal interchange code (EBCDIC) to American standard code for information exchange (ASCII) based on the type of certificate package format and the guest OS 106. The authentication handler 109A may automatically convert from the RACF binary format to any format required by the virtualized container environment 103A. The certificates may be converted by the authentication handler 109A into any appropriate format for use by the guest OS 106. Formats include, but are not limited to, PEM format, public key cryptography standards (PKCS) #12 package, or implementation-specific formats (such as, but not limited to, a Java key store or an OpenSSL key database). Authentication handler 109A can provide the certificate in the required guest OS certificate format based on the type of certificate and the virtualization environment guest OS 106.

[0018] It should be noted that the block diagram of FIG. 1A is not intended to indicate that system 100A includes all of the components shown in FIG. 1A. Rather, system 100A may have fewer suitable components than those shown in FIG. 1A, or may have suitable additional components not shown in FIG. 1A (e.g., additional memory components, embedded controllers, functional blocks, connections between functional blocks, modules, inputs, outputs, address spaces, CPUs, virtualized container environments, container runtime environments, guest OSs, guest OS virtualization layers, authentication files, authentication handlers, containers, applications, security databases, etc.). Moreover, the embodiments described herein with respect to system 100A may be implemented using any suitable logic. Logic as referred to herein may include, in various embodiments, any suitable hardware (e.g., a processor, embedded controller, or application specific integrated circuit, among others), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware.

[0019] 1B, in accordance with one or more embodiments of the present invention, a schematic diagram of a system 100B including integrated authentication for a container-based environment. An embodiment of the system 100B may correspond to a cloud computing environment, such as described below with reference to FIGS. 3 and 4, and may be implemented with any suitable computer system, such as, but not limited to, computer system 500 of FIG. 5. The system 100B includes a host system. The host system includes resources, such as address space 101, central processing unit (CPU) pool 102, data set 111, and network 112, running a host OS virtualization layer 110 (also referred to as a hypervisor). An embodiment of the host OS virtualization layer 110 may include any suitable OS, such as, but not limited to, z / OS. The host OS virtualization layer 110 supports multiple virtualized container environments 103A-N. Each of the virtualized container environments 103A-N runs a guest OS, such as guest OS 106, as shown in the virtualized container environment 103A. Guest OS 106 may include any suitable OS, such as, but not limited to, Linux. As shown in container environment 103A, each of container environments 103A-N hosts a respective set of containers, such as containers 104A-N. Each of containers 104A-N may host one or more applications. Containers 104A-N are supported by container runtime environment 105. In some embodiments of the present invention, container runtime environment 105 may include Docker. Container runtime environment 105 is hosted by guest OS 106 and guest OS virtualization layer 108. Each of container environments 103A-N may include a respective instance of container runtime environment 105, guest OS 106, and guest OS virtualization layer 108, as shown in container environment 103A. Container environments 103A-N may access resources of the host system via guest OS virtualization layer 108 and host OS virtualization layer 110.

[0020] The security DB 113 may include a stored set of security artifacts (such as, but not limited to, certificates and keys) for use in authentication operations. As shown in FIG. 1B, applications hosted in containers 104A-N in the container environment 103A may access security artifacts in the security DB 113 via an authentication module including an authentication file system 107B. The authentication file system 107B may include an authentication handler 109B. Each of the container environments 103A-N may include a respective authentication file system, such as the authentication file system 107B, including a respective authentication handler, such as the authentication handler 109B, for communicating with the security DB 113. Authentication operations that may be performed via the authentication file system 107B and the authentication handler 109B in an embodiment of the system 100B include, but are not limited to, a TLS / SSL connection from a virtual environment Docker daemon (e.g., the container runtime environment 105) to an external Docker registry, an LDAP server for user authentication, or an HTTP / HTTPS proxy server. The operation of the authentication file system 107B and the authentication handler 109B is further described below with reference to the method 200B of FIG. 2B.

[0021] In some embodiments of the present invention, the names of security artifacts in security DB 113 can be provided to container environment 103A via placeholder files in authentication file system 107B. Authentication file system 107B can include a mapping of security artifacts from security DB 113 to one or more placeholder files in authentication file system 107B. The placeholder files in authentication file system 107B can correspond to symbolic links that are mounted to appropriate locations in the normal file system of guest OS 106. For example, in some embodiments of the present invention, for a private Docker registry, a symbolic link to a placeholder file in authentication file system 107B can be included in the / etc / docker / certs.d directory. For an LDAP server, a symbolic link to a placeholder file in authentication file system 107B can be included in the / etc / ldap / ldap-ca directory. For HTTP / HTTPS proxy servers, a symbolic link to a placeholder file in the authentication file system 107B may be included in the / etc / certs.d / docker-proxy-ca directory in the normal file system of the guest OS 106. Based on the application that accesses the symbolic link to perform an authentication operation, the file access request may be redirected by the guest OS 106 to a placeholder file in the authentication file system 107B that corresponds to the symbolic link. When any placeholder file in the authentication file system 107B is accessed by any of the containers 104A-N, an authentication handler 109B in the authentication file system 107B may be invoked to communicate locally with the underlying host OS virtualization layer 110 to request a security artifact corresponding to the access from the underlying security DB 113.The authentication handler 109B may include an extended STHYI instruction that allows the guest OS 106 to communicate directly with the host OS virtualization layer 110 without requiring network access. The container environment 103A may run as a started task associated with a user ID on the host OS virtualization layer 110, and the authentication handler 109B may use the user ID to authenticate against the security DB 113 and obtain the requested CA certificate from the appropriate key ring. The authentication handler 109B may convert the requested certificate from a format used by the security DB 113 to any appropriate format required by the container environment 103A. In some embodiments of the system 100B, the authentication file system 107B may include a file system in user space (FUSE). In embodiments of the system 100B that include the authentication file system 107B, kernel modifications to the guest OS 106 may not be required. Any additional metadata that may be required in the container environment 103A may be maintained in the authentication file system 107B.

[0022] In some embodiments of the system 100B, the security artifacts in the security DB 113 may include certificates and plaintext or encrypted private keys (such as those used by ICSF) for use by server-side applications deployed in the virtual environment and applications running inside the containers 104A-N supported by the guest OS 106. In some embodiments of the system 100B, the RACF may be a security product of the underlying host OS implemented in the security DB 113 and may use real and virtual key rings for storing certificates and private keys. A real key ring is explicitly defined and configured to include a specific certificate and private key corresponding to a user ID. A RACF virtual key ring is the set of all certificates and private keys owned by a user ID in the host environment corresponding to the host OS virtualization layer 110. The set of certificates in the RACF key ring may be used by a user or server application to determine the trustworthiness of a client or peer. Each RACF user ID may be associated with a virtual key ring. A dedicated Certificate Authority (CERTAUTH) virtual key ring can contain all trusted CA certificates in the RACF database that makes up security DB 113 and can be accessed by any user ID. Certificates associated with the key ring are associated with user IDs, stored in security DB 113, and can be retrieved for application use and peer validation by authentication file system 107B and authentication handler 109B.

[0023] The RACF database, from which an embodiment of the security DB 113 may be constructed, may store certificates in an internal binary format, such as Privacy Enhanced Mail (PEM) format and Base64 encoded X.509 certificates. The PEM and Base64 formats are text formats and may be transmitted as text by the authentication handler 109B. In some embodiments of the invention, the authentication handler 109B may perform a conversion from Extended Binary Coded Decimal Interchange Code (EBCDIC) to American Standard Code for Information Interchange (ASCII) based on the type of certificate package format and the guest OS 106. The authentication handler 109B may automatically convert from the RACF binary format to any format required by the virtualized container environment 103A. Some conversions by the authentication handler 109B may require metadata stored in the authentication file system 107B or may be performed based on configuration parameters set when the authentication file system 107B is mounted. The certificates may be converted by the authentication handler 109B into any appropriate format for use by the guest OS 106. The format includes, but is not limited to, PEM format, Public Key Cryptography Standard (PKCS) #12 package, or an implementation-specific format (such as, but not limited to, a Java key store or an OpenSSL key database). The authentication handler 109B can provide the certificate in the required guest OS certificate format based on the type of certificate and the virtualization environment guest OS 106.

[0024] It should be noted that the block diagram of FIG. 1B is not intended to indicate that system 100B includes all of the components depicted in FIG. 1B. Rather, system 100B may have fewer suitable components than those depicted in FIG. 1B, or may have suitable additional components not depicted in FIG. 1B (e.g., additional memory components, embedded controllers, functional blocks, connections between functional blocks, modules, inputs, outputs, address spaces, CPUs, virtualized container environments, container runtime environments, guest OSs, guest OS virtualization layers, authentication file systems, authentication handlers, containers, applications, security databases, etc.). Moreover, the embodiments described herein with respect to system 100B may be implemented using any suitable logic. Logic as referred to herein may include, in various embodiments, any suitable hardware (e.g., a processor, embedded controller, or application specific integrated circuit, among others), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware.

[0025] FIG. 2A is a process flow diagram of a method 200A for integrated authentication for a container-based environment, according to one or more embodiments of the present invention. An embodiment of the method 200A may be implemented in the system 100A of FIG. 1A. An embodiment of the method 200A is described with reference to the system 100A of FIG. 1A. At block 201 of the method 200A, one or more authentication files, such as authentication file 107A, are provided in a predefined location within the container environment 103A. For example, for a container environment 103A including a container runtime environment including a private Docker registry, the authentication file 107A may be located under the / etc / docker / certs.d directory, for an LDAP server, the authentication file 107A may be located under / etc / ldap / ldap-ca, and for an HTTP / HTTPS proxy server, the authentication file 107A may be located under / etc / certs.d / docker-proxy-ca. An authentication file, such as authentication file 107A, may be located in any suitable location within a container environment, such as the container environment 103A. An authentication file, such as authentication file 107A, may have a predefined file extension. The predefined file extension may have any suitable format (e.g., a symbolic link, a character special, a pipe, or a socket file type). At block 202, an authentication handler 109A is provided to the container environment 103A. Providing the authentication handler 109A may include modifying the kernel of the guest OS 106.

[0026] At block 203 of the method 200A, an application in the container 104A of the container environment 103A accesses the authentication file 107A to request a security artifact for performing an authentication operation. At block 204, the access to the authentication file 107A made at block 203 invokes the authentication handler 109A. The authentication handler 109A may be invoked by the guest OS 106 based on the file extension of the accessed authentication file 107A. At block 205, the invoked authentication handler 109A passes control to the host OS virtualization layer 110 to retrieve the requested security artifact from the security DB 113. In some embodiments of the invention, the authentication handler 109A may implement a STHYI interface call to communicate with the host OS virtualization layer 110 at block 205. In some embodiments of block 205, retrieving the requested security artifact from the security DB 113 may be performed based on a user ID associated with the requesting application. At block 206, the requested security artifact is provided from security DB 113 and host OS virtualization layer 110 to the requesting application via authentication handler 109A. In some embodiments of block 206, authentication handler 109A can automatically convert the security artifact from a format used by security DB 113 to a format usable by the requesting application in container 104A. The format conversion at block 206 can be performed based on the file extension of the security artifact. Blocks 203-206 of method 200A can be repeated throughout operation of system 100A for applications operating in container environments 103A-N to access security artifacts in security DB 113.

[0027] 2A is not intended to imply that the steps of method 200A be performed in a particular order or that all of the steps of method 200A be included in any event. Additionally, method 200A may include any suitable number of additional steps.

[0028] FIG. 2B is a process flow diagram of a method 200B for integrated authentication for a container-based environment, according to one or more embodiments of the present invention. An embodiment of the method 200B may be implemented in the system 100B of FIG. 1B. An embodiment of the method 200B is described with reference to the system 100B of FIG. 1B. At block 211 of the method 200B, an authentication file system 107B is mounted to the guest OS 106 at a predefined location in the container environment 103A. The authentication file system 107B includes one or more placeholder files and an authentication handler 109B. The placeholder files may be located in any suitable location in the authentication file system 107B. The placeholder files may correspond to symbolic links located in suitable locations in the normal file system of the guest OS 106. For example, in some embodiments of the present invention, in the case of a private Docker registry, a symbolic link to a placeholder file in the authentication file system 107B may be included in the / etc / docker / certs.d directory. In the case of an LDAP server, a symbolic link to a placeholder file in authentication file system 107B may be included in the / etc / ldap / ldap-ca directory. In the case of an HTTP / HTTPS proxy server, a symbolic link to a placeholder file in authentication file system 107B may be included in the / etc / certs.d / docker-proxy-ca directory in the normal file system of guest OS 106. In some embodiments of the invention, mounting authentication file system 107B including authentication handler 109B in container environment 103A may not require modification of the kernel of guest OS 106.

[0029] At block 212 of the method 200B, an application in the container 104A of the container environment 103A accesses a placeholder file in the authentication file system 107B to request a security artifact for performing an authentication operation. To request a security artifact, the application can access a symbolic link in the normal file system of the guest OS 106, which is redirected by the guest OS 106 to a placeholder file in the authentication file system 107B that corresponds to the accessed symbolic link. At block 213, the access to the placeholder file in the authentication file system 107B made at block 212 invokes the authentication handler 109B. At block 214, the authentication handler 109B passes control to the host OS virtualization layer 110 to retrieve the requested security artifact from the security DB 113. In some embodiments of the invention, the authentication handler 109B can implement a STHYI interface call to communicate with the host OS virtualization layer 110 at block 214. In some embodiments of block 214, retrieving the requested security artifact from security DB 113 may be performed based on a user ID associated with the requesting application. At block 215, the security artifact is provided to the requesting application from security DB 113 and host OS virtualization layer 110 via authentication handler 109B. In some embodiments of block 215, authentication handler 109B may automatically convert the security artifact from a format used by security DB 113 to a format usable by the requesting application. The format conversion at block 215 may be performed based on the file extension of the security artifact.Blocks 212-215 of method 200B may be repeated throughout operation of system 100B in order for applications operating in container environments 103A-N to access security artifacts in security DB 113.

[0030] 2B is not intended to imply that the steps of method 200B be performed in a particular order or that all of the steps of method 200B be included in any event. Additionally, method 200B may include any suitable number of additional steps.

[0031] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings described herein is not limited to a cloud computing environment. Rather, embodiments of the invention may be practiced in conjunction with any other type of computing environment now known or later developed.

[0032] Cloud computing is a model of service delivery 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. The cloud model includes at least five characteristics, at least three service models, and at least four deployment models.

[0033] The characteristics are as follows:

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

[0035] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin- and thick-client platforms (e.g., cell phones, laptops, PDAs).

[0036] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Different physical and virtual resources are dynamically allocated and reallocated depending on demand. Consumers generally have no control or knowledge of the exact location of the resources provided to them, so there is a sense of location independence, although consumers may be able to determine location at a higher level of abstraction (e.g. country, state, data center).

[0037] Rapid elasticity: Computing capacity can be provisioned quickly and elastically, in some cases automatically, to scale out immediately and to be released quickly to scale in immediately. To the consumer, the computing capacity available for provisioning often appears unlimited and can be purchased at any time and in any quantity.

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

[0039] The service model is as follows:

[0040] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin-client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even the individual application functions, except for limited user-specific application configuration settings.

[0041] Platform as a Service (PaaS): The capability offered to the consumer is to deploy applications that the consumer creates or acquires 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 networks, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of the hosting environment.

[0042] Infrastructure as a Service (IaaS): The facility offered to the consumer is the provision of processors, storage, networking, and other basic computing resources on which the consumer can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, and deployed applications, and in some cases has partial control over some network components (e.g., the host firewall).

[0043] The deployment model is as follows:

[0044] Private Cloud: The cloud infrastructure is dedicated to a specific organization. It can be managed by that organization or a third party and can exist on-premise or off-premise.

[0045] Community Cloud: The cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). The cloud infrastructure can be managed by the organizations or a third party and can exist on-premise or off-premise.

[0046] Public cloud: The cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0047] Hybrid Cloud: This cloud infrastructure combines two or more cloud models (private, community or public), each of which retains its inherent semantics but is bound together by standards or specific technologies that enable data and application portability (e.g. cloud bursting for load balancing between clouds).

[0048] A cloud computing environment is a service-oriented environment with an emphasis on statelessness, low coupling, modularity and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0049] An exemplary cloud computing environment 50 is shown in FIG. 3. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, to which local computing devices used by cloud consumers (e.g., PDA or cell phone 54A, desktop computer 54B, laptop computer 54C, or automobile computer system 54N, or combinations thereof, etc.) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as, for example, a private, community, public, or hybrid cloud, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service, for which the cloud consumer does not need to maintain resources on the local computing device. It should be understood that the types of computing devices 54A-N shown in FIG. 3 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device over any type of network or network addressable connection (e.g., using a web browser), or both.

[0050] A set of functional abstraction layers provided by the cloud computing environment 50 (FIG. 3) is now illustrated in FIG. 4. It should be understood in advance that the components, layers, and functions illustrated in FIG. 4 are merely exemplary, and embodiments of the present invention are not limited thereto. As illustrated, the following layers and corresponding functions are provided:

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

[0052] The virtualization layer 70 provides an abstraction layer from which virtual entities such as, for example, virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75 can be provided.

[0053] As an example, the management layer 80 may provide the functionality described herein. Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. As an example, these resources may include application software licenses. Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables allocation and management of cloud computing resources such that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future needs for cloud computing resources according to SLAs.

[0054] The workload layer 90 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality 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 mobile desktop 96.

[0055] FIG. 5 is a schematic diagram of a computer system 500 according to one embodiment. The computer system 500 can be an electronic computer framework that includes and / or employs any number and combination of computing devices and networks utilizing various communication technologies as described herein. The computer system 500 can be modular, easily scalable and extensible, with the ability to change into different services or reconfigure some features independently of others. The computer system 500 can be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smartphone. In some examples, the computer system 500 can be a cloud computing node. The computer system 500 can be described in the general context of computer system executable instructions, such as program modules, executed by the computer system. In general, a program module may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. The computer system 500 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked via a communication network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

[0056] As shown in FIG. 5, computer system 500 has one or more central processing units (CPUs) 501a, 501b, 501c, etc. (collectively or generically referred to as processor 501). Processor 501 can be a single-core processor, a multi-core processor, a computing cluster, or any number of other configurations. Processor 501, also referred to as a processing circuit, is coupled to system memory 503 and various other components via a system bus 502. System memory 503 can include read-only memory (ROM) 504 and random access memory (RAM) 505. ROM 504 is coupled to system bus 502. ROM 504 may include a basic input / output system (BIOS) that controls certain basic functions of computer system 500. RAM is a read / write memory coupled to system bus 502 for use by processor 501. System memory 503 provides temporary memory space for the operation of the instructions described above during operation. System memory 503 can include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0057] Computer system 500 includes an input / output (I / O) adapter 506 and a communications adapter 507 coupled to a system bus 502. I / O adapter 506 may be a small computer system interface (SCSI) adapter that communicates with a hard disk 508 and / or any other similar components. I / O adapter 506 and hard disk 508 are collectively referred to herein as mass storage 510.

[0058] The software 511 executed on the computer system 500 may be stored in the mass storage 510. The mass storage 510 is an example of a tangible storage medium readable by the processor 501, and the software 511 is stored as instructions executed by the processor 501, for example, to operate the computer system 500 as described herein with reference to the various figures. Examples of computer program products and the execution of such instructions are described in more detail herein. The communications adapter 507 interconnects the system bus 502 with a network 512, which may be an external network, to enable the computer system 500 to communicate with other such systems. In one embodiment, a portion of the system memory 503 and the mass storage 510 collectively store an operating system. The operating system may be any suitable operating system for coordinating the functions of the various components illustrated in FIG. 5, such as, for example, IBM Corporation's z / OS or AIX operating systems.

[0059] Additional input / output devices are shown connected to the system bus 502 via a display adapter 515 and an interface adapter 516. In one embodiment, adapters 506, 507, 515, and 516 may be connected to one or more I / O buses that are connected to the system bus 502 via intermediate bus bridges (not shown). A display 519 (e.g., a screen or display monitor) is connected to the system bus 502 by a display adapter 515. The display adapter 515 may include a graphics controller and a video controller to improve the performance of graphics-intensive applications. A keyboard 521, a mouse 522, speakers 523, etc. may be interconnected to the system bus 502 via the interface adapter 516. The interface adapter 516 may include, for example, a super I / O chip that integrates multiple device adapters into a single integrated circuit. Suitable I / O buses for connecting peripheral devices such as hard disk controllers, network adapters, and graphics adapters typically include common protocols such as Peripheral Component Interconnect (PCI). For this reason, as configured in FIG. 5, computer system 500 includes a processing function in the form of a processor 501, a storage function including a system memory 503 and mass storage 510, input means such as a keyboard 521 and a mouse 522, and an output function including a speaker 523 and a display 519.

[0060] In some embodiments, the communications adapter 507 can transmit data using any suitable interface or protocol, such as an Internet Small Computer System Interface, among others. The network 512 may be a cellular network, a wireless network, a wide area network (WAN), a local area network (LAN), or the Internet, among others. External computing devices may be connected to the computer system 500 via the network 512. In some examples, the external computing devices may be external web servers or cloud computing nodes.

[0061] It should be noted that the block diagram of FIG. 5 is not intended to indicate that computer system 500 includes all of the components depicted in FIG. 5. Rather, computer system 500 may include fewer suitable components than those depicted in FIG. 5, or may include suitable additional components not depicted in FIG. 5 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Moreover, the embodiments described herein with respect to computer system 500 may be implemented using any suitable logic. Logic as referred to herein may include, in various embodiments, any suitable hardware (e.g., a processor, embedded controller, or application specific integrated circuit, among others), software (e.g., an application, among others), firmware, or any suitable combination of hardware, software, and firmware.

[0062] Various embodiments of the present invention are described herein with reference to the associated drawings. Alternative embodiments of the present invention may be devised without departing from the scope of the present invention. In the following description and drawings, various connections and relationships between elements (e.g., over, below, adjacent, etc.) are described. These connections and / or relationships may be direct or indirect unless otherwise specified, and the present invention is not limited in this respect. Thus, coupling of entities may refer to direct or indirect coupling, and relationships between entities may be direct or indirect. Also, various tasks and processing steps described herein may be combined into a more comprehensive procedure or process having additional steps or functions not specifically described herein.

[0063] One or more of the methods described herein may be implemented using any or a combination of the following technologies known in the art: discrete logic circuitry having logic gates for performing logical functions on data signals, application specific integrated circuits (ASICs) having appropriate combinations of logic gates, programmable gate arrays (PGAs), field programmable gate arrays (FPGAs), etc.

[0064] For the sake of brevity, prior art related to making and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of computing systems and specific computer programs for implementing various technical features described herein are well known. Thus, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or omitted entirely, and details of well-known systems and / or processes are not provided.

[0065] In some embodiments, various functions or operations may be performed at a given location, or in conjunction with the operation of one or more devices or systems, or both. In some embodiments, a portion of a given function or operation may be performed at a first device or location, and remaining portions of the function or operation may be performed at one or more additional devices or locations.

[0066] The terms used herein are for the purpose of describing particular embodiments only and are not intended to be limiting. As used herein, the singular forms "a", "an" and "the" are intended to include the plural unless the context clearly indicates otherwise. Furthermore, as used herein, the terms "comprises" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, or components or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, or groups or combinations thereof.

[0067] The corresponding structures, materials, acts, and equivalents of all means-plus-function or step-plus-function elements in the following claims are intended to include any structures, materials, or acts for performing functions in combination with other specifically claimed claim elements. The present disclosure has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the disclosed form. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the present disclosure. The present embodiment has been chosen and described in order to best explain the principles and practical applications of the present disclosure, and to enable others skilled in the art to understand the present disclosure in various embodiments with various modifications suitable for the particular use contemplated.

[0068] The drawings shown herein are exemplary. Many variations may be made to the drawings or the steps (or operations) described herein without departing from the scope of the present disclosure. For example, actions may be performed in a different order, or actions may be added, removed, or modified. Also, the term "coupled" describes having a signal path between two elements, and does not imply a direct connection between the elements with no intervening element / connection between them. All of these variations are considered part of the present disclosure.

[0069] The following definitions and abbreviations shall be used for the interpretation of the claims and the specification. As used herein, the terms "comprises," "comprising," "includes," "including," "has," "having," "contains," or "containing," or other variations thereof, are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or device that includes a list of elements is not necessarily limited to only those elements but can include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or device.

[0070] Moreover, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include any integer number greater than or equal to one, i.e., one, two, three, four, etc. The term "a plurality" is understood to include any integer number greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both indirect and direct "connections."

[0071] The terms "about," "substantially," "approximately," and variations thereof are intended to include the degree of error associated with measurement of a particular quantity based on equipment available at the time of this application. For example, "about" can include a range of ±8%, 5%, or 2% from a given value.

[0072] The present invention may be a system, method or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer readable storage medium having stored thereon computer readable program instructions for causing a processor to carry out aspects of the present invention.

[0073] A computer-readable storage medium may be a tangible device that can hold and store instructions used by an instruction execution device. The computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROM, DVD, memory sticks, floppy disks, punch cards or mechanically encoded devices with instructions recorded on ridges in grooves, and the like, and suitable combinations thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a wave guide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electric signal transmitted through a wire.

[0074] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can comprise copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing device / processing device.

[0075] The computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer readable program instructions may be executed entirely on the user's computer as a stand-alone software package, or partially on the user's computer, or partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuitry, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer readable program instructions by utilizing state information of the computer readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

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

[0077] These computer-readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, whereby these instructions, executed via the processor of such computer or other programmable data processing apparatus, create means for performing the functions / operations specified in one or more blocks in the flowcharts and / or block diagrams. These computer-readable program instructions can further be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon thereby constitutes an article of manufacture including instructions for performing the functions / operations specified in one or more blocks in the flowcharts and / or block diagrams.

[0078] Also, computer-readable program instructions may be loaded into a computer, other programmable apparatus, or other device and a sequence of operational steps executed on the computer, other programmable apparatus, or other device to generate a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0079] The flowcharts and block diagrams in the drawings 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 performing a specific logical function. In some other implementations, the functions shown in the blocks may be executed in a different order than the order shown in the figures. For example, two blocks shown in succession may actually be executed substantially simultaneously, or the blocks may be executed in reverse order depending on the functionality involved. It should be noted that each block in the block diagrams and / or flowcharts, and combinations of multiple blocks in the block diagrams and / or flowcharts, may be executed by a dedicated hardware-based system that performs a specific function or operation or executes a combination of dedicated hardware and computer instructions.

[0080] Various embodiments of the present invention have been described by way of example, but are not intended to be exhaustive or limited to these embodiments. As will be apparent to those skilled in the art, many modifications and variations are possible without departing from the scope of the described embodiments. The terms used in this specification are selected to best explain the principles of the embodiments, their practical applications, or technical improvements to the technology recognized in the market, or to allow other skilled in the art to understand the embodiments described herein.

Claims

1. accessing, by an application executing within a container within a container environment hosted by a hypervisor on a host system, an authentication module located within the container environment; invoking an authentication handler within the container environment based on the access to the authentication module; transferring control from the authentication handler to the hypervisor; retrieving, by the hypervisor, a security artifact from a security database of the host system; providing the obtained security artifact to the application via the authentication handler; performing an authentication operation by the application using the security artifact; 4. A computer-implemented method comprising:

2. The method of claim 1 , wherein the authentication module includes an authentication file accessed by the application to perform the authentication operation, the location of the authentication file in the container environment corresponding to a type of the security artifact.

3. The method of claim 2 , wherein the authentication handler is invoked based on a file extension of the authentication file.

4. 2. The method of claim 1, wherein the authentication module includes an authentication file system mounted to a guest operating system (OS) of the container environment, the authentication file system including a placeholder file accessed by the application to perform the authentication operation.

5. The method of claim 4 , wherein the placeholder file is accessed based on a symbolic link in a normal file system of the guest OS, the location of the symbolic link corresponding to a type of the security artifact.

6. The method of claim 4 , wherein the authentication handler is located within the authentication file system.

7. 2. The method of claim 1 , wherein providing the obtained security artifact to the application via the authentication handler includes converting the security artifact by the authentication handler from a first format used for storage in the security database to a second format required for use by the application.

8. a memory having computer readable instructions; and one or more processors for executing the computer readable instructions, the computer readable instructions controlling the one or more processors to: accessing, by an application executing within a container within a container environment hosted by a hypervisor on a host system, an authentication module located within the container environment; invoking an authentication handler within the container environment based on the access to the authentication module; transferring control from the authentication handler to the hypervisor; retrieving, by the hypervisor, a security artifact from a security database of the host system; providing the obtained security artifact to the application via the authentication handler; performing an authentication operation by the application using the security artifact; A system that causes a system to perform an operation including:

9. The system of claim 8 , wherein the authentication module includes an authentication file accessed by the application to perform the authentication operation, the location of the authentication file in the container environment corresponding to the type of the security artifact.

10. The system of claim 9 , wherein the authentication handler is invoked based on a file extension of the authentication file.

11. 9. The system of claim 8, wherein the authentication module includes an authentication file system mounted to a guest operating system (OS) of the container environment, the authentication file system including a placeholder file accessed by the application to perform the authentication operation.

12. 12. The system of claim 11, wherein the placeholder file is accessed based on a symbolic link in a normal file system of the guest OS, the location of the symbolic link corresponding to a type of the security artifact.

13. The system of claim 11 , wherein the authentication handler is located within the authentication file system.

14. 9. The system of claim 8, wherein providing the obtained security artifact to the application via the authentication handler includes converting the security artifact by the authentication handler from a first format used for storage in the security database to a second format required for use by the application.

15. 1. A computer program product including a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by one or more processors, the one or more processors being configured to: accessing, by an application executing within a container within a container environment hosted by a hypervisor on a host system, an authentication module located within the container environment; invoking an authentication handler within the container environment based on the access to the authentication module; transferring control from the authentication handler to the hypervisor; retrieving, by the hypervisor, a security artifact from a security database of the host system; providing the obtained security artifact to the application via the authentication handler; performing an authentication operation by the application using the security artifact; A computer program product for causing a computer to perform operations including:

16. 16. The computer program product of claim 15, wherein the authentication module includes an authentication file accessed by the application to perform the authentication operation, the location of the authentication file in the container environment corresponding to a type of the security artifact.

17. 20. The computer program product of claim 16, wherein the authentication handler is invoked based on a file extension of the authentication file.

18. 16. The computer program product of claim 15, wherein the authentication module includes an authentication file system mounted to a guest operating system (OS) of the container environment, the authentication file system including a placeholder file accessed by the application to perform the authentication operation.

19. 20. The computer program product of claim 18, wherein the placeholder file is accessed based on a symbolic link in a normal file system of the guest OS, the location of the symbolic link corresponding to a type of the security artifact.

20. 20. The computer program product of claim 18, wherein the authentication handler is located within the authentication file system.

Images