Integrated authentication for container-based environments

Abstract

Techniques for integrated authentication for container-based environments are described herein. One aspect includes an application running in a container in a container environment hosted by a hypervisor on a host system accessing an authentication module located in the container environment. Another aspect includes invoking an authentication handler in the container environment based on the access to the authentication module. Another aspect includes passing control from the authentication handler to the 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, by the application, an authentication operation using the security artifact.

Description

Background Technology

[0001] This invention relates generally to computer systems, and more specifically to integrated authentication for container-based environments.

[0002] In a cloud computing environment, computing is delivered as a service rather than a product, and shared resources, software, and information are provided to computers and other devices as metered services via networks such as the Internet. In such an environment, computing, software, data access, and storage services are provided to users who do not need to know the physical location and configuration of the system delivering the service.

[0003] A physical computer that is part of a virtualized computing environment can be referred to as a host. A virtualized computing environment, such as one implemented in a physical cloud computing node within 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 infrastructure that supports a set of virtualized container environments running on the physical computer. This common infrastructure may be referred to as a hypervisor. Each container environment may run a guest operating system and may support multiple containers. Each container may support one or more applications. Summary of the Invention

[0004] Embodiments of the present invention relate to integrated authentication for container-based environments. One non-limiting example computer-implemented method includes an application running in a container within a container environment hosted by a hypervisor on a host system accessing an authentication module located in the container environment. The method also includes invoking an authentication handler in the container environment based on access to the authentication module. The method further includes transferring control from the authentication handler to the hypervisor. The method also includes retrieving a security artifact from a security database on the host system by the hypervisor. The method further includes providing the retrieved security artifact to the application via the authentication handler. The method also includes the application using the security artifact to perform an authentication operation.

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

[0006] Additional technical features and advantages are achieved through the technology of this invention. Embodiments and aspects of the invention are described in detail herein and are considered part of the claimed subject matter. For a better understanding, refer to the detailed description and accompanying drawings. Attached Figure Description

[0007] The details of the exclusive rights described herein are specifically pointed out and explicitly claimed in the claims at the end of the specification. The foregoing and other features and advantages of embodiments of the invention will become clear from the following detailed description taken in conjunction with the accompanying drawings, in which:

[0008] Figure 1A This is a block diagram of components of a system for integrated authentication in a container-based environment according to one or more embodiments of the present invention;

[0009] Figure 1B This is a block diagram of components of a system for integrated authentication in a container-based environment according to one or more embodiments of the present invention;

[0010] Figure 2A This is a flowchart of an integrated authentication process for a container-based environment according to one or more embodiments of the present invention;

[0011] Figure 2B This is a flowchart of an integrated authentication process for a container-based environment according to one or more embodiments of the present invention;

[0012] Figure 3 A cloud computing environment according to an embodiment of the present invention is shown;

[0013] Figure 4 An abstract model layer according to an embodiment of the present invention is shown; and

[0014] Figure 5 This is a block diagram of an example computer system used in conjunction with one or more embodiments of integrated authentication for a container-based environment. Detailed Implementation

[0015] One or more embodiments of the present invention provide integrated authentication for container-based environments. To perform authentication operations in a virtualized container environment, replication of public and private certificate security artifacts (e.g., certificates and / or private keys) may be required. The replicated security artifacts can be copied to known directories and file locations within the guest OS, allowing the guest OS and the associated containers in the virtualized container environment to use these security artifacts for certificate verification and authentication. During the provisioning of the virtual environment, copies of any certificates can be injected into the virtual environment, and the virtual environment can place the certificates at appropriate directory locations. However, for cloud systems comprising multiple instances of guest OS, security artifacts may be replicated separately to each instance, which may require proactive management of the replicated security artifacts to ensure that the replicated security artifacts remain operational and current throughout the cloud system. Such security artifact management can be relatively complex, especially for virtualized container environments in the form of immutable devices.

[0016] Implementations of integrated authentication for container-based environments can directly integrate authentication operations of a virtualized container environment, including the guest OS, with the underlying host OS's security database (DB) storing security artifacts, without replicating the security artifacts within the virtualized container environment. Authentication operations may include, but are not limited to, Transport Security Layer / Secure Sockets Layer (TLS / SSL) connections, Lightweight Directory Access Protocol (LDAP) connections, and Hypertext Transfer Protocol Secure (HTTPS) proxy server connections. The guest OS and host OS can each be any suitable OS; in some embodiments of the invention, the host OS may be z / And the guest OS can be

[0017] Implementations of integrated authentication for container-based environments may include an authentication module and an authentication handler. The authentication module includes an authentication file or authentication file system. The authentication file or authentication file system may include mappings of security artifacts, including but not limited to certificates and key rings (e.g., resource access control facilities, or RACF, key rings), which serve as placeholders for any appropriate directory location in the guest OS. When an application running in a container within the virtual container environment accesses the authentication file or authentication file system, the authentication handler is invoked to communicate natively with the underlying host OS to request the security artifact corresponding to the access from the underlying host security database (DB). Multiple instances of the guest OS can access the security artifacts in the security DB via a corresponding authentication handler for each instance, making it unnecessary to provide copies of the security artifacts throughout the system. In some embodiments, the authentication handler is capable of implementing store hypervisor information (STHYI) instructions, which allow the guest OS to communicate directly with the host OS environment without network access. The virtualized container environment may run as a task initiated under a user identifier (ID) on the host environment, and the user ID can be used to authenticate with the security DB to access the requested security artifact and convert the security artifact to any format required by the virtualized container environment.

[0018] Embodiments of the present invention allow access to a secure centralized security database (including certificate and key stores), which belongs to the hypervisor (i.e., the host operating system) and is stored in the hypervisor's local storage format to be transparently accessible in real time to multiple instances of the guest OS via the guest OS's local interface, eliminating the need for statically exporting and storing keys and certificates in a format used by the guest OS. The translation and conversion of security artifacts between the hypervisor's local format and the format used by the guest OS can be performed in real time by the authentication processor, and security artifacts can be converted from any storage format used in the security database to any appropriate format required by the instance of the guest OS. The security database can be subject to access control by the hypervisor to restrict access to the centralized certificate and key store based on the identity (e.g., user ID) associated with a request from the guest OS.

[0019] Turn now Figure 1A This document outlines a system 100A, comprising integrated authentication for container-based environments, according to one or more embodiments of the present invention. Embodiments of system 100A may correspond to cloud computing environments, as described below. Figure 3 and 4 The method is under discussion and can be implemented using any suitable computer system, including but not limited to... Figure 5 Computer system 500. System 100A includes a host system that includes resources such as an address space 101, a central processing unit (CPU) pool 102, a dataset 111, and a network 112 running a host OS virtualization layer 110 (also known as a hypervisor). Embodiments of the host OS virtualization layer 110 may include any suitable OS, including but not limited to z / OS. The host OS virtualization layer 110 supports multiple virtualized container environments 103A-N. Each virtualized container environment in virtualized container environments 103A-N runs a guest OS, such as guest OS 106 as shown in virtualized container environment 103A. Guest OS 106 may include any suitable OS, including but not limited to Linux. As shown in container environment 103A, each container environment in container environments 103A-N hosts its own set of containers, such as containers 104A-N. Each container in containers 104A-N may host one or more applications. Containers 104A-N are supported by a container runtime environment 105. In some embodiments of the present invention, the container runtime environment 105 may include Container runtime environment 105 is hosted by guest OS 106 and guest OS virtualization layer 108. As shown in container environment 103A, each container environment in container environments 103A-N may include a corresponding instance of container runtime environment 105, guest OS 106, and guest OS virtualization layer 108. Container environments 103A-N can access the resources of the host system via guest OS virtualization layer 108 and host OS virtualization layer 110.

[0020] Security DB 113 may include a collection of storage for security artifacts used in authentication operations, including but not limited to certificates and keys. Figure 1A As shown, applications hosted in containers 104A-N within container environment 103A can 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 corresponding authentication file (such as authentication file 107A) and authentication handler (such as authentication handler 109A) for communicating with security DB 113. Authentication operations that can be performed via authentication file 107A and authentication handler 109A in embodiments of system 100A include, but are not limited to, connections from the virtual environment Docker daemon (e.g., container runtime environment 105) to an external Docker registry, to an LDAP server for user authentication, or to an HTTP / HTTPS proxy server. Further details are provided below regarding... Figure 2A Method 200A discusses the operation of authentication documents 107A and authentication processing procedures 109A in more detail.

[0021] In some embodiments of the invention, the name of a security artifact in a security DB 113 can be provided in a container environment 103A via authentication file 107A. During the provision of container environment 103A, the name of any security artifact can be provided to the 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 one or more authentication files (such as authentication file 107A) can be placed as placeholders in appropriate directory locations. For example, in some embodiments of the invention, for a private Docker registry, authentication file 107A can be placed in the / etc / docker / certs.d directory; for an LDAP server, authentication file 107A can be placed in / etc / ldap / ldap-ca; and for an HTTP / HTTPS proxy server, authentication file 107A can be placed in / etc / certs.d / docker-proxy-ca. When an authentication file, such as authentication file 107A, is accessed by any container 104A-N, authentication handler 109A can 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. Authentication file 107A may have predefined special file extensions, and the invocation of authentication handler 109A can be executed by guest OS 106 based on the predefined file extensions of authentication file 107A. Authentication handler 109A may include extended STHYI instructions that allow guest OS 106 to communicate directly with host OS virtualization layer 110 without requiring network access. Container environment 103A can run as a startup task on host OS virtualization layer 110 with an associated user ID, and the user ID can be used by authentication handler 109A to authenticate with security DB 113 and obtain any requested CA certificate from the appropriate keyring. The authentication processor 109A can convert the requested certificate from the format used in security DB 113 to any appropriate format required by the container environment 103A.

[0022] In some embodiments of System 100A, security artifacts in Security DB 113 may include certificates, plaintext or encrypted private keys (e.g., those used by an Integrated Cryptographic Service Facility or ICSF) for use by server-side applications deployed within a virtual environment and by applications running within containers 104A-N supported by guest OS 106. In some embodiments of System 100A, RACF may be an underlying host OS security product implemented in Security DB 113, and physical and virtual key rings may be used for certificate and private key storage. The physical key ring is explicitly defined and configured to include specific certificates and private keys corresponding to user IDs. The RACF virtual key ring is a collection of all certificates and private keys owned by a user ID in the host environment corresponding to the host OS virtualization layer 110. This set of certificates in the RACF key ring can be used by user or server applications to determine the trustworthiness of a client or peer. Each RACF user ID can be associated with a virtual key ring. A CERTAUTH virtual key ring may include all trusted CA certificates in the RACF database (including Security DB 113) and can be accessed by any user ID. The certificate associated with the key ring can be associated with the user ID, stored in the security DB 113, and retrieved via the authentication file 107A and the authentication processor 109A for application use and peer verification.

[0023] The RACF database, which may include an embodiment of the secure DB 113, can store certificates in internal binary formats, such as Privacy Enhanced Mail (PEM) format and Base64-encoded X.509 certificates. PEM and Base64 formats are text formats and can be transmitted as text by the authentication processor 109A. In some embodiments of the invention, the authentication processor 109A may perform a conversion from Extended Binary Encoded Decimal Interchange Code (EBCDIC) to American Standard Code for Message Interchange (ASCII) based on the certificate packet format type and the guest OS 106. The authentication processor 109A may automatically convert from RACF binary format to any format required by the virtualization container environment 103A. The authentication processor 109A may convert certificates to any suitable format for use in the guest OS 106, including but not limited to PEM format, Public Key Cryptography Standard (PKCS) #12 encapsulation, or implementation-specific formats (including but not limited to...). (Keystore or OpenSSL key database). The authentication processor 109A can serve certificates of any desired client OS certificate format based on the certificate type and the virtualization environment client OS 106.

[0024] It should be understood that Figure 1A The block diagram is not intended to indicate that system 100A will include Figure 1AAll components shown. Conversely, system 100A may include any suitable fewer or... Figure 1A Additional components not shown herein (e.g., additional memory components, embedded controllers, function blocks, connections between function blocks, modules, inputs, outputs, address spaces, CPUs, virtualization container environments, container runtime environments, guest OSs, guest OS virtualization layers, authentication files, authentication handlers, containers, applications, security databases, etc.). Furthermore, the embodiments described herein with respect to System 100A can be implemented with any suitable logic, wherein in different embodiments, the logic mentioned herein may include any suitable hardware (e.g., processors, embedded controllers, or application-specific integrated circuits, etc.), software (e.g., applications, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0025] Turn now Figure 1B This document broadly illustrates a system 100B including integrated authentication for container-based environments according to one or more embodiments of the present invention. Embodiments of system 100B may correspond to cloud computing environments, as described below. Figure 3 and 4 This is under discussion and can be combined with any suitable computer system (including but not limited to...). Figure 5 The system 100B is implemented using a computer system 500. System 100B includes a host system running a host OS virtualization layer 110 (also called a hypervisor), and the host system includes resources such as an address space 101, a central processing unit (CPU) pool 102, a dataset 111, and a network 112. Embodiments of the host OS virtualization layer 110 may include any suitable OS, including but not limited to z / OS. The host OS virtualization layer 110 supports multiple virtualized container environments 103A-N. Each virtualized container environment in virtualized container environments 103A-N runs a guest OS, such as guest OS 106 as shown in virtualized container environment 103A. Guest OS 106 may include any suitable OS, including but not limited to Linux. As shown in container environment 103A, each container environment in container environments 103A-N hosts its own set of containers, such as containers 104A-N. Each container in containers 104A-N may host one or more applications. Containers 104A-N are supported by a container runtime environment 105. In some embodiments of the present invention, the container runtime environment 105 may include Container runtime environment 105 is hosted by guest OS 106 and guest OS virtualization layer 108. As shown in container environment 103A, each container environment in container environments 103A-N may include a corresponding instance of container runtime environment 105, guest OS 106, and guest OS virtualization layer 108. Container environments 103A-N can access the resources of the host system via guest OS virtualization layer 108 and host OS virtualization layer 110.

[0026] Security DB 113 may include a collection of storage for security artifacts used in authentication operations, including but not limited to certificates and keys. Figure 1B As shown, applications hosted in containers 104A-N within container environment 103A can access security artifacts in secure DB 113 via an authentication module including an authentication file system 107B (including authentication handler 109B). Each of container environments 103A-N may include a corresponding authentication file system 107B (such as authentication file system 107B), which includes a corresponding authentication handler (such as authentication handler 109B) for communicating with secure DB 113. Authentication operations that can be performed via authentication file system 107B and authentication handler 109B in embodiments of system 100B include, but are not limited to, connections from the virtual environment Docker daemon (e.g., container runtime environment 105) to an external Docker registry, to an LDAP server for user authentication, or to an HTTP / HTTPS proxy server via TLS / SSL connections. The following will discuss... Figure 2B Method 200B discusses the operation of the authentication file system 107B and the authentication process 109B in more detail.

[0027] In some embodiments of the invention, the names of security artifacts in the security DB 113 may be provided in the container environment 103A via placeholder files in the authentication file system 107B. The authentication file system 107B may include a mapping of security artifacts from the security DB 113 to one or more placeholder files in the authentication file system 107B. The placeholder files in the authentication file system 107B may correspond to symbolic links at appropriate locations in the regular file system of the guest OS 106. For example, in some embodiments of the invention, for a private Docker registry, symbolic links to placeholder files in the authentication file system 107B may be included in the / etc / docker / certs.d directory; for an LDAP server, symbolic links to placeholder files in the authentication file system 107B may be included in...

[0028] The symbolic link to the placeholder file in the / etc / ldap / ldap-ca directory; and for HTTP / HTTPS proxy servers, the symbolic link to the placeholder file in the authentication file system 107B can be included in the regular file system of the guest OS 106.

[0029] In the ` / etc / certs.d / docker-proxy-ca` directory, based on application access symbolic links to perform authentication operations, file access requests can be redirected by the guest OS 106 to placeholder files corresponding to the symbolic links in the authentication file system 107B. When any placeholder file in the authentication file system 107B is accessed by any container in containers 104A-N, the authentication handler 109B in the authentication file system 107B can be invoked to communicate locally with the underlying host OS virtualization layer 110 to request the security artifact corresponding to the access from the underlying security DB 113. The authentication handler 109B may include extended STHYI instructions that allow the guest OS 106 to communicate directly with the host OS virtualization layer 110 without requiring network access. The container environment 103A can run as a startup task on the host OS virtualization layer 110 with an associated user ID, and the user ID can be used by the authentication handler 109B to authenticate with the security DB 113 and obtain any requested CA certificate from the appropriate keyring. The authentication processor 109B can convert the requested certificate from the format used in the security DB 113 into any appropriate format required by the container environment 103A. In some embodiments of system 100B, the authentication file system 107B may include a file system in user space (FUSE). Embodiments of system 100B that include the authentication file system 107B may not require any kernel changes to the guest OS 106. Any additional metadata that may be required in the container environment 103A can be maintained in the authentication file system 107B.

[0030] In some embodiments of System 100B, security artifacts in Security DB 113 may include certificates, plaintext or encrypted private keys (e.g., used by ICSF) for use by server-side applications deployed within a virtual environment and applications running within containers 104A-N supported by guest OS 106. In some embodiments of System 100B, RACF may be an underlying host OS security product implemented in Security DB 113, and physical and virtual key rings may be used for certificate and private key storage. The physical key ring is explicitly defined and configured to include specific certificates and private keys corresponding to user IDs. The RACF virtual key ring is a collection of all certificates and private keys owned by the user ID in the host environment corresponding to the host OS virtualization layer 110. This set of certificates in the RACF key ring can be used by user or server applications to determine the trustworthiness of clients or peers. Each RACF user ID can be associated with a virtual key ring. A CERTAUTH virtual key ring may include a RACF database (including Security DB).

[0031] All trusted CA certificates in 113) are accessible by any user ID. Certificates associated with the key ring can be associated with a user ID, stored in the secure DB 113, and retrieved by the authentication file system 107B and authentication processor 109B for application of usage and peer verification.

[0032] The RACF database, which may include a secure DB 113, can store certificates in internal binary formats, such as Privacy Enhanced Mail (PEM) format and Base64-encoded X.509 certificates. PEM and Base64 formats are text formats and can be transmitted as text by the authentication processor 109B. In some embodiments of the invention, the authentication processor 109B may perform a conversion from Extended Binary Encoded Decimal Exchange Code (EBCDIC) to American Standard Code for Message Exchange (ASCII) based on the certificate packet format type and the guest OS 106. The authentication processor 109B may automatically convert from RACF binary format to any format required by the virtualization container environment 103A. Some conversions performed by the authentication processor 109B may require metadata stored within the authentication file system 107B, or may be performed based on configuration parameters set during the installation of the authentication file system 107B. The authentication processor 109B may convert certificates to any suitable format for use in the guest OS 106, including but not limited to PEM format, Public Key Cryptography Standard (PKCS) #12 encapsulation, or implementation-specific formats (including but not limited to...). (Keystore or OpenSSL key database). The authentication processor 109B can serve certificates of any desired client OS certificate format based on the certificate type and the virtualization environment client OS 106.

[0033] It should be understood that Figure 1B The block diagram is not intended to indicate that system 100B includes Figure 1B All components shown. Conversely, system 100B may include any suitable fewer or... Figure 1B Additional components not shown herein (e.g., additional memory components, embedded controllers, function blocks, connections between function blocks, modules, inputs, outputs, address spaces, CPUs, virtualization container environments, container runtime environments, guest OSs, guest OS virtualization layers, authentication file systems, authentication handlers, containers, applications, security databases, etc.). Furthermore, the embodiments described herein with respect to system 100B can be implemented with any suitable logic, wherein the logic mentioned herein may include any suitable hardware (e.g., processors, embedded controllers, or application-specific integrated circuits, etc.), software (e.g., applications, etc.), firmware, or any suitable combination of hardware, software, and firmware.

[0034] Figure 2A A process flowchart of a method 200A for integrated authentication in a container-based environment according to one or more embodiments of the present invention is shown. Embodiments of method 200A may be implemented in... Figure 1A Implemented in System 100A and referenced Figure 1A System 100A is described. In box 201 of method 200A, one or more authentication files (such as authentication file 107A) are provided at a predefined location in container environment 103A. For example, for container environment 103A that includes a container runtime environment including a private Docker registry, authentication file 107A can be placed in the / etc / docker / certs.d directory; for an LDAP server, authentication file 107A can be placed under / etc / ldap / ldap-ca; for an HTTP / HTTPS proxy server, authentication file 107A can be placed under / etc / certs.d / docker-proxy-ca. Authentication files such as authentication file 107A can be placed at any appropriate location in container environment such as container environment 103A. Authentication files such as authentication file 107A may have predefined file extensions. Predefined file extensions can have any appropriate format (e.g., symbolic links, character specials, pipes, or socket file types). In box 202, authentication handler 109A is provided in container environment 103A. The provision of authentication handler 109A may include modifications to the kernel of guest OS 106.

[0035] In block 203 of method 200A, an application in container 104A within container environment 103A accesses authentication file 107A to request a security artifact to perform an authentication operation. In block 204, authentication handler 109A is invoked via the access to authentication file 107A that occurred in block 203. Authentication handler 109A may be invoked by guest OS 106 based on the file extension of the accessed authentication file 107A. In block 205, the invoked authentication handler 109A passes control to host OS virtualization layer 110 to retrieve the requested security artifact from security database 113. In some embodiments of the invention, in block 205, authentication handler 109A may implement STHYI interface calls to communicate with host OS virtualization layer 110. In some embodiments of block 205, the retrieval of the requested security artifact from security database 113 may be performed based on the user ID associated with the requesting application. In block 206, the requested security artifact is provided to the requesting application from the security database 113 and the host OS virtualization layer 110 via security handler 1109A. In some embodiments of block 206, authentication handler 109A may automatically convert the security artifact from the format used in the security database 113 to a format usable by the requesting application in container 104A. The format conversion in block 206 may be performed based on the file extension of the security artifact. Blocks 203 through 206 of method 200A may be repeated throughout the operation of system 100A to enable applications running in container environments 103A-N to access the security artifact in the security database 113.

[0036] Figure 2A The process flowchart is not intended to indicate that the operations of method 200A will be performed in any particular order, or that all operations of method 200A will be included in every case. Furthermore, method 200A may include any suitable number of additional operations.

[0037] Figure 2B A process flow diagram of a method 200B for integrated authentication in a container-based environment according to one or more embodiments of the present invention is shown. Embodiments of method 200B may be implemented in... Figure 1B Implemented in System 100B and referencing Figure 1BSystem 100B is described. In block 211 of method 200B, an authentication file system 107B is mounted to a guest OS 106 at a predetermined location in a container environment 103A. The authentication file system 107B includes one or more placeholder files and an authentication handler 109B. The placeholder files may be placed at any suitable location in the authentication file system 107B. The placeholder files may correspond to symbolic links located at suitable locations in the regular file system of the guest OS 106. For example, in some embodiments of the invention, for a private Docker registry, symbolic links to placeholder files in the authentication file system 107B may be included in the / etc / docker / certs.d directory; for an LDAP server, symbolic links to placeholder files in the authentication file system 107B may be included in...

[0038] The symbolic link to the placeholder file in the / etc / ldap / ldap-ca directory; and for HTTP / HTTPS proxy servers, the symbolic link to the placeholder file in the authentication file system 107B can be included in the regular file system of the guest OS 106.

[0039] In the directory / etc / certs.d / docker-proxy-ca. In some embodiments of the invention, installing the authentication file system 107B, which includes the authentication handler 109B, in the container environment 103A may not require modification of the guest OS 106 kernel.

[0040] In block 212 of method 200B, an application in container 104A within container environment 103A accesses a placeholder file in authentication file system 107B to request a security artifact to perform an authentication operation. The application can access symbolic links in the guest OS 106's regular file system to request the security artifact, and accesses placeholder files that are redirected by guest OS 106 to the symbolic links accessed in authentication file system 107B. In block 213, authentication handler 109B is invoked by accessing the placeholder file in authentication file system 107B that occurred in block 212. In block 214, authentication handler 109B passes control to host OS virtualization layer 110 to retrieve the requested security artifact from security database 113. In some embodiments of the invention, in block 214, authentication handler 109B may implement STHYI interface calls to communicate with host OS virtualization layer 110. In some embodiments of block 214, the retrieval of the requested security artifact from security database 113 may be performed based on a user ID associated with the requesting application. In block 215, a security artifact is provided to the requesting application from the security database 113 and the host OS virtualization layer 110 via security processor 1109B. In some embodiments of block 215, authentication processor 109B may automatically convert the security artifact from a format used in the security database 113 to a format usable by the requesting application. The format conversion in block 215 may be performed based on the file extension of the security artifact. Blocks 212 through 215 of method 200B may be repeated throughout the operation of system 100B to enable applications running in container environments 103A-N to access the security artifact in the security database 113.

[0041] Figure 2B The process flow diagram is not intended to indicate that the operations of method 200B will be performed in any particular order, or that all operations of method 200B will be included in every case. Furthermore, method 200B may include any suitable number of additional operations.

[0042] It should be understood that while this disclosure includes a detailed description of cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Rather, embodiments of the invention can be implemented in conjunction with any other type of computing environment now known or developed hereafter.

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

[0044] The features are as follows:

[0045] On-demand self-service: Cloud consumers can unilaterally and automatically provide computing power, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0046] Extensive network access: Capabilities are available through networks and accessed via standard mechanisms that facilitate the use of heterogeneous thin client or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0047] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence because consumers typically do not have control or knowledge of the exact location of the resources provided, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0048] Rapid flexibility: The ability to provide capacity quickly and flexibly, automatically scaling down and up rapidly in some situations to scale up rapidly. For consumers, the available supply capacity often appears unlimited and can be purchased in any quantity at any time.

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

[0050] The service model is as follows:

[0051] Software as a Service (SaaS): This provides consumers with the ability to use the provider's applications running on cloud infrastructure. The applications can be accessed from different client devices via a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including the network, servers, operating system, storage, or even individual application capabilities, with possible exceptions such as limited user-specific application configuration settings.

[0052] Platform as a Service (PaaS): This provides consumers with the ability to deploy applications created or acquired by the consumer using programming languages ​​and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but they have control over the deployed applications and the configuration of any application hosting environment.

[0053] Infrastructure as a Service (IaaS): This provides consumers with the capability to deliver processing, storage, networking, and other basic computing resources that enable them to deploy and run arbitrary software, which may include operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0054] The deployment model is as follows:

[0055] Private cloud: A cloud infrastructure that operates solely for an organization. It can be managed by the organization or a third party and can exist on-site or off-site.

[0056] Community cloud: A cloud infrastructure shared by several organizations and supporting a specific community with shared concerns (e.g., tasks, security requirements, policies, and compliance considerations). It can be managed by an organization or a third party and can exist on-site or off-site.

[0057] Public cloud: Makes cloud infrastructure available to the public or large industry groups and is owned by an organization that sells cloud services.

[0058] Hybrid cloud: A cloud infrastructure is a combination of two or more clouds (private, community, or public) that remain a single entity but are bound together by standardized or proprietary technologies that enable data and applications to be ported (e.g., cloud bursting for load balancing between clouds).

[0059] Cloud computing environments are service-oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure comprising a network of interconnected nodes.

[0060] See now Figure 3 This describes an illustrative cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 to which local computing devices used by cloud consumers can communicate. These local computing devices include, for example, personal digital assistants (PDAs) or cellular phones 54A, desktop computers 54B, laptop computers 54C, and / or automotive computer systems 54N. The nodes 10 can communicate with each other. They can be physically or virtually grouped (not shown) in one or more networks, such as private clouds, community clouds, public clouds, or hybrid clouds, or combinations thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platforms, and / or software as services that cloud consumers do not need to maintain on their local computing devices. It should be understood that... Figure 3 The types of computing devices 54A-N shown are intended to be illustrative only, and computing node 10 and cloud computing environment 50 can communicate with any type of computerized device via any type of network and / or network-addressable connectivity (e.g., using a web browser).

[0061] Now for reference Figure 4 This illustrates a set of functional abstraction layers provided by the cloud computing environment 50 (Figure 1). It should be understood beforehand that... Figure 4 The components, layers, and functions shown are intended to be illustrative only, and embodiments of the invention are not limited thereto. As described, the following layers and corresponding functions are provided:

[0062] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: a mainframe 61; a RISC (Reduced Instruction Set Computer) based server 62; a server 63; a blade server 64; a storage device 65; and network and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0063] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual server 71; virtual storage 72; virtual network 73, including virtual private network; virtual application and operating system 74; and virtual client 75.

[0064] In one example, management layer 80 can provide the functionality described herein. Resource provisioning 81 provides dynamic procurement of computing resources and other resources used to perform 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 authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud resource allocation and management to ensure that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-scheduling and procurement of cloud resources based on anticipated future needs according to the SLA.

[0065] Workload tier 90 provides examples of functionalities that can leverage a cloud computing environment. Examples of workloads and functionalities that can be provided from this tier include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics and processing 94; transaction processing 95; and mobile desktop 96.

[0066] Turn now Figure 5A computer system 500 is generally illustrated according to an embodiment. As described herein, 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 different communication technologies. The computer system 500 can be easily expanded, scalable, and modular, with the ability to be changed to different services or reconfigured to some features independently of others. The computer system 500 can be, for example, a server, desktop computer, laptop computer, tablet computer, or 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. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. The computer system 500 can be practiced 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 can reside in local and remote computer system storage media, including memory storage devices.

[0067] like Figure 5 As shown, the computer system 500 has one or more central processing units (CPUs) 501a, 501b, 501c, etc. (collectively or commonly 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 processing circuitry) is coupled to system memory 503 and various other components via system bus 502. System memory 503 may include read-only memory (ROM) 504 and random access memory (RAM) 505. ROM 504 is coupled to system bus 502 and 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 instructions during operation. System memory 503 may include random access memory (RAM), read-only memory, flash memory, or any other suitable memory system.

[0068] Computer system 500 includes an input / output (I / O) adapter 506 and a communication 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 component. I / O adapter 506 and hard disk 508 are collectively referred to herein as mass storage 510.

[0069] Software 511 executing on computer system 500 may be stored in mass storage 510. Mass storage 510 is an example of a tangible storage medium readable by processor 501, wherein, as described herein with respect to the various figures, software 511 is stored as instructions to be executed by processor 501 to operate computer system 500. Examples of computer program products and the execution of such instructions are discussed in more detail herein. Communication adapter 507 interconnects system bus 502 with network 512, which may be an external network enabling computer system 500 to communicate with other such systems. In one embodiment, a portion of system memory 503 and mass storage 510 jointly stores an operating system, which can be any suitable operating system, such as z / OS or AIX from IBM, for coordination. Figure 5 The functions of the different components shown.

[0070] Additional input / output devices are shown connected to the system bus 502 via display adapter 515 and interface adapter 516. In one embodiment, adapters 506, 507, 515, and 516 may be connected to one or more I / O buses connected to the system bus 502 via an intermediate bus bridge (not shown). A display 519 (e.g., a screen or display monitor) is connected to the system bus 502 via display adapter 515, which may include a graphics controller to improve performance in graphics-intensive applications, and a video controller. Keyboard 521, mouse 522, speakers 523, etc., may interconnect with the system bus 502 via interface adapter 516, which may include, for example, a super I / O chip integrating 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). Therefore, as Figure 5 The computer system 500 configured therein includes processing capabilities in the form of a processor 501, storage capabilities including system memory 503 and mass storage 510, input devices such as a keyboard 521 and a mouse 522, and output capabilities including a speaker 523 and a display 519.

[0071] In some embodiments, the communication adapter 507 may use any suitable interface or protocol (such as an Internet Small Computer System Interface) to send data. The network 512 may be a cellular network, radio network, wide area network (WAN), local area network (LAN), or the Internet. External computing devices may be connected to the computer system 500 via the network 512. In some examples, the external computing device may be an external network server or a cloud computing node.

[0072] It should be understood that Figure 5The block diagram is not intended to indicate that the computer system 500 will include Figure 5 All components shown. Conversely, computer system 500 may include any suitable fewer or... Figure 5 Additional components not shown (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Furthermore, the embodiments described herein with respect to computer system 500 can be implemented with any suitable logic, wherein the logic mentioned herein may include any suitable hardware (e.g., processor, embedded controller, or application-specific integrated circuit, etc.), software (e.g., applications, etc.), firmware, or any suitable combination of hardware, software, and firmware in different embodiments.

[0073] Various embodiments of the invention are described herein with reference to the accompanying drawings. Alternative embodiments of the invention may be devised without departing from its scope. In the following description and drawings, various connections and positional relationships (e.g., above, below, adjacent, etc.) are illustrated between elements. Unless otherwise specified, these connections and / or positional relationships may be direct or indirect, and the invention is not intended to be limiting in this respect. Therefore, the connection of entities may refer to direct or indirect connections, and the positional relationship between entities may be direct or indirect positional relationships. Furthermore, the various tasks and process steps described herein may be incorporated into a more comprehensive procedure or process with additional steps or functions not described in detail herein.

[0074] One or more methods described herein can be implemented using any of the following techniques or combinations thereof, each of which is well known in the art: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having appropriately combined logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0075] For the sake of brevity, conventional techniques relating to the manufacture and use of the present invention may or may not be described in detail herein. Specifically, various aspects of the computing systems and specific computer programs used to implement the different technical features described herein are well known. Consequently, for the sake of brevity, many conventional implementation details are only briefly mentioned or omitted entirely herein, without providing well-known system and / or process details.

[0076] In some embodiments, various functions or actions may occur at a given location and / or in conjunction with the operation of one or more devices or systems. In some embodiments, a portion of a given function or action may be performed at a first device or location, and the remainder of the function or action may be performed at one or more additional devices or locations.

[0077] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, unless the context clearly indicates otherwise, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well. It should also be understood that when the terms “comprises” and / or “comprising” are used in this specification, they specify the presence of the stated features, integrals, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or combinations thereof.

[0078] All means or steps in the following claims, plus corresponding structures, materials, actions, and equivalents of the functional elements, are intended to include any structure, material, or action for performing the function in conjunction with other claimed elements as specifically claimed. This disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the forms disclosed. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of this disclosure. These embodiments were chosen and described in order to best explain the principles and practical application of this disclosure, and to enable others skilled in the art to understand this disclosure with respect to different embodiments having different modifications suitable for the particular intended use.

[0079] The diagrams depicted herein are illustrative. Many variations may be made to the diagrams or steps (or operations) described herein without departing from the scope of this disclosure. For example, actions may be performed in a different order, or actions may be added, deleted, or modified. Furthermore, the term "coupled" describes a signal path between two elements and does not imply a direct connection between elements without intermediate elements / connections. All such variations are considered part of this disclosure.

[0080] The following definitions and abbreviations will be used to interpret the claims and description. As used herein, the terms “comprises,” “comprising,” “includes,” “including,” “has,” “having,” “contains,” or “containing,” or any other variations thereof, are intended to cover non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus.

[0081] Furthermore, the term "exemplary" is used herein to mean "used as an example, illustration, or illustration." Any implementation or design described herein as "exemplary" is not necessarily to be construed as superior to or better than other embodiments or designs. The terms "at least one" and "one or more" should be understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "multiple" should be understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connection" can include both indirect "connection" and direct "connection."

[0082] The terms “about,” “substantially,” “roughly,” and their variations are intended to include the degree of error associated with a measurement based on a specific quantity of equipment available at the time of application submission. For example, “about” could include a range of ±8%, 5%, or 2% of a given value.

[0083] This invention can be a system, method, and / or computer program product with any possible level of technical detail integration. The computer program product may include a computer-readable storage medium having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0084] Computer-readable storage media can be tangible means for retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer disks, 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 universal disk (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or protrusions in slots having instructions recorded thereon, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses passing through fiber optic cables), or electrical signals transmitted through wires.

[0085] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or to an external computer or external storage device. The network may include copper cables, optical fibers, 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 forwards them to a computer-readable storage medium within the suitable computing / processing device.

[0086] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including 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 may be executed entirely on a user's computer, partially on a user's computer, as a standalone software package, partially on a 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 local area network (LAN) or a wide area network (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), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry in order to perform aspects of this invention.

[0087] The present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should 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.

[0088] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium storing the instructions comprises an article of manufacture containing instructions that implement aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0089] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, such that the instructions executed on the computer, other programmable apparatus, or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0090] The flowcharts and block diagrams in the accompanying 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. Each block in a flowchart or block diagram 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 marked in the blocks may occur in a different order than indicated in the figures. For example, depending on the functions involved, two consecutively shown blocks may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0091] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements over those found in the market, or to enable those skilled in the art to understand the embodiments described herein.

Claims

1. A computer implementation method, comprising: Applications running in containers within a container environment hosted by a hypervisor on a host system access an authentication module located in the container environment, wherein the authentication module includes an authentication file system of the guest operating system (OS) installed in the container environment. The authentication process in the container environment is invoked based on access to the authentication module; Control is transferred from the authentication process to the management process; The management program retrieves security artifacts from the security database of the host system. The retrieved security artifact is provided to the application via the authentication process; as well as The application uses the security artifact to perform the authentication operation. The authentication file system includes placeholder files accessed by the application via symbolic links in the guest operating system's regular file system to perform the authentication operation. The authentication file system also includes a mapping from security artifacts stored in the security database to placeholder files stored in the authentication file system.

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

3. The method according to claim 2, wherein, The authentication process is invoked based on the file extension of the authentication file.

4. The method according to claim 1, wherein, The location of the symbolic link corresponds to the type of the security artifact.

5. The method according to claim 1, wherein, The authentication processing program is located in the authentication file system.

6. The method according to claim 1, wherein, Providing the retrieved security artifact to the application via the authentication process includes: the authentication process converting the security artifact from a first format intended for storage in the security database into a second format required by the application.

7. A system comprising: Memory, containing computer-readable instructions; as well as One or more processors for executing the computer-readable instructions, the computer-readable instructions controlling the one or more processors to perform operations, the operations including: Applications running in containers within a container environment hosted by a hypervisor on a host system access an authentication module located in the container environment, wherein the authentication module includes an authentication file system of the guest operating system (OS) installed in the container environment. The authentication process in the container environment is invoked based on access to the authentication module; Control is transferred from the authentication process to the management process; The management program retrieves security artifacts from the security database of the host system. The retrieved security artifact is provided to the application via the authentication process; and The application uses the security artifact to perform the authentication operation. The authentication file system includes placeholder files accessed by the application via symbolic links in the guest operating system's regular file system to perform the authentication operation. The authentication file system also includes a mapping from security artifacts stored in the security database to placeholder files stored in the authentication file system.

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

9. The system according to claim 8, wherein, The authentication process is invoked based on the file extension of the authentication file.

10. The system according to claim 7, wherein, The location of the symbolic link corresponds to the type of the security artifact.

11. The system according to claim 7, wherein, The authentication processing program is located in the authentication file system.

12. The system according to claim 7, wherein, Providing the retrieved security artifact to the application via the authentication process includes: the authentication process converting the security artifact from a first format intended for storage in the security database into a second format required by the application.

13. A computer program product comprising program instructions executable by one or more processors to cause the one or more processors to perform operations, the operations including: Applications running in containers within a container environment hosted by a hypervisor on a host system access an authentication module located in the container environment, wherein the authentication module includes an authentication file system of the guest operating system (OS) installed in the container environment. The authentication process in the container environment is invoked based on access to the authentication module; Control is transferred from the authentication process to the management process; The management program retrieves security artifacts from the security database of the host system. The retrieved security artifact is provided to the application via the authentication process; as well as The application uses the security artifact to perform the authentication operation. The authentication file system includes placeholder files accessed by the application via symbolic links in the guest operating system's regular file system to perform the authentication operation. The authentication file system also includes a mapping from security artifacts stored in the security database to placeholder files stored in the authentication file system.

14. The computer program product according to claim 13, wherein, The authentication module includes an authentication file that is accessed by the application to perform the authentication operation, wherein the location of the authentication file in the container environment corresponds to the type of the security artifact.

15. The computer program product according to claim 14, wherein, The authentication process is invoked based on the file extension of the authentication file.

16. The computer program product according to claim 13, wherein, The location of the symbolic link corresponds to the type of the security artifact.

17. The computer program product according to claim 13, wherein, The authentication processing program is located in the authentication file system.

Images