Multi-tenant API key authentication and resource isolation system in containerized environment

Abstract

The invention discloses a multi-tenant API key authentication and resource isolation system in a containerized environment, and relates to the field of containerized multi-tenant authentication. Comprising an authentication authorization layer, a resource management and control layer and a security isolation layer. The authentication authorization layer comprises a multi-tenant authentication engine, an API key verification sub-module, a tenant identity recognition sub-module, an authority cascade verification sub-module and a dynamic authority calculation sub-module. And the resource management and control layer comprises a resource quota manager, a dynamic quota allocation sub-module, a real-time use monitoring sub-module, a threshold alarm control sub-module and an elastic capacity expansion and contraction sub-module. The security isolation layer comprises a multi-dimensional isolation engine, a container network isolation sub-module, a storage space isolation sub-module, a process permission isolation sub-module and a system call filtering sub-module; deep fusion of API authentication and container resource control is realized, a dynamic resource quota management mechanism based on tenant identities is established, and fine-grained API authority control and resource use limitation are provided.

Description

Technical Field

[0001] This invention relates to the field of containerized multi-tenant authentication, and more specifically to a multi-tenant API key authentication and resource isolation system in a containerized environment. Background Technology

[0002] Existing API key authentication systems, such as OAuth 2.0, JWT Token, and Basic API Key, include key generation, authentication, permission management, and session management modules. Their working principle is as follows: a unique API key is generated for each user or application; the validity of the key is verified during API requests; and the permission information associated with the key determines whether access to specific resources is permitted.

[0003] This resource limiting mechanism, based on Docker and Kubernetes, includes CPU limiting modules, memory limiting modules, storage quota modules, and network bandwidth control modules. Its working principle is to limit container resource usage through cgroups technology, setting upper limits for resources such as the number of CPU cores, memory size, and disk I / O. When container resource usage exceeds these limits, rate limiting or termination is implemented.

[0004] Tenant isolation solutions based on namespace or virtualization technologies include network isolation modules, storage isolation modules, process isolation modules, and permission isolation modules. The working principle is to create an independent operating environment for each tenant, achieving basic isolation between tenants through technologies such as virtual networks, independent storage volumes, and process namespaces.

[0005] A role-based access control system includes a user management module, a role definition module, a permission allocation module, and an access control module. Its working principle is: define different roles and permissions, assign users to specific roles, and control user access to resources based on role permissions.

[0006] The authentication and resource isolation are disconnected. In the existing system, API authentication and container resource isolation are two separate systems. The authentication system cannot directly control the allocation and use of container resources, which may cause authenticated users to consume system resources beyond their authorized scope.

[0007] The lack of tenant-level resource control means that traditional container resource limits can only be set at the container level, and cannot dynamically adjust resource quotas based on tenant identity, thus failing to effectively guarantee the service quality level of different tenants.

[0008] API key permission management is crude. Existing API key systems have overly simplistic permission management, typically offering only two states: "permission granted" or "no permission granted." This fails to achieve fine-grained permission control at the tenant level, such as restrictions on message posting frequency or the number of topic subscriptions.

[0009] Without a dynamic resource adjustment mechanism, the system cannot dynamically adjust resource quotas based on the actual usage and business needs of tenants. Resource allocation is fixed and cannot cope with changes in resource demand during peak business periods.

[0010] Incomplete security isolation means that simple namespace isolation cannot prevent malicious tenants from affecting the system, and there is a lack of deep security isolation mechanisms, such as network traffic isolation and system call restrictions.

[0011] The monitoring and auditing capabilities are insufficient, lacking tenant-level resource usage monitoring and behavior auditing functions, making it impossible to accurately track tenant resource consumption and operational behavior, and making it difficult to conduct security analysis and cost calculation. Summary of the Invention

[0012] The purpose of this invention is to address the above-mentioned shortcomings by proposing a multi-tenant API key authentication and resource isolation system in a containerized environment. This system achieves deep integration of API authentication and container resource control, establishes a dynamic resource quota management mechanism based on tenant identity, provides fine-grained API permission control and resource usage restrictions, supports multi-layered security isolation and malicious behavior protection, and enables comprehensive tenant behavior monitoring and resource usage auditing.

[0013] The present invention specifically adopts the following technical solution: 1. A multi-tenant API key authentication and resource isolation system in a containerized environment, characterized by comprising an authentication and authorization layer, a resource management and control layer, and a security isolation layer; The authentication and authorization layer includes a multi-tenant authentication engine, an API key verification submodule, a tenant identity recognition submodule, a permission cascading verification submodule, and a dynamic permission calculation submodule; The multi-tenant authentication engine is used to verify the validity of API keys, identify tenant identities, and calculate the dynamic permission scope of tenants; The API key verification submodule adopts a multi-level verification strategy. First, it verifies the correctness of the key format and the validity of the signature. Then, it checks the validity period and usage status of the key. Finally, it verifies the binding relationship between the key and the request source. The key verification process consists of three levels: The first layer is format and signature verification. The system first checks whether the string format of the API key conforms to the predefined specifications, uses an encryption algorithm to verify the digital signature of the key, and uses the public key to decrypt and verify the integrity of the signature to ensure that the key has not been tampered with. The second layer: validity period and status check, extract timestamp information from the key, compare it with the current system time to determine if it has expired, query the key status database to check if the key has been disabled, revoked or suspended, and verify whether the number of times the key has been used has exceeded the limit. The third layer: source binding verification, obtains network information such as the IP address and user agent of the request, matches it with the source information bound during key registration, and checks whether the request comes from an authorized domain name, IP range or device fingerprint; The tenant identification submodule determines the tenant identity of the requester by parsing the tenant identifier from the API key, loads the basic information of the tenant from the tenant database, and establishes a tenant context object for use in subsequent processing. The permission cascading verification submodule implements multi-dimensional permission verification based on tenant identity, further checking the operation permissions of specific users and verifying whether they can execute specific functions. The dynamic permission calculation submodule dynamically adjusts the permission scope based on the tenant's current status and historical behavior; the resource management layer includes a resource quota manager, a dynamic quota allocation submodule, a real-time usage monitoring submodule, a threshold alarm control submodule, and an elastic scaling submodule; The resource quota manager implements precise resource control based on tenant identity, ensuring that tenants of different levels receive corresponding quality of service guarantees. It uses a priority scheduling algorithm to give higher-level tenants priority in obtaining resource guarantees, and allows lower-level tenants to use idle resources when system resources are sufficient. The dynamic quota allocation submodule dynamically allocates resource quotas such as CPU, memory, network bandwidth, and storage space based on the tenant's service level agreement (SLA) and the current system load. When resources are scarce, it reclaims excess or near-timeout resources according to priority. The real-time monitoring submodule continuously monitors the resource usage of each tenant and transmits monitoring data to the central monitoring server in real time by deploying a lightweight monitoring agent in each container. The threshold alarm control submodule sets multi-level resource usage thresholds. When a tenant's resource usage approaches the quota limit, an alert is issued. When the quota is exceeded, rate limiting or service degradation measures are adopted. The elastic scaling submodule automatically adjusts container resource configuration via the container's API when tenant resource requirements change; The security isolation layer includes a multi-dimensional isolation engine, a container network isolation submodule, a storage space isolation submodule, a process permission isolation submodule, and a system call filtering submodule; The multi-dimensional isolation engine enables deep security isolation between tenants, creating an independent network namespace for each tenant, configuring independent routing tables and firewall rules to prevent mutual interference between tenants and potential security threats. The container network isolation submodule creates an independent virtual network environment and IP address range for each tenant. The storage space isolation submodule allocates independent storage volumes and file system space to each tenant; The process permission isolation submodule restricts the system permissions of processes within the container to prevent malicious processes from breaching the container boundaries; The system call filtering submodule maintains a system call whitelist, allowing only necessary system calls to pass through. It filters system calls from containers at the kernel level, preventing potentially malicious system calls.

[0014] The present invention has the following beneficial effects: Multi-layered security protection, through API authentication, resource isolation, network isolation, system call filtering and other multi-layered protection mechanisms, improves the system's security protection capability by more than 80%, effectively preventing security threats such as container escape, privilege escalation, and data leakage.

[0015] The detection rate of malicious behavior has been improved. The anomaly detection mechanism based on behavior pattern analysis can identify more than 95% of abnormal behaviors, including resource abuse, malicious access, and data theft. The average detection time has been reduced from 10 minutes to 30 seconds.

[0016] Tenant isolation integrity: The multi-dimensional isolation engine ensures complete isolation between tenants, with network traffic isolation rate reaching 100%, storage data isolation rate reaching 100%, and process permission isolation effectiveness reaching 99.9%.

[0017] The dynamic resource allocation accuracy is improved by a dynamic resource allocation mechanism based on tenant identity and real-time needs. Resource utilization is increased by 35%, and resource allocation accuracy reaches over 90%, effectively avoiding resource waste and over-allocation.

[0018] The system boasts a fast and automated elastic scaling response mechanism that can respond to changes in resource demand within 5 minutes, achieving a 95% success rate for scaling up and a 99% safety rate for scaling down, significantly improving the system's resource adaptability.

[0019] Tenant service quality is guaranteed. Differentiated resource quota management ensures that different levels of tenants receive corresponding service quality. VIP tenants have a service availability of 99.99%, while ordinary tenants have an availability of 99.9%, meeting the needs of different levels of business.

[0020] The level of automation has been significantly improved. The system's automated mechanisms, such as automatic authentication, dynamic resource allocation, and secure isolation configuration, reduce the workload of operation and maintenance by 60%, while improving the accuracy and consistency of configuration.

[0021] Enhanced security incident response capabilities, with real-time security monitoring and alarm mechanisms reducing the average response time for security incidents from 2 hours to 15 minutes, and improving security incident handling efficiency by 85%.

[0022] The audit traceability capability is comprehensive, and all-round behavior auditing and log recording provide a complete operational traceability chain. The integrity of audit data reaches 99.9%, meeting compliance requirements and security analysis needs. Attached Figure Description

[0023] Figure 1 This is a diagram illustrating the overall architecture of a multi-tenant API key authentication and resource isolation system. Figure 2 Flowchart for multi-tenant authentication and resource binding; Figure 3 Flowchart for dynamic resource quota adjustment; Figure 4 Flowchart for implementing multidimensional security isolation. Detailed Implementation

[0024] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings and specific examples: Combination Figure 1-4 A multi-tenant API key authentication and resource isolation system in a containerized environment, including an authentication and authorization layer, a resource management layer, and a security isolation layer; The authentication and authorization layer includes a multi-tenant authentication engine, an API key verification submodule, a tenant identity recognition submodule, a permission cascading verification submodule, and a dynamic permission calculation submodule; The multi-tenant authentication engine is used to verify the validity of API keys, identify tenant identities, and calculate the dynamic permission scope of tenants; The API key verification submodule employs a multi-layered verification strategy. First, it verifies the correctness of the key format and the validity of the signature. Then, it checks the key's validity period and usage status. Finally, it verifies the binding relationship between the key and the request source. This module supports multiple key formats, including symmetric encryption keys, asymmetric encryption certificates, and JWT tokens.

[0025] The key verification process consists of three levels: The first layer is format and signature verification. The system first checks whether the string format of the API key conforms to the predefined specifications (such as length, character set, etc.), uses an encryption algorithm (such as HMAC-SHA256 or RSA) to verify the digital signature of the key, and uses the public key to decrypt and verify the integrity of the signature to ensure that the key has not been tampered with. The second layer: validity period and status check, extract timestamp information from the key, compare it with the current system time to determine if it has expired, query the key status database to check if the key has been disabled, revoked or suspended, and verify whether the number of times the key has been used has exceeded the limit. The third layer: source binding verification, obtains network information such as the IP address and user agent of the request, matches it with the source information bound during key registration, and checks whether the request comes from an authorized domain name, IP range or device fingerprint; The tenant identification submodule determines the tenant's identity (usually an encrypted tenant ID) based on the API key information and loads the tenant's basic information from the tenant database, including tenant level, service type, resource quota, and permission scope. This module supports a multi-level tenant system, such as a primary tenant containing multiple sub-tenants, enabling hierarchical management.

[0026] The cascading permission verification submodule implements multi-dimensional permission verification based on tenant identity. This module not only verifies tenant access permissions to specific API interfaces but also verifies operation permissions for specific resource objects, such as publish or subscribe permissions to specific MQTT topics. Permission verification adopts a cascading mode, from tenant-level permissions to user-level permissions, and from functional permissions to resource permissions.

[0027] The dynamic permission calculation submodule dynamically adjusts the permission scope based on the tenant's current status and historical behavior, for example, by implementing time window restrictions, such as the number of API calls per hour or the amount of data transmitted per day.

[0028] The resource management layer includes a resource quota manager, a dynamic quota allocation submodule, a real-time usage monitoring submodule, a threshold alarm control submodule, and an elastic scaling submodule.

[0029] The resource quota manager implements precise resource control based on tenant identity, ensuring that tenants of different levels receive corresponding quality of service guarantees. Using a priority scheduling algorithm, higher-level tenants are given priority in resource guarantees, while lower-level tenants are allowed to use idle resources when system resources are sufficient.

[0030] The dynamic quota allocation submodule dynamically allocates resource quotas such as CPU, memory, network bandwidth, and storage space based on the tenant's Service Level Agreement (SLA) and the current system load. This module uses a priority scheduling algorithm, where higher-level tenants are given priority in resource guarantees when resources are scarce, while lower-level tenants can use idle resources when resources are plentiful.

[0031] The real-time monitoring submodule continuously monitors the resource usage of each tenant, including metrics such as real-time CPU utilization, memory usage, network I / O traffic, and storage read / write speed. This module achieves second-level resource usage data collection by deploying a monitoring agent within the container, and transmits the monitoring data to the central monitoring server in real time by deploying a lightweight monitoring agent program in each container.

[0032] The threshold alarm control submodule sets multi-level resource usage thresholds, such as: alert (75%), warning (85%), and critical (95%). When a tenant's resource usage approaches the quota limit, an alert is issued. When the quota is exceeded, rate limiting or service degradation measures are adopted. This module supports differentiated threshold strategies. For example, the alarm threshold for VIP tenants can be set to 90% of the quota, and for ordinary tenants it can be set to 80%.

[0033] The elastic scaling submodule automatically adjusts container resource configuration via the container's API when tenant resource needs change. This module analyzes tenants' historical usage patterns and current business needs, predicts resource demand trends, and performs resource scaling or reclamation in advance to ensure service quality while improving resource utilization efficiency.

[0034] The security isolation layer includes a multi-dimensional isolation engine, a container network isolation submodule, a storage space isolation submodule, a process permission isolation submodule, and a system call filtering submodule; it also includes independent network namespaces, virtual network interfaces, routing tables, etc. This module achieves complete isolation of network traffic between tenants through Software Defined Network (SDN) technology, while supporting service discovery and communication within tenants.

[0035] The multi-dimensional isolation engine achieves deep security isolation between tenants, creating an independent network namespace for each tenant, configuring independent routing tables and firewall rules, and preventing mutual interference and potential security threats between tenants.

[0036] The container network isolation submodule creates an independent virtual network environment and IP address range for each tenant, including an independent network namespace, virtual network interface card, routing table, etc. This module achieves complete isolation of network traffic between tenants through Software Defined Network (SDN) technology, while supporting service discovery and communication within the tenant.

[0037] The storage isolation submodule allocates independent storage volumes and file system space to each tenant, ensuring complete data isolation between tenants. This module supports various storage backends, including local disks, network storage (NFS), distributed storage (Ceph), etc., and provides data encryption and backup functions.

[0038] The process permission isolation submodule restricts the system permissions of processes within the container to prevent malicious processes from breaching the container boundary. This module adopts the principle of least privilege, granting processes only the necessary system permissions and disabling dangerous system calls and privileged operations.

[0039] The system call filtering submodule filters container system calls using seccomp-bpf technology, maintains a system call whitelist, and only allows essential business system calls to pass through. It uses the BPF (Berkeley Packet Filter) program to filter at the kernel level, blocking potentially malicious system calls. This module's maintenance of the system call whitelist effectively prevents container escape and privilege escalation attacks.

[0040] The system authentication and resource control described in this application are deeply integrated, and API key authentication and container resource control are organically combined to realize an integrated security management model of authentication as authorization and authorization as allocation.

[0041] The system described in this application uses dynamic resource quotas based on tenant identity. It dynamically calculates and adjusts resource quotas based on multiple factors such as tenant identity, service level, and historical behavior to achieve differentiated service quality assurance.

[0042] The multi-dimensional security isolation engine described in this application achieves deep security isolation from multiple dimensions such as network, storage, process, and system calls, ensuring complete independence and security between tenants.

[0043] The system described in this application features intelligent abnormal behavior detection based on machine learning behavior pattern analysis. It can detect and prevent malicious behavior in real time and provide proactive security protection capabilities.

[0044] The system described in this application features a fine-grained cascading permission verification system, with a multi-level permission verification system from the tenant level to the user level and from functional permissions to resource permissions, ensuring the accuracy of permission control.

[0045] The system described in this application employs a multi-tenant authentication algorithm to protect the tenant identification and permission calculation method based on API keys, including technical solutions such as key verification process, permission cascading algorithm, and dynamic permission calculation formula.

[0046] The system described in this application adopts a dynamic resource quota management mechanism to protect the algorithm for dynamically allocating resources based on tenant identity and real-time demand, including quota calculation models, elastic adjustment strategies, priority scheduling algorithms, and other technical implementations.

[0047] The system described in this application adopts a multi-dimensional isolation technology solution, which protects the implementation methods and configuration strategies of multi-dimensional isolation such as network isolation, storage isolation, process isolation, and system call filtering.

[0048] The system described in this application employs security monitoring and anomaly detection algorithms, protecting anomaly detection algorithms based on behavioral pattern analysis, including technical solutions such as feature extraction methods, pattern recognition algorithms, and anomaly scoring mechanisms.

[0049] The system described in this application employs container security hardening methods to protect the security hardening technology of container runtime, including implementation methods such as minimum permission configuration, security policy application, and runtime protection mechanisms.

[0050] The system described in this application adopts an audit log processing mechanism to protect the technical solutions for tenant behavior auditing and log processing, including log collection strategies, data storage formats, query analysis algorithms, and other technical implementations.

[0051] The system described in this application employs authentication performance optimization. API key verification must be completed in milliseconds, requiring optimization of the verification algorithm and caching strategy to avoid authentication becoming a performance bottleneck.

[0052] The system described in this application adopts resource quota accuracy. The calculation of dynamic resource quotas must take into account the overall system load and tenant historical behavior to ensure the fairness and rationality of quota allocation.

[0053] The system described in this application employs isolation integrity verification. The implementation of the multi-dimensional isolation mechanism must undergo rigorous security testing and verification to ensure the integrity and effectiveness of the isolation.

[0054] The system described in this application uses monitoring data processing. The processing of large amounts of monitoring data requires efficient data processing algorithms and storage mechanisms to avoid the monitoring system becoming a performance burden.

[0055] The system described in this application employs fault recovery capabilities. The system must have a robust fault recovery mechanism to ensure that the availability of the overall service is not affected when some components fail.

[0056] Of course, the above description is not intended to limit the present invention, and the present invention is not limited to the examples given above. Any changes, modifications, additions or substitutions made by those skilled in the art within the scope of the present invention should also fall within the protection scope of the present invention.

Claims

1. A multi-tenant API key authentication and resource isolation system in a containerized environment, characterized in that, This includes an authentication and authorization layer, a resource management layer, and a security isolation layer; The authentication and authorization layer includes a multi-tenant authentication engine, an API key verification submodule, a tenant identity recognition submodule, a permission cascading verification submodule, and a dynamic permission calculation submodule; The multi-tenant authentication engine is used to verify the validity of API keys, identify tenant identities, and calculate the dynamic permission scope of tenants; The API key verification submodule adopts a multi-level verification strategy. First, it verifies the correctness of the key format and the validity of the signature. Then, it checks the validity period and usage status of the key. Finally, it verifies the binding relationship between the key and the request source. The key verification process consists of three levels: The first layer is format and signature verification. The system first checks whether the string format of the API key conforms to the predefined specifications, uses an encryption algorithm to verify the digital signature of the key, and uses the public key to decrypt and verify the integrity of the signature to ensure that the key has not been tampered with. The second layer: validity period and status check, extract timestamp information from the key, compare it with the current system time to determine if it has expired, query the key status database to check if the key has been disabled, revoked or suspended, and verify whether the number of times the key has been used has exceeded the limit. The third layer: source binding verification, obtains network information such as the IP address and user agent of the request, matches it with the source information bound during key registration, and checks whether the request comes from an authorized domain name, IP range or device fingerprint; The tenant identification submodule determines the tenant identity of the requester by parsing the tenant identifier from the API key, loads the basic information of the tenant from the tenant database, and establishes a tenant context object for use in subsequent processing. The permission cascading verification submodule implements multi-dimensional permission verification based on tenant identity, further checking the operation permissions of specific users and verifying whether they can execute specific functions. The dynamic permission calculation submodule dynamically adjusts the permission scope based on the tenant's current status and historical behavior; the resource management layer includes a resource quota manager, a dynamic quota allocation submodule, a real-time usage monitoring submodule, a threshold alarm control submodule, and an elastic scaling submodule; The resource quota manager implements precise resource control based on tenant identity, ensuring that tenants of different levels receive corresponding quality of service guarantees. It uses a priority scheduling algorithm to give higher-level tenants priority in obtaining resource guarantees, and allows lower-level tenants to use idle resources when system resources are sufficient. The dynamic quota allocation submodule dynamically allocates resource quotas such as CPU, memory, network bandwidth, and storage space based on the tenant's service level agreement (SLA) and the current system load. When resources are scarce, it reclaims excess or near-timeout resources according to priority. The real-time monitoring submodule continuously monitors the resource usage of each tenant and transmits monitoring data to the central monitoring server in real time by deploying a lightweight monitoring agent in each container. The threshold alarm control submodule sets multi-level resource usage thresholds. When a tenant's resource usage approaches the quota limit, an alert is issued. When the quota is exceeded, rate limiting or service degradation measures are adopted. The elastic scaling submodule automatically adjusts container resource configuration via the container's API when tenant resource requirements change; The security isolation layer includes a multi-dimensional isolation engine, a container network isolation submodule, a storage space isolation submodule, a process permission isolation submodule, and a system call filtering submodule; The multi-dimensional isolation engine enables deep security isolation between tenants, creating an independent network namespace for each tenant, configuring independent routing tables and firewall rules to prevent mutual interference between tenants and potential security threats. The container network isolation submodule creates an independent virtual network environment and IP address range for each tenant. The storage space isolation submodule allocates independent storage volumes and file system space to each tenant; The process permission isolation submodule restricts the system permissions of processes within the container to prevent malicious processes from breaching the container boundaries; The system call filtering submodule maintains a system call whitelist, allowing only necessary system calls to pass through. It filters system calls from containers at the kernel level, preventing potentially malicious system calls.

Images