Selective provision of mutual transport shift security by means of alternative server names

Abstract

System that has a hardware processor (602) configured to: In response to the detection of a legacy indicator, generate an alternative server name and assign the alternative server name to a pod address; and to configure a proxy (116) associated with the pod so that it selectively provides mutual transport layer security (mTLS) based on the alternative server name, wherein the system includes an extension application programming interface (API) server to receive a workload, invoke an extension point with the received workload, and receive a modified deployment descriptor that includes at least one uniform resource locator (URL) that uses the alternate server name; and where the legacy indicator is an indicator that a particular connection should not use mTLS.

Description

BACKGROUND

[0001] The methods presented here relate to mutual transport layer security (mTLS). Specifically, the methods involve the selective deployment of mTLS using alternative server names.

[0002] US 10 623 390 B1 discloses a cloud platform architecture in which access addresses of a service are replaced by a local address of a sidecar program associated with an application, so that the application communicates with the service via the sidecar program. SUMMARY

[0003] According to one embodiment described herein, a system can include a processor to generate an alternate server name in response to the detection of a legacy indicator and to assign the alternate server name to the address of a pod. The processor can also further configure a proxy associated with the pod to selectively provide mutual transport layer security (mTLS) based on the alternate server name.

[0004] According to another embodiment described herein, a method may include detecting a legacy indicator via a processor. The method may further include modifying a pod's Uniform Resource Location (URL) via the processor to use an alternate server name. The method may also further include configuring a proxy associated with the pod to disable mutual Transport Layer Security (mTLS) in response to receiving the alternate server name.

[0005] According to a further embodiment described herein, a computer program product for selectively providing mutual transport layer security (mTLS) may comprise a computer-readable storage medium containing program code. The computer-readable storage medium is not a transient signal per se. The program code is executable by a processor to cause the processor to monitor a plurality of manifests for a plurality of legacy indicators. The program code may also cause the processor to detect a legacy indicator associated with at least one legacy client in at least one of the plurality of manifests. Furthermore, the program code may cause the processor to generate an alternative server name in response to the detection of the legacy indicator.The program code can also instruct the processor to assign the alternate server name to a pod's address. Furthermore, the program code can instruct the processor to configure a proxy associated with the pod to disable a service in response to receiving a server name indicator containing the alternate server name from a legacy client. Brief description of the different views of the drawings

[0006] Embodiments of the invention are now described only by way of example with reference to the accompanying drawings, wherein: Fig. 1 is a block diagram of an exemplary system for selectively deploying mTLS using alternative server names; Fig. 2 is a block diagram of an exemplary procedure that can selectively provide mTLS using alternative server names; Fig. 3 is a block diagram of an exemplary data processing unit that can selectively provide mTLS using alternative server names; Fig. 4 is a process flow diagram of an exemplary cloud computing environment according to the embodiments described herein; Fig. 5 a process flow diagram of exemplary abstraction model layers according to the embodiments described herein; and Fig. 6 is an example of a physical, non-transient, computer-readable medium that can selectively provide mTLS by means of alternative server names. DETAILED DESCRIPTION

[0007] Microservice-based applications can consist of multiple services, referred to here as microservices, that interact via a network protocol. This network protocol can be, for example, Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), or a Remote Procedure Call (RPC) system. In some examples, a microservice system may employ a service network. A service network can contain components that indirectly exchange data through intermediary proxies. These proxies can be used to simplify data exchange and can also improve the stability and security of data exchange. As long as the data exchange between the services of a microservice-based application uses proxies, the proxies can fulfill all requirements without directly affecting the microservice code.One example of a prerequisite is a handshake within the framework of mutual transport layer security (mTLS). Mutual TLS, or mTLS, refers here to a method for performing mutual authorization checks between clients and servers. For example, a server can initiate an authorization check against a client by sending the client a certificate. The certificate can be signed by a trusted certificate authority and contain the name of a server. The name can include a primary name and an alternate name. The certificate can also contain a public key.The public key can be used by clients to encrypt a random value, which is then decrypted by a server using a private key corresponding to the public key and sent back to the client as proof of the server's identity. The client can then similarly prove its authorization to the server by decrypting a value received from the server that is encrypted using a public key corresponding to the client's private key.

[0008] In service network environments, requests not initiated by a proxy, such as those from a legacy client, can also be intercepted and redirected to a proxy. The term "legacy client" here refers to clients that are not configured to use a specific requirement, such as mTLS. Requests initiated by legacy clients can include requests related to health checks, access to metrics, status, introspection, and data debugging. A health check might include an activity check or a readiness check. Because the proxy might not know the client's identity, it may initiate an mTLS exchange. However, the resulting client certificate request to begin the client's authorization check might be unexpected for the legacy client, potentially leading to the termination of the connection.In some examples, a legacy client can perform a health check, such as an activity check or a readiness check. For example, the legacy client can be used to check the activity or readiness of an application instance in a pod. Activity, in this context, refers to whether an application instance is active. For instance, if an activity check determines that an application instance is inactive, an orchestrator can restart the application instance. An orchestrator, in this context, refers to a container management tool that automates the provisioning of a containerized infrastructure and provides load balancing for the services created with containers. Readiness, in this context, refers to whether an application instance is ready to serve traffic.For example, an application instance might be active but unavailable to handle traffic because one or more dependencies are not ready. In this context, a pod refers to a group of one or more processes, potentially running in a containerized environment, with shared storage and networking, and a predefined operating environment for the container(s). A pod can thus be used to model an application-specific logical host. For instance, the container(s) within the pod can share an IP address and port range and discover each other via localhost. Each port can be assigned a separate IP address so that application instances can use ports without conflicts.A pod can be used to define a storage medium, such as a local disk directory or a network disk, and expose that medium to one or more containers within the pod. Applications within a pod can access shared storage media that may be defined as part of the pod and made available for mounting into each application's file system. Pods can be managed manually via an orchestrator or via a control unit such as an access control unit.

[0009] According to embodiments of the present disclosure, a system can selectively provide mTLS using alternative server names. The system may include an alternative name generator to create an alternative server name in response to the detection of a legacy client and to associate the alternative server name with the address of a pod. The system may also include a proxy configurator to configure a proxy associated with the pod to disable a service in response to receiving a server name indicator containing the alternative server name.

[0010] The methods described here enable the use of legacy clients in service network systems that use mTLS. Furthermore, these methods are transparent to application instances and require no code changes in applications or clients. They can be used to separate mTLS and non-mTLS clients into different logical servers without affecting or modifying client code.

[0011] In some scenarios, the methods described here can be implemented in a cloud computing environment. As shown below, with reference to at least the Fig. 3, Fig. 4 to Fig. As discussed in more detail in Section 5, a data processing unit configured to selectively provide mTLS using alternative server names can be implemented in a cloud computing environment. It should be noted beforehand that, although this disclosure may contain a description of cloud computing, implementations of the teaching set forth herein are not limited to a cloud computing environment. Instead, embodiments of the present invention can be implemented together with any type of data processing environment, now known or subsequently invented.

[0012] Cloud computing is a service delivery model that enables seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, main memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management overhead or interaction with a service provider. This cloud model can include at least five properties, at least three service models, and at least four implementation models.

[0013] The properties are as follows: On-Demand Self-Service: A cloud user can unilaterally and automatically provide data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider. Broad Network Access: Functions are available over a network, accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: The provider's data processing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources being dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control over or knowledge of the exact location of the provided resources, but may be able to define a location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling (scale out), in some cases automatically, and released quickly for rapid scale-in. To the user, the available features often appear unlimited and can be purchased in any quantity at any time. Measured Service: Cloud systems automatically control and optimize resource usage by employing a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource utilization can be monitored, controlled, and reported, thereby creating transparency for both the provider and the user of the service.

[0014] The service models are as follows: Software as a Service (SaaS): The functionality provided to the user consists of using the provider's applications running in a cloud infrastructure. These applications are accessible from various client devices via a thin-client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The function provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, within the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and potentially over configurations of the application hosting environment. Infrastructure as a Service (IaaS): The functionality provided to the user consists of supplying processing, storage, networking, and other basic data processing resources, enabling the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and potentially limited control over selected network components (e.g., host firewalls).

[0015] The following are the deployment models: Private Cloud: The cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can be located on the organization's own premises or on external premises. Community Cloud: This cloud infrastructure is shared by multiple organizations and supports a specific user community with shared concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). It can be managed by the organizations themselves or a third party and can be located on-premises or external premises. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community or public) that remain separate entities but are connected by a standardized or proprietary technology that enables data and application portability (e.g. cloud audience distribution for load balancing between clouds).

[0016] A cloud computing environment is service-oriented, focusing on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure comprising a network of interconnected nodes.

[0017] According to Fig. Figure 1 shows a block diagram of an example system for selectively deploying mTLS using alternative server names. This example system is generally referred to as 100. System 100 could, for example, be a service network system. System 100 consists of Fig. System 100 comprises a client 102 that is in a data transmission connection with an orchestrator 104. The client can be, for example, a user, a program, or an automated agent such as an automated deployment pipeline. In this context, an orchestrator is a system for workload planning or orchestration. System 100 also comprises a registration agent 106 that is in a data transmission connection with the orchestrator 104. System 100 includes an alternative name registration (HC-APP). B) 108, which can be registered by the registration agent 106 with a service register 110. Accordingly, the registration agent 106 is also in a data transmission connection with the service register 110. The service register 110 is furthermore in a data transmission connection with a first application instance 112. The first application instance 112 is in a data transmission connection with a corresponding first sidecar proxy 114. In this context, a sidecar proxy is a proxy that belongs to a specific application instance in order to provide the application instance with one or more services of a service network. The first sidecar proxy 114 is in a data transmission connection with a second sidecar proxy 116. The service register 110 and the second sidecar proxy 116 are in a data transmission connection with an agent 118 using transport layer security (TLS).TLS, in this context, refers to a method for a client to perform an authorization check on a server with which it exchanges data. For example, agent 118 might belong to an orchestrator and can ensure that a workload scheduled for a specific endpoint or node is functioning correctly. For instance, the agent can check the status of various currently running application instances and services by pinging their state endpoints. Agent 118 might be a legacy client not configured to perform mTLS. Furthermore, the second sidecar proxy, 116, is in a data transmission connection with a second application instance, 120, corresponding to the second sidecar proxy, 116. In some examples, sidecar proxies 114 and 116 might be configured to perform mTLS. Sidecar proxies 114 and 116 can together form a service network.Sidecar proxies 114 and 116 can therefore be assigned one or more functions from application instances 112 and 120, respectively. In addition to other functions such as reporting and logging, sidecar proxies 114 and 116 can, for example, determine how to load balance requests, how to handle outages, and how to consistently disclose request metrics. Sidecar proxies 114 and 116 include corresponding endpoints 122 and 124. Endpoints 122 and 124 can be, for example, HTTP or HTTPS endpoints. Each endpoint 122 and 124 can have one or more names or identities. Each endpoint 122 or 124 can have multiple identities associated with different purposes. For example, one name might be associated with activity checks and another with readiness checks.As described in more detail below, one of the names may be an alternate server name that can be used to bypass mTLS during a health check. Endpoints 122 and 124 may also contain proof of the names or identities in the form of a certificate used for authorization verification.

[0018] In the example of the Fig. 1. A client 102 can send a request to the orchestrator 104 to provision a second application instance 120, as indicated by an arrow 126. In some examples, the request can be in the form of a manifest. A manifest is a file that, among other information, can specify a name, ports to open, labels to use, the application image to run, and the number of instances to run. The orchestrator 104 can use the manifest to schedule, run, and manage one or more instances of an application. A user can configure a manifest for each workload to be managed. In some examples, the manifest can also contain information about how to perform health checks on a workload.For example, the manifest can specify activity checks and readiness checks using alternative server names, as shown in the example procedure below. Fig. 2. The orchestrator 104 can send a set of provisioning notifications to the registration agent 106, as shown by arrow 128. The registration agent 106 can send an alternate server name 108, corresponding to a health check (HC) for the second application instance 120, to the service register 110, as indicated by arrows 130 and 132. For example, the registration agent 106 can generate the alternate server name and register the alternate server name based on a manifest that specifies the alternate server name to be registered for a particular service. In the example from Fig. 1. The alternative server name generated for a status check of the second application instance 120 is HC-APP. B In some examples, the registration agent 106 can perform the alternative name registration 130 in response to a request from an extension connection point. The extension connection point could be, for example, a registration control unit, an extension API, or a control loop.

[0019] Furthermore according to Fig. 1. The first application instance 112 can have a server name corresponding to application instance 120 APP. B send to service register 110, as shown by arrow 134. The first application instance 112 can then respond with an IP address IP B received. The first sidecar proxy 114 can respond to a request for the IP address of the server named APP. BThe second application instance 120 is sent, as indicated by arrow 138. The first sidecar proxy 114 can then receive the IP address in response, as shown by arrow 140. Sidecar proxy 114 can then communicate with the second sidecar proxy 116 using the IP address IP. B Exchange data. For example, the IP address can correspond to endpoint 124 of the second sidecar 116 belonging to the second application instance 120. The sidecar proxy 114 can receive a server name indication (SNI) message from APP. BSend to indicate to the second sidecar proxy 116 that normal data exchange via mTLS should take place between the first sidecar proxy 114 and the second sidecar proxy 116. In this context, SNI is an extension of the TLS computer network protocol that allows a client to indicate at the beginning of a handshaking process which hostname it is attempting to connect to. Using SNI enables a server to present multiple certificates under the same IP address and TCP port number, so that multiple secure (HTTPS) websites (or any other service over TLS) can be served from the same IP address without all of these sites needing to use the same certificate. Therefore, if the second sidecar proxy 116 sends the SNI from APP... BIf the second sidecar proxy 116 receives a request, it can be configured to perform an authorization check with the first sidecar proxy 114 using mutual TLS. For example, the second sidecar proxy 116 can use a certificate corresponding to the respective SNI.

[0020] In contrast, data exchange between agent 118 and the second sidecar proxy 116 may not use mTLS. Agent 118 can instead use TLS to perform a health check on the second application instance 120. In some examples, the health check might be an activity check used to determine if an application instance needs to be restarted. For example, the application instance might be in a deadlock, where it is running but not progressing and therefore needs to be restarted. In some examples, the application instance might not be running and therefore needs to be restarted. The health check might also be a readiness check to determine if an application instance is ready to serve a workload.Agent 118 can therefore send a request for the IP address of the second application instance 120 and receive the corresponding IP address, as indicated by a double arrow 144. For example, the agent can access the service register 110 to retrieve the name HC-APP. B to resolve this, and in response to this an IP address IP B received. Agent 118 can then receive an SNI message from HC-APP. B Send to indicate that mTLS should not be used in data exchange with the second sidecar proxy 116, as indicated by an arrow 146. For example, the alternative name may have been specified as a state check endpoint in a YAML deployment descriptor of a manifest. The SNI message can be sent in plaintext. In response to receiving the SNI from HC-APP BThe second sidecar proxy 116 can be configured to perform only a TLS authentication check with agent 118 instead of an mTLS authentication check. In some examples, the second sidecar proxy 116 can prove its authorization to agent 118 using TLS and provide agent 118 with either an activity or readiness status. This eliminates the need to send a client certificate request to agent 118 and prevents connection drops.

[0021] It should be noted that the block diagram consists of Fig. 1 should not imply that the system 100 includes all in Fig. The system is not intended to contain the components shown in section 1. Rather, the system may contain 100 fewer or even additional components that are not shown in section 1. Fig. Figure 1 illustrates (e.g., additional client units, applications, application instances, proxies, agents, registers, types of checks, etc.). For example, the orchestrator can alternatively invoke an authorization control unit (not shown), which can be used to rewrite a provisioning descriptor and, if necessary, replace the original name with the alternative name. For example, the authorization control unit can be used to change names to alternative names for activity probes or standby probes in a pod. The authorization control unit can intercept requests to an orchestrator's API server before an object is persisted, but after the request has been checked for permission and authorized. Subsequently, the authorization control unit can examine a received manifest. The authorization control unit can detect one or more services, such as health checks, in the manifest.The admission control unit can then modify a URL associated with a health check to use an alternate server name. For example, the admission control unit can invoke one or more admission control webhooks that correspond to the request. Here, a webhook refers to any callback or callout mechanism, such as a user-defined Hypertext Transfer Protocol (HTTP) callback. In some examples, an extension API (not shown) can be used to invoke a webhook. The webhook can be used to rewrite the deployment descriptor in the manifest to change the original name to an alternate name for activity and readiness probes. The admission control unit can then send the updated deployment descriptor back to the orchestrator to create pods with health check endpoints associated with the alternate server name.In some examples, the manifest can be modified offline. For instance, the manifest can be reviewed and alternative server names added before it is sent to Orchestrator 104. In some examples, a control loop (not shown) might be a program that monitors for change notifications in objects of interest and rewrites objects in response to these notifications. For example, the control loop might monitor the shared state of a cluster via an orchestrator's application programming interface (API) server and make changes to alter the current state to a desired state. The API server can notify the orchestrator of changes such as the creation and deletion of various objects.Unlike the admission control unit, which can be called by the orchestrator, a control loop can be reactive and process events as notifications.

[0022] Fig. Figure 2 is a process flow diagram of an exemplary procedure that can selectively provide mTLS using alternative server names. Procedure 200 can be used with any suitable data processing unit, such as data processing unit 300. Fig. 3 will be implemented and will be implemented with reference to systems 100 from Fig. 1 described. For example, the procedures described below can be performed by the processor 302 of the data processing unit 300 from Fig. 3 will be implemented.

[0023] Block 202 detects a legacy indicator. In this context, a legacy indicator is an indicator that a particular connection should not use mTLS. In some examples, the legacy indicator might be a specific attribute in a deployment manifest. For instance, the manifest might specify one or more workloads to be deployed. A workload can include any service that can be provided by an application instance or service, ranging from web applications to more complex, distributed back-office processing systems. In some examples, the legacy indicator might be detected during the deployment of an application. In some examples, a deployment might include various object types, such as "ReplicaSet," "Deployment," "Pod," and so on. As described above, a Pod object can be one or more containers that perform a function.In some examples, pods can be created directly. A ReplicaSet object can be used to dynamically set the number of pods running in a cluster. For example, the number of pods can be set based on a common premise, such as an image to run, a configuration, open ports, etc. An orchestrator can be used to ensure that the object instances are running and handles failures. Deployment objects can be used to add more functionality. For example, deployment objects can be used to enable rolling updates, etc. For example, the legacy indicator during pod deployment can be detected by an approval control unit. In some examples, the legacy indicator can be detected through an extension application programming interface (API).For example, an approval control unit can be used to call a webhook and send the manifest to the webhook to validate and rewrite the manifest, as described below. In some examples, the legacy indicator can be detected via a control loop. For example, the control loop can subscribe to change notifications, and in response to the detection of a new workload, the control loop can modify a deployment descriptor of the new workload based on detected legacy indicators to conform to a desired state of using the alternate server name. In some examples, the legacy indicator can take the form of a URL in an explicit global deployment configuration that provides container identity and respective legacy URLs. For example, the container identity can include an image name and labels.In some examples, the legacy indicator might be in the form of explicitly added pod-specific metadata in labels or annotations. In some examples, the legacy indicator can be detected by running a snapshot of a deployment in a sandbox environment and testing for the presence of specific URL patterns, including legacy indicators. In some examples, the legacy indicator can be detected by analyzing available API defaults for a legacy microservice. In this case, the legacy indicator might be in the form of a predefined, specific legacy microservice.

[0024] In block 204, a pod's Uniform Resource Locator (URL) is modified to use an alternate server name. For example, an authorisation control unit (ACU) can be used to change the pod's URL in the received manifest to the alternate server name. The ACU can call an authorisation webhook and send the manifest to be reconfigured. The ACU can receive a manifest with updated URLs that use alternate server names for services such as health checks. In some examples, an alternate server name mapping to the pod can be stored in a service registry. In some examples, a collection of pods can be grouped into a service with a resolvable DNS name. If the legacy indicator detects pods using non-mTLS connections, the system can create an alternate name mapping to the same group of pods.For example, any name can be used for the alternate name. In some examples, a service name with a different DNS resolution scope can be used. For example, a health-checking namespace can be created, and under the health-checking namespace, an alternate name with an explicit reference to the original service endpoint can be created. In some examples, a specialized DNS server can be configured to resolve specially formatted alternate names such as health-checking.<ursprünglicher_dienstname> or not at all.<ursprünglicher_dienstname> dissolves, whereby<ursprünglicher_dienstname> The original name of the service, which is to be replaced by the specially formatted alternative name, can thus, as described above, the URLs can be automatically rewritten and specified in the manifest, enabling a completely transparent system modification without any user involvement.

[0025] Block 206 configures a proxy associated with the pod to disable mutual transport layer security (mTLS) upon receiving the alternate server name. This proxy could be a sidecar proxy, for example. The proxy can be configured to provide mTLS to some server names, but disable mTLS and use TLS instead upon receiving a Service Name Indication (SNI) containing the alternate server name. This allows the proxy to perform different support services for an application instance depending on the received server name. For example, a legacy client could use the alternate server name to perform a health check. This health check could be an activity check or a readiness check.The legacy client can send the alternate server name to a proxy configured to provide TLS in response to receiving the alternate server name. For example, the legacy client can send a server name indicator containing the alternate server name to the proxy.

[0026] The process flow plan of the Fig. Paragraph 2 is not intended to imply that the steps of Procedure 200 must be executed in a specific order or that all steps of Procedure 200 must be included in every case. Furthermore, Procedure 200 can include any appropriate number of additional steps. For example, other forms of legacy indicators can be used. Additionally, in some cases, the proxy can be configured to use a different, non-standard port number for non-mTLS connections, thus leaving standard ports free for use by mTLS connections. The proxy can create multiple listeners and request a separate processing pipeline for each port.Furthermore, while it is described above that modifying URLs to include alternative server names is done automatically without any user input, in some examples the system may alternatively expose the alternative name as an attribute to allow users to configure other systems to use it. This other system might be, for example, a centralized monitoring system. Additionally, in some examples the alternative name can be used to automatically reconfigure other system components. For instance, if an original service name is exposed by an Ingress resource, the system can create an additional Ingress definition that maps the health check URL to the alternative service name.The Ingress resource can be made specific to the health check URL and the original service name, thereby changing only this mapping to the alternate internal service name and leaving the other URLs mapped to the original internal service name.

[0027] Fig. Figure 3 is a block diagram of an example data processing unit (DPU) that can selectively provide mTLS using alternative server names. DPU 300 could be, for example, a server, a desktop computer, a laptop computer, a tablet computer, or a smartphone. In some examples, DPU 300 might be a cloud computing node. In a general context, DPU 300 can be described by a computer system's executable instructions, such as program modules that are executed by a computer system. Generally, program modules contain routines, programs, objects, components, logic, data structures, and so on, that perform specific tasks or implement certain abstract data types.The Data Processing Unit 300 can be operated in distributed cloud computing environments where tasks are performed by remotely located processing units connected by a communication network. In a distributed cloud computing environment, program modules can reside in both local and remote storage media of the computer system, including short-term storage units.

[0028] The data processing unit 300 can include a processor 302, which is designed to execute stored instructions, and a memory unit 304 to provide temporary storage space for instruction steps during operation. The processor can be a single-core processor, a multi-core processor, a data processing cluster, or any number of other configurations. The memory 304 can include random-access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0029] The processor 302 can be connected via a system connection 306 (e.g., PCI®, PCI-Express®, etc.) to an input / output (I / O) interface 308, which is configured to connect the data processing unit 300 to one or more I / O units 310. The I / O units 310 may include, for example, a keyboard and a pointing device, the pointing device being, among other things, a touchpad or a touch-sensitive screen. The I / O units 310 may be built-in components of the data processing unit 300 or units connected externally to the data processing unit 300.

[0030] The processor 302 can also be connected via the system connection 306 to a display interface 312, which is configured to connect the data connection unit 300 to a display unit 314. The display unit 314 can include a display screen, which is a built-in component of the data processing unit 300. The display unit 314 can also include, among other things, a computer monitor, television, or projector that is externally connected to the data processing unit 300. Furthermore, a network interface controller (NIC) 316 can be configured to connect the data processing unit 300 to the network 318 via the system connection 306. In some embodiments, the NIC 316 can transmit data using any suitable interface or protocol, including, for example, the Internet Small Computer System Interface.Network 318 can be, among other things, a cell network, a wireless network, a wide area network (WAN), a local area network (LAN), or the internet. An external data processing unit (DPU) 320 can be connected to a DPU 300 via network 318. In some examples, the external DPU 320 might be an external web server 320. In other examples, the external DPU 320 might be a cloud computing node.

[0031] The processor 302 can also be connected via the system connection 306 to a storage unit 322, which can include a hard disk drive, an optical drive, a USB flash drive, an array of drives, or any combination thereof. In some examples, the storage unit can include an indicator detection module 324, an alternate name generator module 326, and a proxy configurator module 328. The indicator detection module 324 can detect a legacy indicator. For example, the indicator detection module 324 can receive a manifest and detect a legacy indicator within the manifest. The legacy indicator could be a specific attribute in a manifest, pod-specific metadata, a specific URL pattern generated by running an image of a deployment, or a legacy microservice in an application programming interface (API) specification, as discussed above.The legacy indicator can show the potential access of a legacy client. This legacy client might be, for example, an agent using Transport Layer Security (TLS) to perform a health check or any other service. Upon detecting a legacy client, the Alternate Name Generator (ALG) module 326 can generate an alternate server name. The ALG module 326 can also map the alternate server name to the address of a pod. The pod might, for example, be an endpoint of a sidecar proxy. In some examples, the ALG module 326 can modify a pod's URL based on the alternate server name. The ALG module 326 can be implemented through an allow control unit, an extension API, or a control loop.The Proxy Configurator Module 328 can configure a proxy associated with the pod to selectively provide a service based on the alternate server name. For example, the Configurator Module 328 can configure the proxy associated with the pod to selectively disable a service in response to receiving a server name indicator containing the alternate server name. For example, the disabled service could be mTLS. The Processor 302 can transfer data for an application instance or service through the configured proxy. In some examples, the Processor 302 can provide services for an application instance through the configured proxy. For example, the processor can provide credential services such as mTLS or TLS services through the configured proxy.

[0032] It should be noted that the block diagram consists of Fig. 3 is not intended to imply that the data processing unit 300 contains all in Fig. The data processing unit is intended to contain the three components shown. Rather, it may contain fewer or additional components, which are located in... Fig. 3 are not illustrated (e.g., additional memory components, embedded control units, modules, additional network interfaces, etc.). Furthermore, each of the functionalities of the indicator recognition module 324, the alternative name generator module 326, and the proxy configuration module 328 can be implemented partially or completely in hardware and / or in the processor 302. For example, the functionality can be implemented, among other things, with an application-specific integrated circuit, logic implemented in an embedded control unit, or as logic implemented in the processor 302. In some embodiments, the functionalities of the indicator recognition module 324, the alternative name generator module 326, and the proxy configuration module 328 can be implemented with logic, wherein the logic in this case is any suitable hardware (including, for example, a processor), software (including, for example, a processor), or other software.an application), firmware, or any suitable combination of hardware, software, and firmware. For example, the functionalities of the Indicator Detection Module 324, the Alternate Name Generator Module 326, and the Proxy Configurator Module 328 can be implemented in an extension attachment point. The extension attachment point can be, for example, an Admission Control Unit, an Extension API Server, or a control loop. An Admission Control Unit can examine and modify a manifest before the pod is created. For example, the Admission Control Unit can invoke one or more Admission Control Webhooks that match the request. The webhooks can rewrite the deployment descriptor in the manifest to change the original name to an alternate name for activity and readiness probes. An Extension API Server can invoke an Admission Attachment Point.For example, the extension API server can receive a workload, call an extension point with the received workload, and receive a modified deployment descriptor containing at least one Uniform Resource Locator (URL) that uses the alternate server name. The control loop can monitor the collective state of a cluster via an orchestrator's API server and make changes to alter the current state to a desired state. For example, the control loop can subscribe to change notifications and, in response to the detection of a new workload, modify the deployment descriptor of the new workload to reflect the desired state of using the alternate server name.

[0033] In Fig. Figure 4 illustrates a Cloud Computing Environment 400. As shown, the Cloud Computing Environment 400 has one or more Cloud Computing Nodes 402 with which local data processing units used by cloud users, such as the electronic assistant (PDA, personal digital assistant) or mobile phone 404A, the desktop computer 404B, the laptop computer 404C, and / or the automotive computer system 404N, can exchange data. The Nodes 402 can exchange data with each other. They can be grouped physically or virtually into one or more networks, such as private, community, public, or hybrid clouds (not shown), as described above, or into a combination thereof. This enables the Cloud Computing Environment 400 to offer infrastructure, platforms, and / or software as services for which a cloud user does not need to maintain resources on a local data processing unit.It is noted that the in . Fig. The four types of data processing units shown (404A-N) are merely examples and the data processing nodes (402) and the cloud computing environment (400) can exchange data with any type of data processing unit over any type of network and / or network-addressable connection (e.g., using a web browser).

[0034] Fig. Figure 5 shows a group of 400 through the cloud computing environment ( Fig. 4) provided functional abstraction layers. It should be noted beforehand that the in Fig. The components, layers, and functions shown in Figure 5 are to be understood as merely illustrative, and embodiments of the invention are not limited to these. As shown, the following layers and corresponding functions are provided.

[0035] A 500 hardware and software layer contains hardware and software components. Examples of hardware components include mainframes, such as IBM® zSeries® systems; servers with RISC (Reduced Instruction Set Computer) architecture, such as IBM pSeries®, IBM xSeries®, and IBM BladeCenter® systems; storage devices; networks; and networking components. Examples of software components include network application server software, such as IBM WebSphere® application server software, and database software, such as IBM DB2® database software. (IBM, zSeries, pSeries, xSeries, BladeCenter, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.)

[0036] The virtualization layer 502 provides an abstraction layer from which the following examples of virtual entities can be provisioned: virtual servers, virtual storage, virtual networks (including virtual private networks), virtual applications and operating systems, and virtual clients. In one example, the management layer 504 can provide the following functionality: Resource provisioning provides dynamic procurement of compute resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing provide cost monitoring for resources used within the cloud computing environment, as well as billing and invoicing for the use of these resources. In one example, these resources might include application software licenses.Security (not shown) provides identity verification for cloud customers and tasks, as well as protection for data and other resources. A user portal provides access to the cloud computing environment for customers and system administrators. Quality of service (QoS) management provides the allocation and management of cloud computing resources to meet required QoS levels. Service level agreement (SLA) planning and fulfillment (not shown) provides the advance planning and procurement of cloud computing resources for which a future requirement is anticipated, in accordance with an SLA. A service network provides infrastructure services such as routing, security, and metrics.

[0037] A workload layer 506 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: Mapping and navigation; software development and lifecycle management; provision of training in virtual classrooms; data analytics processing; transaction processing; and mobile desktop.

[0038] The methods presented may be a system, a process, or a computer program product. The computer program product may comprise a computer-readable storage medium (or media) on which computer-readable program instructions are stored to induce a processor to execute aspects of the present invention.

[0039] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by a unit to execute instructions. For example, a computer-readable storage medium can be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, random-access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), portable compact storage disk-read-only memory (CD-ROM), DVD (digital versatile disc), USB flash drive, floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium shall not, in its use herein, be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses traveling through an optical fiber cable), or electrical signals transmitted by a wire.

[0040] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0041] Computer-readable program instructions for executing the steps of the methods described herein can be assembly instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, stateful data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, and similar languages, as well as traditional procedural programming languages ​​such as C or similar languages. The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter case, the remotely located computer can 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 the connection can be established with an external computer (for example, via the internet using an internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), can execute the computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.

[0042] Aspects of the present methods are described herein with reference to flowcharts and / or block diagrams or diagrams of processes, devices (systems), and computer program products according to embodiments of the methods. It is noted that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be executed by means of computer-readable program instructions.

[0043] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or another programmable data processing device to create a machine, such that the instructions executed via the processor of the computer or other programmable data processing device will generate a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams.

[0044] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device, or other unit to cause the execution of a series of process steps on the computer or other programmable device or other unit in order to generate a process executed on a computer, such that the instructions executed on the computer, other programmable device, or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0045] Fig. Figure 6 shows a block diagram of an exemplary physical, non-transient, computer-readable medium 600 that can selectively provide mTLS using alternative server names. The physical, non-transient, computer-readable medium 600 can be accessed by a processor 602 via a computer connection 604. Furthermore, the physical, non-transient, computer-readable medium 600 can contain code to instruct the processor 602 to perform the steps of the procedure 200 from the preceding figure. Fig. 2 to be carried out.

[0046] The various software components discussed here can be stored on the physical, non-transient, computer-readable medium 600, as in Fig. Figure 6 shows this. For example, an indicator detection module 606 contains code to monitor manifests for legacy indicators. It also contains code to detect a legacy indicator associated with a legacy client in a manifest. In some examples, the indicator detection module 606 may also contain code to inspect and modify a manifest before the pod is created. In some examples, the indicator detection module 606 may also contain code to detect the legacy indicator during application deployment. An alternate name generator module 608 contains code to generate an alternate server name in response to the detection of the legacy indicator. The alternate name generator module 608 also contains code to map the alternate server name to a pod's address.In some examples, the alternate name generator module 608 also contains code to store a mapping of the alternate server name to the pod in a service register. A proxy configurator module 610 contains code to configure a proxy associated with the pod to disable a service in response to receiving a server name indicator containing the alternate server name from the legacy client. For example, the proxy configurator module 610 may contain code to configure the proxy to disable mutual transport layer security (mTLS) in response to receiving a server name indicator containing the alternate server name from a legacy client.In some examples, the proxy configuration module 610 may contain code to configure the proxy to provide an alternative service in response to receiving the server name indicator containing the alternate server name from the legacy client. For example, the proxy configuration module 610 may contain code to configure the proxy to provide TLS in response to receiving the server name indicator containing the alternate server name from the legacy client. In some examples, the legacy client may perform a health check on an application instance associated with the proxy using the alternate server name. The health check could be, for example, an activity check or a readiness check. Note that, depending on the specific application, any number of these parameters may be present. Fig. 6 additional software components not shown, contained in the physical, non-transient, computer-readable medium 600.

[0047] The flowcharts and block diagrams / charts in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, procedures, and computer program products according to various embodiments of the present methods. In this context, each block in the flowcharts or block diagrams / charts can represent a module, segment, or part of instructions that contain one or more executable instructions for performing the specific logical function(s). In some alternative embodiments, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may in reality be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order, depending on the corresponding functionality.It should also be noted that each block of the block diagrams and / or flowcharts, as well as combinations of blocks in the block diagrams and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or steps, or by combinations of special hardware and computer instructions. It should be noted that, depending on the specific application, any number of blocks may be included. Fig. 6 additional software components not shown, contained in the physical, non-transient, computer-readable medium 600.

[0048] The descriptions of the various embodiments of the present methods are provided for illustrative purposes only and are not intended to be exhaustive or limited to these embodiments. Many modifications and variations are apparent to the person skilled in the art, without deviating from the scope and fundamental principles of the described embodiments. The terminology used herein has been chosen to best explain the fundamental principles of the embodiments, their practical application, or technical improvements compared to technologies available on the market, or to enable the person skilled in the art to understand the embodiments disclosed herein.

Claims

[1] System that has a hardware processor (602) configured to: In response to the detection of a legacy indicator, generate an alternative server name and assign the alternative server name to a pod address; and to configure a proxy (116) associated with the pod so that it selectively provides mutual transport layer security (mTLS) based on the alternative server name, wherein the system includes an extension application programming interface (API) server to receive a workload, invoke an extension point with the received workload, and receive a modified deployment descriptor that includes at least one uniform resource locator (URL) that uses the alternate server name; and where the legacy indicator is an indicator that a particular connection should not use mTLS. [2] System according to claim 1, wherein the system includes an approval control unit to check and modify a manifest before the pod is created. [3] System according to claim 1, wherein the system has a control loop to subscribe to change notifications and, in response to the detection of a new workload, to modify a deployment descriptor of the new workload to correspond to a desired state of using the alternative server name. [4] System according to claim 1, wherein the legacy indicator comprises a specific attribute in a manifest, pod-specific metadata, a specific URL pattern generated by running an image of a deployment, or a legacy microservice in an application programming interface (API) specification. [5] System according to claim 1, wherein a legacy client associated with a detected legacy client access has an agent that uses Transport Layer Security (TLS) to perform a state check. [6] System according to claim 1, wherein the hardware processor is provided to provide services for an application instance in the pod via the configured proxy. [7] A computer-implemented procedure comprising: Detection (202) of a legacy indicator via a processor (602), Modifying (204) a Uniform Resource Location (URL) of a pod by the processor to use an alternate server name, and Generating the alternate server name in response to detecting the legacy indicator and assigning the alternate server name to a pod address; and Configure (206) a proxy (116) associated with the pod to disable mutual transport layer security (mTLS) in response to receiving the alternate server name, where the legacy indicator is an indicator that a particular connection should not use mTLS. [8] A computer-implemented method according to claim 7, wherein the detection of the legacy indicator comprises receiving a manifest and sending the manifest to a webhook for verification. [9] A computer-implemented method according to claim 7, wherein the detection of the legacy indicator comprises subscribing to change notifications that detect a new workload that has the legacy indicator. [10] A computer-implemented method according to claim 7, wherein the detection of the legacy indicator comprises running an image of a deployment in a sandbox environment and checking for the presence of a specific URL pattern that exhibits the legacy indicator. [11] A computer-implemented method according to claim 7, wherein modifying the URL comprises rewriting a manifest via a webhook. [12] A computer-implemented method according to claim 7, comprising disclosing the alternative name as an attribute to configure other systems to use the alternative server name. [13] A computer-implemented method according to claim 7, comprising automatically reconfiguring another system component using the alternative server name. [14] Computer program product for selectively providing mutual transport layer security (mTLS), wherein the computer program product comprises a computer-readable storage medium containing program code, wherein the computer-readable storage medium is not a transient signal in itself, wherein the program code is executable by a processor (602) to cause the processor to: to monitor a plurality of manifestos against a plurality of legacy indicators, to identify a legacy indicator belonging to at least one legacy client in at least one of the majority of manifests, to generate an alternative server name in response to the detection of the legacy indicator, to assign the alternative server name to a pod's address and to configure a proxy (116) associated with the pod so that, in response to receiving a server name indicator containing the alternative server name from at least one legacy client, it disables a service, where the legacy indicator is an indicator that a particular connection should not use mTLS. [15] Computer program product according to claim 14, further comprising program code executable by the processor to check and modify a manifest before the pod is created. [16] Computer program product according to claim 14, further comprising program code executable by the processor to detect the legacy indicator during the deployment of an application. [17] Computer program product according to claim 14, further comprising program code executable by the processor to store an assignment of the alternative server name to the pod in a service register. [18] Computer program product according to claim 14, further comprising program code executable by the processor to configure the proxy to provide Transport Layer Security (TLS) in response to receiving the server name indicator containing the alternative server name from the legacy client. [19] Computer program product according to claim 14, further comprising program code executable by the processor to configure the proxy to disable mTLS in response to receiving the server name indicator containing the alternative server name.

Images