Method, device and storage medium for managing a container service

Abstract

This application discloses a container service management method, device, and storage medium. Relating to the field of digital information transmission technology, the container service management method includes: in response to an incoming connection request whose target port is a first preset port, redirecting the incoming connection request to an inbound monitoring port monitored by an authentication proxy process; controlling the authentication proxy process to check the first authentication information of the incoming connection request received by the inbound monitoring port according to an authentication algorithm; and if the first authentication information check passes, forwarding the incoming connection request to the target application. This application achieves the technical effect of supporting secure authentication without modifying any code.

Description

Technical Field

[0001] This application relates to the field of digital information transmission technology, and in particular to a method, apparatus and storage medium for managing container services. Background Technology

[0002] Currently, software applications are typically deployed in containers, but many internal or legacy HTTP services do not include robust authentication mechanisms. Therefore, directly exposing HTTP services to complex network environments poses security risks.

[0003] In related technologies, the approach to reduce security risks is to add authentication to these services. The specific solution involves modifying the application code, specifically embedding authentication code directly into the service's business logic. However, this approach is highly intrusive and prone to introducing new errors. Summary of the Invention

[0004] The main purpose of this application is to provide a management method, device and storage medium for container services, which aims to solve the technical problem that embedding authentication code in the business logic of the service itself can easily introduce new errors.

[0005] To achieve the above objectives, this application provides a method for managing container services, which includes:

[0006] In response to an incoming connection request whose target port is the first preset port, the incoming connection request is redirected to the inbound monitoring port monitored by the authentication agent process.

[0007] The control authentication agent process checks the first authentication information of the incoming connection requests received by the inbound monitoring port according to the authentication algorithm;

[0008] If the initial authentication information check passes, the incoming connection request will be forwarded to the target application.

[0009] In one embodiment, the step of redirecting an incoming connection request to an inbound monitoring port monitored by the authentication proxy process in response to an incoming connection request whose target port is a preset port includes:

[0010] By using pre-configured iptables rules within the container, inbound connection requests with a target port of a preset port can be monitored.

[0011] When an incoming connection request is detected, the PREROUTING chain in the iptables nat table is used to change the target port of the incoming connection request from the default port to the inbound monitoring port monitored by the authentication agent process, so as to redirect the incoming connection request to the inbound monitoring port.

[0012] In one embodiment, the step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm includes:

[0013] The control authentication agent process parses the incoming connection requests received by the inbound monitoring port and extracts the authentication information carried in the incoming connection requests. The authentication information includes the Token carried in the request header, signature information, or identity credentials carried in the request body.

[0014] The authentication information is checked according to the preset authentication algorithm to verify its validity and whether the access permissions corresponding to the authentication information comply with the access rules of the target application.

[0015] In one embodiment, after the step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm, the process includes:

[0016] If the initial authentication information check fails, the control authentication agent process terminates the connection and returns an error response to the first source service that initiated the connection request.

[0017] In one embodiment, after the step of forwarding the incoming connection request to the target application, the method includes:

[0018] Control the authentication agent process to receive the first response information from the target application;

[0019] Process identifier for parsing the first response information;

[0020] If the process identifier is in the whitelist, then the second authentication information is added to the first response information according to the authentication algorithm to obtain the target response information;

[0021] Forward the target response information to the first source service of the incoming connection request.

[0022] To achieve the above objectives, this application also provides a method for managing container services, including:

[0023] In response to an outbound connection request whose target port is the second preset port, the outbound connection request is redirected to the outbound monitoring port monitored by the authentication agent process.

[0024] The control authentication proxy process parses the process identifier of the connection request;

[0025] If the process identifier is in the whitelist, then third authentication information is added to the outbound connection request according to the authentication algorithm to obtain the target outbound connection request;

[0026] Forward the outbound connection request to the target service corresponding to the outbound connection request.

[0027] In one embodiment, after the step of controlling the authentication proxy process to parse the process identifier of the connection request, the method includes:

[0028] If the process identifier is not in the whitelist, the authentication agent process controls the return of an error response to the second-source service that made the outgoing connection request.

[0029] In one embodiment, after the step of forwarding the target outbound connection request to the target service corresponding to the outbound connection request, the method includes:

[0030] Control the authentication agent process to receive the second response information from the target service;

[0031] Based on the authentication algorithm, examine the fourth authentication information in the second response information;

[0032] If the fourth authentication information passes the check, the fourth authentication information will be forwarded to the second source service corresponding to the outgoing connection request.

[0033] In addition, to achieve the above objectives, this application also provides a container service management device, which includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the container service management method described above.

[0034] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium, on which a program implementing a container service management method is stored, and the program implementing the container service management method is executed by a processor to implement the steps of the container service management method as described above.

[0035] This application provides a container service management method. First, in response to an incoming connection request whose target port is a first preset port, the method redirects the incoming connection request to an inbound monitoring port monitored by an authentication proxy process. The authentication proxy process then checks the first authentication information of the incoming connection request received by the inbound monitoring port according to an authentication algorithm. If the first authentication information passes the check, the incoming connection request is forwarded to the target application. By redirecting incoming connection requests to the inbound monitoring port of the authentication proxy, all requests accessing the target port undergo an authentication process, directly blocking unauthenticated requests from reaching the target application. This intercepts illegal access at the source. Furthermore, the authentication algorithm of the authentication proxy process verifies and intercepts unauthorized illegal requests, achieving the technical effect of supporting secure authentication without modifying any code. Attached Figure Description

[0036] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0037] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0038] Figure 1 A flowchart illustrating the management method for container services provided in this application, as described in Embodiment 1.

[0039] Figure 2 A flowchart illustrating the management method for container services provided in Embodiment 4 of this application;

[0040] Figure 3 A flowchart is provided for Embodiment 5 of the management method for container services in this application;

[0041] Figure 4 A schematic diagram of the incoming connection request processing flow in an embodiment of the management method for container services in this application;

[0042] Figure 5 A flowchart illustrating the management method for container services provided in Embodiment Six of this application;

[0043] Figure 6 A flowchart is provided for Embodiment 7 of the management method for container services in this application;

[0044] Figure 7 A flowchart illustrating the management method for container services provided in Embodiment 8 of this application;

[0045] Figure 8 A schematic diagram of the outbound connection request processing flow in an embodiment of the management method for container services in this application;

[0046] Figure 9 This is a schematic diagram of the structure of the management device for container services in this application embodiment.

[0047] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0048] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0049] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0050] Currently, the approach used in related technologies to reduce security risks is to add authentication to these services. The specific solution involves modifying the application code, specifically embedding authentication code directly into the service's business logic. However, this approach is highly intrusive and prone to introducing new errors.

[0051] The main solution of this application is as follows: In response to an incoming connection request whose target port is a first preset port, the application redirects the incoming connection request to the inbound monitoring port monitored by the authentication proxy process; it controls the authentication proxy process to check the first authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm; if the first authentication information check passes, the incoming connection request is forwarded to the target application. By redirecting the incoming connection request to the inbound monitoring port of the authentication proxy, all requests accessing the target port undergo an authentication process, directly blocking the path of unauthenticated requests to the target application, intercepting illegal access at the source, and then verifying the authentication by the authentication algorithm of the authentication proxy process to intercept unauthorized illegal requests, achieving the technical effect of supporting secure authentication without modifying any code.

[0052] It should be noted that the execution subject in this embodiment can be a container service management device, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a container service management device capable of performing the above functions. This embodiment does not specifically limit it in this way. The following uses a container service management device as an example to describe this embodiment and the following embodiments.

[0053] Based on this, Embodiment 1 of this application proposes a method for managing container services. Please refer to... Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the container service management method of this application. The container service management method includes steps S10 to S30:

[0054] Step S10: In response to an incoming connection request whose target port is the first preset port, the incoming connection request is redirected to the inbound monitoring port monitored by the authentication agent process.

[0055] The first preset port is a pre-defined target port that requires authentication and control. It is typically the port through which the application within the container provides services. If an incoming connection request points to this port, it triggers the subsequent authentication process. An incoming connection request is a network connection request initiated from outside the container, such as from another container, host, or network, attempting to connect to the target port within the container. The authentication proxy process is a dedicated program process responsible for authenticating and verifying received connection requests. It runs within the container or its environment and checks the legitimacy of the connection request using a preset authentication algorithm. The inbound monitoring port is a dedicated port for the authentication proxy process, used to receive redirected incoming connection requests. It is used only by the authentication proxy process and does not directly provide services externally.

[0056] In this embodiment, when the target port of an incoming connection request initiated from outside is a first preset port, the system automatically forwards the request to the inbound monitoring port. This port is specifically acquired by the authentication proxy process, so that the connection request first enters the authentication process instead of directly reaching the target application, providing a prerequisite for subsequent security control such as identity verification and permission checks. By redirecting incoming connection requests to the first preset port to the authentication proxy process, all requests accessing this port are forced to undergo authentication verification, preventing unauthorized requests from directly accessing the target application and reducing the risk of unauthorized intrusion.

[0057] In a first feasible implementation, step S10 may include: configuring port forwarding rules through a container network plugin; when an incoming connection request's target port matches a first preset port, directly modifying the request's destination port to the inbound monitoring port based on the preset rules, thus achieving direct redirection at the underlying network layer. Relying on network tools for redirection results in extremely low performance overhead and is suitable for high-concurrency scenarios.

[0058] In a second feasible implementation, step S10 may include: deploying traffic interception logic at the container gateway or load balancer layer to identify the port of all inbound connection requests. When the target port is identified as a first preset port, the gateway or load balancer actively forwards the connection request to the inbound monitoring port obtained by the authentication proxy process and records the target information of the original request for subsequent feedback. Centralized traffic interception at the cluster entry layer enables global control across containers and nodes, making it suitable for complex service architectures with multi-container collaboration.

[0059] In a third feasible implementation, step S10 may include: starting a dedicated traffic proxy process inside the container. This process is independent of the authentication proxy process and continuously acquires a first preset port. When an incoming connection request is received, it does not directly process business logic but forwards the request to the inbound monitoring port of the authentication proxy process through inter-process communication, thereby achieving process-level request forwarding within the container. This approach relies solely on the container's internal processes, is simple to deploy, does not require cluster-level network components, and is suitable for single-machine containers or lightweight deployment scenarios.

[0060] The above are only three feasible implementation methods of step S10 provided in this embodiment. This embodiment does not specifically limit the specific implementation method of step S10.

[0061] Step S20: Control the authentication agent process to check the first authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm.

[0062] The authentication algorithm is a set of predefined rules or computational logic used to verify the legitimacy of incoming connection requests. It validates the input authentication information to determine if the connection request conforms to preset security rules. Common authentication algorithms include password hashing algorithms, symmetric or asymmetric encryption algorithms, and token verification algorithms. The choice of authentication algorithm depends on the security policy of the container service. The first authentication information is carried in the incoming connection request to prove the identity or authority of the requester. For example, it might be an encrypted string of username and password, digital certificate, access token, API key, signature information, etc. This information is extracted by the authentication proxy process and used to verify the authentication algorithm to determine whether the connection request originates from an authorized entity.

[0063] In this embodiment, after receiving an incoming connection request redirected to the inbound monitoring port, the authentication proxy process performs a validity check on the first authentication information carried in the request according to a preset authentication algorithm. Through algorithmic verification logic, it confirms whether the initiator of the connection request is an authorized entity, thereby deciding whether to allow the request to continue accessing the target application, effectively intercepting unauthorized illegal requests.

[0064] In a first feasible implementation, step S20 may include: the authentication agent process extracting first authentication information from the protocol header of the incoming connection request, verifying the legality of the information using a preset asymmetric encryption algorithm, and simultaneously querying the locally cached authorization list to confirm that the authentication information has not expired and that the permission scope matches the service corresponding to the target port. If all conditions are met, the check is deemed successful. By using an asymmetric encryption algorithm to verify the signature, the authentication information can be effectively prevented from being tampered with or forged, resulting in high security.

[0065] In a second feasible implementation, step S20 may include: the authentication proxy process parsing the first authentication information carried in the incoming connection request, calculating the information using a preset hash algorithm, comparing the result with the baseline value returned by the backend authentication server, and simultaneously verifying whether the request source IP is within a preset whitelist. If the hash comparison matches and the IP is valid, the check is deemed successful. The hash algorithm comparison ensures the consistency of the authentication information and avoids the risk of plaintext transmission.

[0066] Step S30: If the first authentication information check passes, the incoming connection request is forwarded to the target application.

[0067] In this embodiment, once the authentication proxy process verifies the legitimacy of the first authentication information of the incoming connection request through the authentication algorithm, it forwards the incoming connection request to the target application corresponding to the initial target port, enabling the request to reach the business service and be processed normally. By ensuring that legitimate requests can smoothly access the target application while completing security verification, the security of the container service is guaranteed without hindering the passage of normal business traffic, thus balancing security control and service availability.

[0068] In a first feasible implementation, step S30 may include: after confirming that the first authentication information check has passed, the authentication agent process obtains the original target port corresponding to the target application through a preset port mapping relationship, directly modifies the destination port of the incoming connection request to the original port, and forwards the request to the target application based on the network stack inside the container, while retaining the original source information of the request to ensure that the target application can correctly identify the source of the request. Forwarding is achieved through port mapping relationships, which is logically simple and highly compatible with the container network model, requiring no additional adaptation from the target application, resulting in low deployment costs.

[0069] In a second feasible implementation, step S30 may include: after successful authentication, the authentication proxy process generates a forwarding instruction containing the original request information, and sends this instruction to the target application's acquisition process via an inter-process communication mechanism. The target application then actively retrieves and processes the original incoming connection request from the authentication proxy process, thus achieving request transmission based on process-level interaction. Transmitting requests via inter-process communication allows for the flexible attachment of metadata such as authentication pass identifiers and permission scope during the forwarding process, facilitating the target application's rapid identification of the request's legitimacy and permission level, and reducing secondary verification costs.

[0070] This embodiment provides a container service management method. In response to an incoming connection request whose target port is a first preset port, the method redirects the incoming connection request to the inbound monitoring port monitored by the authentication proxy process. The authentication proxy process checks the first authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm. If the first authentication information passes the check, the incoming connection request is forwarded to the target application. By redirecting the incoming connection request to the inbound monitoring port of the authentication proxy, all requests accessing the target port undergo an authentication process, directly blocking the path of unauthenticated requests to the target application. This intercepts illegal access at the source. Furthermore, the authentication algorithm of the authentication proxy process verifies and intercepts unauthorized illegal requests, achieving the technical effect of supporting secure authentication without modifying any code.

[0071] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. On this basis, the step of redirecting an incoming connection request to the inbound monitoring port monitored by the authentication proxy process in response to an incoming connection request with a target port of a preset port includes:

[0072] Step S11: Monitor incoming connection requests with a target port set to a preset port using the pre-configured iptables rules within the container.

[0073] Containers are lightweight virtualization technologies that encapsulate applications and their dependencies, such as code, libraries, and configuration files. They can run independently in isolated environments, sharing the kernel with the underlying host system. They are characterized by fast startup and low resource consumption, making them the core operating unit for container services. iptables rules are kernel-level rule sets used for filtering, forwarding, and modifying network traffic. By defining matching conditions and execution actions, they control network packets. Pre-configured iptables rules within a container are rules specifically set up to handle specific network requests. Pre-defined ports are ports that require traffic monitoring or security control. These are typically critical ports used by applications within the container to provide services externally. Incoming connection requests pointing to these ports trigger subsequent actions defined by the iptables rules.

[0074] In this embodiment, iptables rules are pre-configured within the container upon startup, and these rules continuously capture network packets. When the target port of an incoming connection request from an external source matches a preset port defined in the rule, the iptables rule triggers a pre-defined monitoring action, thereby achieving real-time awareness and control of access traffic to critical ports. By accurately capturing access requests to target ports through underlying rules, triggering conditions are provided for subsequent security verification, while avoiding dependence on the external network environment, enhancing the independence and flexibility of control.

[0075] Step S12: When an incoming connection request is detected, the PREROUTING chain in the nat table of iptables is used to change the target port of the incoming connection request from the preset port to the inbound monitoring port monitored by the authentication agent process, so as to redirect the incoming connection request to the inbound monitoring port.

[0076] The nat table in iptables is a rule table used to handle Network Address Translation (NAT). Its main function is to modify the source IP, destination IP, source port, or destination port of data packets, achieving network address or port mapping or translation. The nat table is commonly used to resolve communication between private networks and the public network. In container scenarios, nat table rules can be used to map ports inside and outside containers or redirect requests. The PREROUTING chain is a core rule chain in the nat table, operating on the stage after a data packet enters the network interface but before it is routed by the kernel. Before the data packet reaches the target application, its address or port is modified, such as changing the destination port from a preset port to an inbound monitoring port, ensuring that the modified data packet is routed according to the new destination information.

[0077] In this embodiment, when an incoming connection request with a target port of a preset port is detected, the target port of the incoming connection request is changed from the preset port to the inbound monitoring port monitored by the authentication proxy process using the PREROUTING chain in the iptables nat table. This intercepts and processes the data packet before it is routed to the target application, ensuring that the port modification occurs before the request reaches the business process. No additional intermediate process forwarding is required; request redirection is directly completed through kernel-level rules, automatically directing all requests accessing the preset port to the monitoring port of the authentication proxy, laying the underlying network foundation for subsequent authentication and verification.

[0078] In this embodiment, request redirection is achieved by combining iptables rules within the container with the PREROUTING chain of the nat table. All port modifications and request interception are completed through pre-configured iptables rules, and the target application does not need to modify its code, thus improving the security of the container service.

[0079] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a container service management method, which can be referred to the above description and will not be repeated hereafter. Based on this, the step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm includes:

[0080] Step S21: Control the authentication agent process to parse the incoming connection request received by the inbound monitoring port, and extract the authentication information carried in the incoming connection request. The authentication information includes the Token carried in the request header, signature information, or identity credentials carried in the request body.

[0081] In this context, authentication information refers to various data carried in the incoming connection request to prove the legitimacy or authority of the request initiator. It is the core basis for the authentication proxy process to determine whether the request is authorized. A token is typically an encrypted string obtained by the request initiator from the authentication server before initiating the request. It proves that the request has passed prior authentication, such as username / password verification or third-party authorization. Signature information is generally the result of the request initiator encrypting the request content using a private key. The authentication proxy process can decrypt and verify this using the corresponding public key, ensuring that the request content has not been tampered with and indeed comes from a legitimate initiator. Identity credentials are the original or encrypted information directly provided by the request initiator in the connection request to prove their identity, identifying who initiated the request. Common examples include encrypted username and password strings, API keys, and certificate information—data directly used for identity identification. These are typically carried in scenarios requiring explicit verification of who initiated the request, such as login information submitted through a form or key parameters during API calls.

[0082] In this embodiment, the received incoming connection request is parsed to identify the authentication information carried in the request, including the token and signature information carried in the request header and the identity credentials contained in the request body. The scattered authentication-related data in the request is extracted to ensure that the authentication proxy process can obtain complete verification evidence, providing data support for subsequent verification of the request's legitimacy through the authentication algorithm.

[0083] Step S22: Check the authentication information according to the preset authentication algorithm to verify the validity of the authentication information and whether the access permissions corresponding to the authentication information comply with the access rules of the target application.

[0084] Access permissions refer to the scope of operations or resource boundaries that the request initiator, such as a user, service, or device, is allowed to perform. For example, for a user, this might be read-only, read-write, or administrator permissions; for a service, it might be access to specific API interfaces or the ability to invoke certain functions. Access permissions are usually bound to authentication information to determine whether a request has permission to access the target application. Access rules are a set of pre-defined conditions in the target application to restrict access, defining who can access the application and how. Examples include permission matching rules (e.g., only administrators can access backend interfaces, and read-only permissions cannot perform delete operations), resource scope rules (e.g., only user data with IDs up to 100 are allowed), and time / frequency rules (e.g., a maximum of 1000 accesses per day, and access is only allowed during working hours). Access rules define the security boundaries of the target application; the authentication proxy must verify whether the requested access permissions fully comply with these rules to determine the request's legitimacy.

[0085] In this embodiment, based on a preset authentication algorithm, the legitimacy of the extracted authentication information itself is checked. For example, the validity of the token is verified to ensure it is within its validity period and the signature has not been tampered with; the signature information is verified to be decryptable using a public key; and the identity credential is verified to match the authorization information stored in the backend. This ensures that the authentication information itself is authentic, not expired, and not forged. Based on the confirmed validity of the authentication information, the permission scope corresponding to the information is further verified to ensure it meets the access rules of the target application. For example, if the target application's access rule is that only administrators can access it, it is necessary to verify whether the permission associated with the authentication information is that of an administrator; if the rule limits access to a maximum of 100 times per hour, it is necessary to check whether the current access frequency of the request initiator is within the threshold. This step ensures that the requested operation permissions match the security boundary of the target application, avoiding unauthorized access by individuals with legitimate identities but insufficient permissions. Through this two-layer verification—first verifying identity validity, then verifying permission compatibility—both unauthorized intrusion and unauthorized operations by legitimate identities are prevented, providing comprehensive protection for the target application.

[0086] In this embodiment, by extracting authentication information and the corresponding access permissions, the validity of the authentication information and whether the access permissions corresponding to the authentication information comply with the access rules of the target application are verified respectively, thus constructing a more stringent security defense and realizing in-depth security control over container service access requests.

[0087] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a method for managing container services, which can be referred to in the above description and will not be repeated hereafter. Based on this, please refer to... Figure 2 , Figure 2This is a flowchart illustrating the management method for container services provided in Embodiment 4 of this application. Following the step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm, the method includes:

[0088] Step S201: If the first authentication information check fails, control the authentication agent process to terminate the connection and return an error response to the first source service that made the incoming connection request.

[0089] The first source service refers to the original service or entity that initiated the current inbound connection request. For example, this could be a client application outside the container, other microservices within the container cluster, or the terminal device calling the target application. The first source service clarifies the recipient of error responses, ensuring that failure information is accurately returned to the request initiator, informing them of the authentication failure.

[0090] In this embodiment, when the authentication proxy process fails to verify the first authentication information, it directly terminates the connection with the incoming connection request, returns standardized error response information to the first source service of the incoming connection request, and returns a 403 (Access Forbidden) error response to the client. By immediately terminating the connection, unauthenticated requests are completely blocked, preventing them from exploiting vulnerabilities or bypassing logic to access the target application, thus reducing security risks.

[0091] Based on any of the above embodiments of this application, Embodiment 5 of this application proposes a method for managing container services, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 A flowchart illustrating the fifth embodiment of the management method for container services in this application. Following the step of forwarding the incoming connection request to the target application, the method includes:

[0092] Step S301: Control the authentication agent process to receive the first response information from the target application.

[0093] The first response information refers to the processing result or feedback data returned by the target application in response to an incoming connection request initiated from the outside. It is the direct response of the business logic inside the container to the external request.

[0094] In this embodiment, the authentication proxy process receives the first response information, which is the core feedback data generated by the target application in response to the incoming connection request, such as the business processing result, data return, status code, etc. The authentication proxy process synchronously receives the response from the target application, preparing to subsequently send the response back to the request initiator.

[0095] Step S302: Parse the process identifier of the first response information.

[0096] The process identifier is a unique numerical number assigned by the operating system to each running process within the container, used to accurately identify and distinguish different processes. The process identifier for the first response message is a unique number used by the target application to identify which specific process processed and generated the response when generating and returning the first response message.

[0097] In this embodiment, by parsing specific fields of the first response information, such as the process_id field in the response body, or metadata attached to the protocol layer, a unique identifier, i.e., the process identifier, is extracted to identify the target application process that generated the response. By obtaining the process identifier, the source process of the response can be identified, facilitating subsequent tracking.

[0098] Step S303: If the process identifier belongs to the whitelist, then add the second authentication information to the first response information according to the authentication algorithm to obtain the target response information.

[0099] The whitelist refers to a pre-configured list of trusted process identifiers recognized by the system. Each process identifier in the list corresponds to a target application process that has undergone security verification and possesses legitimate permissions to process requests and generate responses. It is used to filter trusted response sources; only when the parsed process identifier is within the whitelist is the first response information determined to originate from a legitimate process. The second authentication information refers to the security data appended to the first response information by the authentication proxy process after confirming that the response source is trustworthy (i.e., the process identifier is within the whitelist), used to verify the integrity and legitimacy of the response.

[0100] In this embodiment, the process identifier corresponding to the first response information is first verified to see if it is in a preset whitelist. If the process identifier is in the whitelist, then based on a preset authentication algorithm, second authentication information, such as a digital signature or encrypted verification code, is added to the first response information to finally generate the target response information. Whitelist verification prevents responses generated by unauthorized processes from being sent back, ensuring the security of response data from the source.

[0101] Step S304: Forward the target response information to the first source service of the incoming connection request.

[0102] In this embodiment, the target response information, after appending the second authentication information to the first response information, is forwarded to the first source service of the incoming connection request, i.e., the client, third-party service, or terminal device that initially initiated the request. From the first source service initiating the request to the authentication proxy forwarding the target response information, a complete bidirectional communication link is formed, avoiding response loss or link breakage due to proxy intervention and ensuring the normal completion of business interactions.

[0103] In this embodiment, by receiving the first response information, performing security enhancement processing, and forwarding the first response information back to the first source service of the incoming connection request, the entire process of end-to-end security control of the response data is realized.

[0104] For example, to help understand the implementation flow of the container service management method obtained by combining this embodiment with the above embodiments, as follows: Figure 4 , Figure 4 This is a schematic diagram of the inbound connection request processing flow in an embodiment of the management method for container services in this application. Specifically:

[0105] When the container starts, inbound TCP connections destined for ports 80 or 443 are redirected to the inbound acquisition port (e.g., 7800) obtained by the local authentication proxy process using pre-configured iptables rules. The authentication proxy process receives the redirected original HTTP request on the inbound acquisition port, parses it, and checks the authentication information in the request header or body according to preset authentication algorithms such as JWT verification, Basic authentication, and HMAC signature verification. If authentication succeeds, the proxy process re-forwards the original HTTP request to the actual acquisition port (e.g., 5500) of the target application within the container. If authentication fails, the proxy process immediately terminates the connection and returns a 403 (Access Denied) error response to the client. The response generated by the target application after processing the request is first passed to the authentication proxy process, which then responds to the client. By leveraging the isolation of the container's network space and using iptables rules to automatically redirect HTTP traffic to the local authentication proxy process within the container, authentication verification of inbound requests is achieved without modifying any application code, supporting secure authentication without any code changes.

[0106] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the management method of the container service in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0107] Based on any of the embodiments described above, Embodiment Six of this application proposes a method for managing container services, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 5 , Figure 5 This is a flowchart illustrating a sixth embodiment of the container service management method provided in this application. The container service management method includes:

[0108] Step S100: In response to an outbound connection request whose target port is the second preset port, the outbound connection request is redirected to the outbound monitoring port monitored by the authentication agent process.

[0109] The second preset port is a specific port pre-configured within the container for managing outbound connection requests. It corresponds to the first preset port, which manages inbound connection requests, and represents two different types of traffic. Outbound connection requests are network connection requests initiated by applications or processes within the container to the outside of the container. The direction is opposite to inbound connection requests initiated from the outside into the container; this is an active communication behavior of the container. The second preset port and the first preset port can be the same or different; this embodiment does not impose specific limitations.

[0110] In this embodiment, when an application initiates an outbound connection request with a target port of the second preset port, the request, originally intended for the second preset port, is redirected to the outbound monitoring port of the authentication proxy process according to preset rules. This ensures that all such outbound connection requests are first processed by the authentication proxy process. Through this redirection operation, the authentication proxy process can verify the request at the outbound monitoring port, allowing only legitimate outbound connection requests to continue transmission, thus blocking unauthorized external communication at the source.

[0111] Step S200: Control the authentication agent process to parse the process identifier of the connection request.

[0112] The process identifier refers to the unique number of the process making the outbound connection request. If an application process within the container initiates an outbound connection request, the process identifier corresponding to that process is the process identifier that needs to be parsed here.

[0113] In this embodiment, for outbound connection requests initiated by applications within the container, the authentication proxy process extracts the process identifier of the initiating process from the metadata of the outbound connection request, such as the process-port binding relationship and the process ownership information of the network connection, through system calls or network protocol parsing. By parsing the process identifier, the source process of the outbound connection request can be directly located, providing a clear target for subsequent security analysis.

[0114] In step S300, if the process identifier belongs to the whitelist, then add third authentication information to the outbound connection request according to the authentication algorithm to obtain the target outbound connection request.

[0115] The third authentication information refers to the security data attached to the outgoing connection request by the authentication agent process after confirming that the process initiating the outgoing connection request is trustworthy, i.e., the process identifier is in the whitelist, to verify the legitimacy and integrity of the outgoing connection request.

[0116] In this embodiment, the process identifier of the outgoing connection request is first verified to see if it is in a preset whitelist. If the process identifier is in the whitelist, third authentication information, such as digital signatures or encrypted authorization credentials, is added to the outgoing connection request based on a preset authentication algorithm, ultimately generating the target outgoing connection request. By adding third authentication information to requests from processes in the whitelist, it is ensured that only outgoing connection requests initiated by trusted processes can pass subsequent verification, thus intercepting unauthorized processes' outgoing connections at the source.

[0117] Step S400: Forward the target outbound connection request to the target service corresponding to the outbound connection request.

[0118] In this embodiment, the outbound connection request, with the third authentication information appended to it, is forwarded to the target service originally indicated by the outbound connection request, such as an external API interface, database service, or other container applications—that is, the external recipient to which the process within the container wants to communicate. The forwarded outbound connection request carries the third authentication information, which the target service can verify using a preset algorithm to confirm that the request originates from a trusted process within the container and has not been tampered with, thus avoiding the processing of illegal or forged requests.

[0119] In this embodiment, the process identifier of the connection request is parsed and the whitelist is verified. Only requests from trusted processes are allowed to enter the subsequent process, thus fundamentally blocking the external connections of malicious processes.

[0120] Based on any of the above embodiments of this application, Embodiment Seven of this application proposes a method for managing container services, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 6 , Figure 6 This is a flowchart illustrating a management method embodiment seven for container services in this application. After the step of controlling the authentication proxy process to parse the process identifier of the connection request, the method includes:

[0121] Step S2001: If the process identifier is not in the whitelist, control the authentication agent process to return an error response to the second source service that made the outgoing connection request.

[0122] In this embodiment, when the authentication proxy process parses the process identifier of the outgoing connection request, it finds that the process identifier is not in the preset whitelist. The authentication proxy process directly rejects the outgoing connection request, does not forward it to the target service, and returns an error response to the second source service, i.e., the process inside the container that initiated the outgoing connection request, such as "The process is not in the whitelist and does not have permission to initiate an external connection" or "The request was intercepted by the security proxy." By rejecting outgoing connection requests initiated by processes outside the whitelist, unauthorized processes are prevented from leaking sensitive data inside the container or connecting to illegal external services, thus eliminating security risks at the source of the outgoing link.

[0123] Based on any of the above embodiments of this application, Embodiment Eight of this application proposes a method for managing container services, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 7 , Figure 7 This is a flowchart illustrating an eighth embodiment of the management method for container services in this application. Following the step of forwarding the target outbound connection request to the target service corresponding to the outbound connection request, the method includes:

[0124] Step S4001: Control the authentication agent process to receive the second response information of the target service.

[0125] The second response information is the processing result or feedback data returned by the target service in response to the outbound connection request initiated within the container. It corresponds to the first response information returned by the target application and belongs to the response data in the outbound communication link.

[0126] In this embodiment, the authentication proxy process actively receives the second response information by acquiring the outbound monitoring port or maintaining the communication link with the target service. This ensures that the processing result of the external service can be obtained by the initiating process within the container, avoiding response loss due to proxy intervention and guaranteeing the integrity of business interactions.

[0127] Step S4002: According to the authentication algorithm, check the fourth authentication information of the second response information.

[0128] The fourth authentication information refers to the security data attached by the target service when returning the second response information to prove the legitimacy and integrity of the response. This, together with the third authentication information added to the outgoing connection request, forms a two-way verification mechanism.

[0129] In this embodiment, the authentication proxy process verifies the fourth authentication information based on a preset authentication algorithm, determining whether the second response information satisfies the requirements of legitimate source, complete content, and request matching. If the verification passes, it confirms that the response comes from a legitimate target service and is complete, providing a security basis for subsequent return to the process within the container.

[0130] Step S4003: If the fourth authentication information passes the check, forward the fourth authentication information to the second source service corresponding to the outgoing connection request.

[0131] In this embodiment, if the fourth authentication information passes the check, the verified fourth authentication information is forwarded to the second source service corresponding to the outgoing connection request, i.e., the process or service within the container that initially initiated the outgoing connection request, such as a business service calling an external API or an application accessing a database. After forwarding the fourth authentication information to the second source service, the internal process can further verify the information to confirm that the received response indeed comes from a trusted external service and has not been tampered with, thus preventing the internal process from blindly trusting external data.

[0132] In this embodiment, by checking the fourth authentication information in the second response information, the authentication proxy can accurately determine whether the response comes from a legitimate target service and whether it has been tampered with during transmission. If the verification fails, the response is directly intercepted to prevent the second source service within the container from receiving forged data, thus blocking security risks at the response entry point.

[0133] For example, to help understand the implementation flow of the container service management method obtained by combining this embodiment with the above embodiments, please refer to... Figure 8 , Figure 8 A schematic diagram of the outbound connection request processing flow in the embodiment of the management method for container services in this application, specifically:

[0134] Using pre-configured iptables rules, outbound TCP connections originating from the container application and destined for ports 80 or 443 are redirected to the outbound acquisition port obtained by the authentication proxy process, such as 7801. The authentication proxy process receives the redirected original HTTP request from the container application on the outbound acquisition port. The authentication proxy process only signs HTTP requests from trusted processes; therefore, it finds the corresponding local process ID (PID) using the socket's IP and port. If the PID is not trusted, a 403 error response is returned. The authentication proxy process parses the HTTP request and enhances it according to pre-defined authentication algorithms, such as generating a Signature, adding an API Key, or injecting a Bearer Token. The proxy process then initiates a new TCP connection and sends the HTTP request, now with added authentication information, to the external target service in its own name. The response from the external service is received by the authentication proxy process, which then returns the response to the original requesting application within the container. By leveraging the isolation of the container's network space and utilizing iptables rules, HTTP traffic is automatically redirected to the local authentication proxy process within the container, thereby enabling automatic signing of outbound requests without modifying any application code, thus supporting secure authentication without requiring any code modifications.

[0135] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the management method of the container service in this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0136] Embodiment 9 of this application provides a container service management method, applied to a container service management system, specifically comprising: responding to an inbound connection request whose target port is a first preset port, redirecting the inbound connection request to an inbound monitoring port monitored by an authentication proxy process; controlling the authentication proxy process to check the first authentication information of the inbound connection request received by the inbound monitoring port according to an authentication algorithm; if the first authentication information check passes, forwarding the inbound connection request to the target application; responding to an outbound connection request whose target port is a second preset port, redirecting the outbound connection request to an outbound monitoring port monitored by the authentication proxy process; controlling the authentication proxy process to parse the process identifier of the outbound connection request; if the process identifier belongs to a whitelist, adding third authentication information to the outbound connection request according to an authentication algorithm to obtain the target outbound connection request; and forwarding the target outbound connection request to the target service corresponding to the outbound connection request.

[0137] In this embodiment, as Figure 4 When the container starts, pre-configured iptables rules redirect inbound TCP connections destined for ports 80 or 443 to the inbound port obtained by the local authentication proxy process, such as 7800. The authentication proxy process receives the redirected raw HTTP request on the inbound port. It parses the HTTP request and checks the authentication information in the request header or body according to a pre-defined authentication algorithm, such as JWT verification, Basic authentication, or HMAC signature verification. If authentication is successful, the proxy process re-forwards the raw HTTP request to the actual port obtained by the target application within the container, such as 5500. Upon receiving the forwarded HTTP request, the target application... Figure 8Using pre-configured iptables rules, outbound TCP connections with target ports of 80 or 443 are redirected to the outbound acquisition port obtained by the authentication proxy process, such as 7801. The authentication proxy process receives the redirected original HTTP request on the outbound acquisition port. The authentication proxy process only signs HTTP requests from trusted processes; therefore, it finds the corresponding local process PID using the socket's IP and port. If it's not a trusted PID, it returns a 403 error response. The HTTP request is parsed, and enhancement operations are performed according to a pre-defined authentication algorithm, such as generating a Signature, adding an API Key, or injecting a Bearer Token. The proxy process then initiates a new TCP connection and sends the HTTP request, now with added authentication information, to the external target service in its own name. The response returned by the external service is received by the authentication proxy process, which then returns the response back to the application that originally initiated the request within the container. By leveraging the isolation of the container's network space and using iptables rules, HTTP traffic can be automatically redirected to the local authentication proxy process within the container. This enables authentication and verification of inbound requests and automatic signing of outbound requests without requiring any modification to application code.

[0138] This application provides a container service management device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the container service management method in Embodiment 1 above.

[0139] The following is for reference. Figure 9 The diagram illustrates a structural schematic of a management device suitable for implementing container services in the embodiments of this application. The management device for container services in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 9 The container service management device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0140] like Figure 9As shown, the container service management device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the container service management device. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the container service management device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a container service management device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems can be implemented or have alternatively.

[0141] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0142] The container service management device provided in this application, employing the container service management method described in the above embodiments, can solve the technical problem of easily introducing new errors. Compared with the prior art, the beneficial effects of the container service management device provided in this application are the same as those of the container service management device provided in the above embodiments, and other technical features in this container service management device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0143] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0144] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0145] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the container service management method in the above embodiments.

[0146] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0147] The aforementioned computer-readable storage medium may be included in the management device of the container service; or it may exist independently and not be mounted in the management device of the container service.

[0148] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the container service management device, the container service management device: in response to an incoming connection request whose target port is a first preset port, redirects the incoming connection request to the inbound monitoring port monitored by the authentication agent process; controls the authentication agent process to check the first authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm; and if the first authentication information check passes, forwards the incoming connection request to the target application.

[0149] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code 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 a remote computer or server. In cases involving remote computers, the remote 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 can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0150] 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 this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. 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 operation, or using a combination of dedicated hardware and computer instructions.

[0151] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0152] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described container service management method, which can solve the technical problem of easily introducing new errors. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the container service management method provided in the above embodiments, and will not be repeated here.

[0153] This application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the container service management method described above.

[0154] The computer program product provided in this application can solve the technical problem of easily introducing new errors. Compared with the prior art, the beneficial effects of the computer program product provided in the embodiments of this application are the same as the beneficial effects of the container service management method provided in the above embodiments, and will not be repeated here.

[0155] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A method for managing container services, characterized in that, A management system for container services, wherein the management method for container services includes: In response to an incoming connection request whose target port is a first preset port, the incoming connection request is redirected to the inbound monitoring port monitored by the authentication proxy process. The authentication proxy process is controlled to check the first authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm; If the first authentication information check passes, the incoming connection request is forwarded to the target application; In response to an outbound connection request whose target port is the second preset port, the outbound connection request is redirected to the outbound monitoring port monitored by the authentication proxy process. Control the authentication proxy process to parse the process identifier of the outgoing connection request; If the process identifier belongs to the whitelist, then third authentication information is added to the outbound connection request according to the authentication algorithm to obtain the target outbound connection request; Forward the target outbound connection request to the target service corresponding to the outbound connection request; The step of redirecting an incoming connection request to an inbound monitoring port monitored by the authentication proxy process in response to an incoming connection request whose target port is a first preset port includes: By using pre-configured iptables rules within the container, inbound connection requests with a target port of a preset port can be monitored. When the incoming connection request is detected, the PREROUTING chain in the nat table of iptables is used to change the target port of the incoming connection request from the preset port to the inbound monitoring port monitored by the authentication agent process, so as to redirect the incoming connection request to the inbound monitoring port.

2. The container service management method as described in claim 1, characterized in that, The step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm includes: The authentication proxy process is controlled to parse the incoming connection requests received by the inbound monitoring port and extract the authentication information carried in the incoming connection requests. The authentication information includes the Token carried in the request header, signature information, or identity credentials carried in the request body. The authentication information is checked according to a preset authentication algorithm to verify its validity and whether the access permissions corresponding to the authentication information comply with the access rules of the target application.

3. The container service management method as described in claim 1, characterized in that, After the step of controlling the authentication proxy process to check the authentication information of the incoming connection request received by the inbound monitoring port according to the authentication algorithm, the following steps are included: If the first authentication information check fails, the authentication proxy process is controlled to terminate the connection and return an error response to the first source service of the incoming connection request.

4. The container service management method as described in claim 1, characterized in that, After the step of forwarding the incoming connection request to the target application, the following steps are included: The authentication agent process is controlled to receive the first response information from the target application. Parse the process identifier of the first response information; If the process identifier belongs to the whitelist, then the second authentication information is added to the first response information according to the authentication algorithm to obtain the target response information; The target response information is forwarded to the first source service of the incoming connection request.

5. The container service management method as described in claim 1, characterized in that, After the step of controlling the authentication proxy process to parse the process identifier of the outgoing connection request, the method includes: If the process identifier is not in the whitelist, the authentication proxy process is controlled to return an error response to the second source service of the outgoing connection request.

6. The container service management method as described in claim 1, characterized in that, After the step of forwarding the target outbound connection request to the target service corresponding to the outbound connection request, the following steps are included: Control the authentication proxy process to receive the second response information from the target service; According to the authentication algorithm, examine the fourth authentication information in the second response information; If the fourth authentication information passes the check, the fourth authentication information is forwarded to the second source service corresponding to the outgoing connection request.

7. A container service management device, characterized in that, The container service management device includes: a memory, a processor, and a computer program stored on the memory and executable on the processor, the computer program being configured to implement the steps of the container service management method as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the container service management method as described in any one of claims 1 to 6.

Images