Network traffic lightweight security detection method based on eBPF and zero-trust policy orchestration

Abstract

The invention relates to a network traffic lightweight security detection method based on eBPF and zero-trust policy orchestration, and belongs to the fields of cloud computing, container security, network function virtualization and zero-trust architecture. The method comprises the following steps of node initialization, eBPF byte code addition and verification, zero copy annular buffer area construction, feature extraction and real-time monitoring, based on the compression decision tree, efficient security detection, event reporting and compression, zero-trust strategy engine, zero-trust strategy arrangement and issuing, remote measurement and zero-trust alarm, and adaptive learning and model updating are realized. According to the invention, fine-grained control of east-west and north-south network traffic in a container cluster is realized, resource overhead in a security filtering process is reduced, influence on service performance is reduced, compatibility of the scheme to different kernel versions and different container arrangement platforms is enhanced, and high requirements of enterprises for container network security are met.

Description

Technical Field

[0001] This invention belongs to the fields of cloud computing, container security, network function virtualization (NFV) and zero trust architecture, and specifically relates to a lightweight security detection method for network traffic based on eBPF and zero trust policy orchestration. Background Technology

[0002] With the increasing adoption of microservice architecture and DevOps practices, containerized deployment density is constantly increasing. In the era of traditional virtual machines, running 10-20 virtual machines on a single physical machine was considered high density; however, in container scenarios, a single host machine may run hundreds or even thousands of Pods, leading to an exponential increase in east-west traffic. Existing security solutions mainly focus on the north-south boundary, lacking visibility and control over east-west traffic, making it easy for attackers to use as a "hidden channel" for lateral movement. While eBPF / XDP technology can provide high-performance kernel-level packet filtering, its development threshold is high, debugging is difficult, and it has strict kernel version requirements, making it difficult to implement in existing CentOS 7 / 8 production environments. Service mesh achieves zero trust through sidecar proxies, but introduces an additional 20%-40% CPU usage and 2-5ms latency, and is strongly coupled with Istio CRDs, making it unacceptable for low-latency transactional services. Existing user-space solutions such as Suricata AF_PACKET and OVS-DPDK either require DPDK large page memory or root privileges, violating the principle of least privilege and conflicting with cgroup v2's resource limitation model.

[0003] Therefore, a security filtering scheme with the design goals of "five no's" is urgently needed: first, it should not intrude into the kernel; second, it should not introduce a sidecar; third, it should not modify the application image; fourth, it should not depend on special hardware; and fifth, it should not affect resource quotas. Summary of the Invention (a) Technical problems to be solved The technical problem this invention aims to solve is how to provide a lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration, in order to address the issues that existing user-space solutions such as Suricata AF_PACKET and OVS-DPDK either require DPDK large page memory or root privileges, violating the principle of least privilege and conflicting with the resource limitation model of cgroup v2.

[0004] (II) Technical Solution To address the aforementioned technical problems, this invention proposes a lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration. This method includes the following steps: Step 1: Node Initialization: Complete image building, secure mounting of shared libraries, and daemon process configuration to provide a stable operating environment for subsequent processes; Step 2: eBPF bytecode loading and verification: This step ensures the secure loading of eBPF bytecode, laying the foundation for traffic collection and guaranteeing the compatibility of the solution with different kernel versions. Step 3: Zero-copy ring buffer construction: Efficient traffic collection is achieved through a zero-copy ring buffer, while an authentication mechanism is introduced to ensure the security of the collection process, and resource quotas are dynamically adapted without affecting business operations; Step 4: Feature Extraction and Real-time Monitoring: Complete the feature analysis and zero-trust score calculation of network traffic, and achieve efficient security detection based on compressed decision trees; Step 5: Event Reporting and Compression: Achieve efficient reporting of abnormal events, ensure the security and traceability of event transmission, and meet compliance requirements; Step 6: Zero Trust Policy Engine: Implements identity-based dynamic access control, ensuring continuous verification of network communication and the principle of least privilege through fine-grained trust scoring and automated policy enforcement; Step 7: Zero Trust Policy Orchestration and Deployment: Implement declarative orchestration and flexible deployment of zero trust policies through Kubernetes CRDs to ensure the security and flexibility of policy updates; Step 8: Telemetry and Zero Trust Alarms: Real-time collection of zero trust indicators and multi-level alarms to help operations and maintenance personnel keep abreast of network security status and respond quickly to security incidents; Step 9: Adaptive Learning and Model Update: Through machine learning, the zero-trust model is adaptively optimized to improve threat detection capabilities, while supporting zero-disruption model updates to ensure business continuity.

[0005] (III) Beneficial Effects This invention proposes a lightweight network traffic security detection method based on eBPF and zero-trust policy orchestration. Compared with existing technologies, this invention has the following significant advantages: 1. Lightweight and efficient: It adopts a three-layer decoupled architecture of "zero-trust detection engine layer + zero-trust policy orchestration layer + zero-trust telemetry management layer", with CPU overhead and memory usage far lower than traditional service mesh solutions, perfectly adapting to high-concurrency, low-latency business scenarios. 2. Strong compatibility: Through CO-RE relocation technology, it achieves compatibility with kernel versions 3.10 to 6.x, without the need to upgrade or modify the kernel, and can be directly deployed in existing CentOS 7 / 8 production environments, reducing enterprise migration costs. 3. Dynamic and flexible: It supports three release modes: canary, rollback, and canary deployment. Policies can be declaratively distributed through Kubernetes CRDs, and the policy rollback time is ≤5 seconds, enabling rapid response to changes in business and security requirements. 4. Low intrusion: The entire process does not introduce sidecars, modify application images, depend on special hardware, or affect resource quotas, meeting the "five no's" design goal and minimizing interference with existing business deployment and operation. Attached Figure Description

[0006] Figure 1 This is a flowchart of the traffic security detection process based on eBPF and zero-trust policy orchestration of the present invention; Figure 2 This is a diagram of the three-layer decoupling architecture of the present invention. Detailed Implementation

[0007] To make the objectives, contents, and advantages of the present invention clearer, the specific embodiments of the present invention will be described in further detail below with reference to the accompanying drawings and examples.

[0008] This invention relates to the fields of cloud computing, container security, network function virtualization (NFV), and zero-trust architecture, specifically to a lightweight security detection method for fine-grained, low-overhead, and dynamically orchestratable east-west and north-south network traffic in a Linux container orchestration platform.

[0009] The purpose of this invention is to provide a lightweight security detection method for container network traffic based on eBPF and zero-trust policy orchestration, so as to achieve fine-grained control over east-west and north-south network traffic in container clusters, reduce resource overhead in the security filtering process, reduce the impact on business performance, and enhance the compatibility of the solution with different kernel versions and different container orchestration platforms, thereby meeting the high requirements of enterprises for container network security.

[0010] To address the aforementioned technical problems, this invention proposes a method for selecting the optimal path for data exchange in cross-network scenarios, which includes the following steps: Step 1: Node Initialization: Complete image building, secure mounting of shared libraries, and daemon process configuration to provide a stable operating environment for subsequent processes; Step 2: eBPF bytecode loading and verification: This step ensures the secure loading of eBPF bytecode, laying the foundation for traffic collection and guaranteeing the compatibility of the solution with different kernel versions. Step 3: Zero-copy ring buffer construction: Efficient traffic collection is achieved through a zero-copy ring buffer, while an authentication mechanism is introduced to ensure the security of the collection process, and resource quotas are dynamically adapted without affecting business operations; Step 4: Feature Extraction and Real-time Monitoring: Complete the feature analysis and zero-trust score calculation of network traffic, and achieve efficient security detection based on compressed decision trees; Step 5: Event Reporting and Compression: Achieve efficient reporting of abnormal events, ensure the security and traceability of event transmission, and meet compliance requirements.

[0011] Step 6: Zero Trust Policy Engine: Implements identity-based dynamic access control, ensuring continuous verification of network communication and the principle of least privilege through fine-grained trust scoring and automated policy enforcement; Step 7: Zero Trust Policy Orchestration and Deployment: Implement declarative orchestration and flexible deployment of zero trust policies through Kubernetes CRDs to ensure the security and flexibility of policy updates.

[0012] Step 8: Telemetry and Zero Trust Alarms: Real-time collection of zero trust indicators and multi-level alarms help operations and maintenance personnel to keep abreast of network security status and respond quickly to security incidents.

[0013] Step 9: Adaptive Learning and Model Update: This step uses machine learning to achieve adaptive optimization of the zero-trust model, improving threat detection capabilities, while supporting zero-disruption model updates to ensure business continuity.

[0014] Example 1: This invention relates to the fields of cloud computing, container security, network function virtualization (NFV), and zero-trust architecture, specifically to a lightweight security detection method for fine-grained, low-overhead, and dynamically orchestratable east-west and north-south network traffic in a Linux container orchestration platform.

[0015] The purpose of this invention is to provide a lightweight security detection method for container network traffic based on eBPF and zero-trust policy orchestration, so as to achieve fine-grained control over east-west and north-south network traffic in container clusters, reduce resource overhead in the security filtering process, reduce the impact on business performance, and enhance the compatibility of the solution with different kernel versions and different container orchestration platforms, thereby meeting the high requirements of enterprises for container network security.

[0016] This invention relates to the fields of cloud computing, container security, Network Functions Virtualization (NFV), and zero-trust architecture. Specifically, it relates to a lightweight security detection method for fine-grained, low-overhead, and dynamically orchestratable east-west and north-south network traffic in a Linux container orchestration platform. The purpose of this invention is to provide a lightweight security detection method for container network traffic based on eBPF and zero-trust policy orchestration, enabling fine-grained control over east-west and north-south network traffic in container clusters, reducing resource overhead in the security filtering process, minimizing the impact on business performance, and enhancing the compatibility of the solution with different kernel versions and container orchestration platforms, thus meeting the high demands of enterprises for container network security.

[0017] To address the lack of visibility and control over east-west traffic in container networks, which makes them vulnerable to becoming "covert channels" for attackers to move laterally, this invention proposes a lightweight security detection method for container network traffic based on eBPF and zero-trust policy orchestration. The technical approach is as follows: Step 1: Node Initialization: Complete image building, secure mounting of shared libraries, and daemon process configuration to provide a stable operating environment for subsequent processes; Step 2: eBPF bytecode loading and verification: This step ensures the secure loading of eBPF bytecode, laying the foundation for traffic collection and guaranteeing the compatibility of the solution with different kernel versions. Step 3: Zero-copy ring buffer construction: Efficient traffic collection is achieved through a zero-copy ring buffer, while an authentication mechanism is introduced to ensure the security of the collection process, and resource quotas are dynamically adapted without affecting business operations; Step 4: Feature Extraction and Real-time Monitoring: Complete the feature analysis and zero-trust score calculation of network traffic, and achieve efficient security detection based on compressed decision trees; Step 5: Event Reporting and Compression: Achieve efficient reporting of abnormal events, ensure the security and traceability of event transmission, and meet compliance requirements.

[0018] Step 6: Zero Trust Policy Engine: Implements identity-based dynamic access control, ensuring continuous verification of network communication and the principle of least privilege through fine-grained trust scoring and automated policy enforcement; Step 7: Zero Trust Policy Orchestration and Deployment: Implement declarative orchestration and flexible deployment of zero trust policies through Kubernetes CRDs to ensure the security and flexibility of policy updates.

[0019] Step 8: Telemetry and Zero Trust Alarms: Real-time collection of zero trust indicators and multi-level alarms help operations and maintenance personnel to keep abreast of network security status and respond quickly to security incidents.

[0020] Step 9: Adaptive Learning and Model Update: This step uses machine learning to achieve adaptive optimization of the zero-trust model, improving threat detection capabilities, while supporting zero-disruption model updates to ensure business continuity.

[0021] like Figure 1 As shown, the above technical approach can build a lightweight security detection method for container network traffic, providing a new approach for the development of traffic security detection products and the enhancement of container network security in such scenarios.

[0022] The above technical approach will be explained in detail below.

[0023] Step 1: Node Initialization Node initialization is the foundational preparation stage for the implementation of the solution. It mainly involves image building, secure mounting of shared libraries, and configuration of daemons to provide a stable operating environment for subsequent processes.

[0024] (1) DaemonSet image construction The image is built using a multi-stage Dockerfile: the first stage is based on the "golang:1.22-alpine" environment, which compiles the nftiny-daemon daemon and the GNN inference microservice; the second stage is based on the "distroless / static" image, which is a streamlined image to remove redundant dependencies and compress the final image size to less than 50MB, thereby reducing resource consumption.

[0025] The image pre-embeds the "libnftiny.so" shared library and the eBPF bytecode file "nftiny.bpf.o" (less than 80KB after CO-RE relocation table compression) to ensure that core components can be directly called after the image is deployed. The "libnftiny.so" shared library uses musl static linking and is less than 2MB after stripping. "nftiny.bpf.o" is less than 80KB after CO-RE relocation table compression.

[0026] (2) Secure mounting of InitContainer The shared library "libnftiny.so" is mounted in read-only mode via HostPath " / opt / nftiny / lib" to prevent malicious tampering and ensure component security. The user group is set to nobody ("fsGroup: 65534") to ensure that the shared library has read-only permissions (0444) after mounting, preventing malicious tampering.

[0027] (3) systemd daemon configuration When a node starts for the first time, DaemonSet automatically creates the system service unit " / etc / systemd / system / nftiny-daemon.service". The configuration includes the automatic restart field "Restart=always" and the restart interval field "RestartSec=5s" to ensure that nftiny-daemon can resume operation within 5 seconds after an abnormal node restart, thus guaranteeing service continuity.

[0028] Step 2: eBPF bytecode loading and verification This step enables the secure loading of eBPF bytecode, laying the foundation for traffic collection while ensuring the compatibility of the solution with different kernel versions.

[0029] (1) CO-RE repositioning Compilation phase: The compilation parameters "clang -target bpf -g -O2 -mcpu=v3" generate CO-RE relocation information for the eBPF bytecode, recording the offsets and type mappings of kernel fields. Runtime phase: The libbpf library reads the kernel type information library file " / sys / kernel / btf / vmlinux" and automatically performs relocation adaptation for over 40 kernel fields, such as task_struct->cgroups, achieving compatibility with kernel versions 3.10 to 6.x without requiring separate bytecode compilation for different kernel versions.

[0030] (2) Real-time verification Before loading the eBPF bytecode, the "bpf_prog_test_run" interface provided by libbpf is used to perform 10,000 loop tests to simulate bytecode execution under different traffic scenarios, detect the existence of infinite loops, illegal memory access, and other issues, and ensure the safety and reliability of the bytecode. If the test fails, it automatically falls back to the user-space bypass detection mode to avoid business interruption due to eBPF loading failure and ensure business continuity.

[0031] Step 3: Constructing a zero-copy circular buffer This step achieves efficient traffic collection through a zero-copy ring buffer, while introducing an authentication mechanism to ensure the security of the collection process and dynamically adapting resource quotas so as not to affect business operations.

[0032] (1) RX / TX dual-ring mapping Based on the eBPF MAP_TYPE_RINGBUF type, two circular buffers, RX for receiving and TX for sending, are created to collect network packets flowing into and out of the container, respectively. Before the mapping is established, the "bpf_map_update_elem" function is called to register an identity verification hook. This hook verifies whether the process accessing the buffer holds a valid kernel-assigned unique process identifier (BPF cookie), allowing only legitimate processes to access the buffer and preventing malicious containers from stealing traffic data through brute-force mapping.

[0033] (2) Quota perception The nftiny-daemon process reads the cgroup v2 CPU quota limit "cpu.max" and memory quota limit "memory.max" configurations in real time and dynamically adjusts the size of the circular buffer block according to the resource quota. The calculation formula is "block_size = min(1MB, memory.max / 1024)". This dynamic adjustment mechanism ensures that the circular buffer does not consume too much of the application container's resource quota, avoiding impact on application performance and meeting the design goal of "not affecting resource quota".

[0034] (3) Memory locking The function "mlockall(MCL_CURRENT|MCL_FUTURE)" is called to lock the memory pages of the circular buffer in physical memory, preventing buffer data from being swapped out to disk due to system memory shortage and avoiding increased latency in traffic collection caused by disk I / O. The "memory.high" configuration in cgroup v2 limits the resident memory RSS of the nftiny-daemon daemon to no more than 200MB, further controlling resource consumption and ensuring the memory usage requirements of the business containers.

[0035] Step 4: Feature Extraction and Real-time Detection This step completes the feature analysis of network traffic and the calculation of zero-trust scores, and achieves efficient security detection based on compressed decision trees.

[0036] (1) Fast parsing of protocol stack It incorporates a lightweight protocol parser with optimized parsing logic for different protocol types: for TCP / UDP protocols, port identification is completed by parsing only the first 20 bytes of the header; for HTTP / 2 protocols, a static table + QPACK decoding technology is used, greatly reducing parsing latency and quickly extracting L7 features such as protocol version, request path, and response code. Through efficient protocol parsing, it provides accurate traffic characteristic data for subsequent threat detection and security filtering, while avoiding the impact of excessive parsing time on overall filtering performance.

[0037] (2) Compressed decision tree execution The decision tree node is designed to be 8 bytes in size: the high 48 bits are a rule bitmap, such as filtering rules for storage ports, protocols, and IP ranges, and the low 16 bits are the child node offsets. This compact data structure reduces memory usage and access frequency. The "__builtin_bswap64" function is called to perform big-endian / little-endian byte order conversion, ensuring compatibility on different CPU architectures. At the same time, rule matching for a single node can be completed with a single memory access, significantly improving the filtering efficiency of the decision tree.

[0038] (3) Abnormality scoring For network events that hit "suspicious" nodes such as those with abnormally high-frequency requests in the decision tree, a threat score is calculated using the formula "score = base_score × entropy_penalty", where base_score is the base threat score for the rule, and entropy_penalty is the traffic entropy penalty coefficient. Higher entropy values ​​indicate more irregular traffic, resulting in a larger penalty coefficient. A scoring threshold is set: when the score ≥ 0.85, the event is considered high-risk and immediately reported to the user-space daemon; when the score < 0.85, a 30-second sliding window is used for secondary aggregation, statistically analyzing the event frequency and feature changes within the window to avoid misjudgments due to single, occasional events and reduce the false alarm rate.

[0039] Step 5: Event Reporting and Compression This step enables efficient reporting of abnormal events, ensures the security and traceability of event transmission, and meets compliance requirements.

[0040] (1) Multiplexed channel Each CPU core is allocated a dedicated 2MB perf buffer to store exception events processed by that core, avoiding lock contention caused by cross-core event transmission and improving event storage efficiency. The nftiny-daemon daemon adopts a level-triggered mode, batch reading perf buffer events from all CPU cores. A single system call can process 1024 events, reducing the number of system calls and lowering CPU overhead.

[0041] (2) protobuf compression The event data is serialized using the proto3 protocol and the gogoprotobuf library, simplifying the field structure and reducing the average size of a single exception event to less than 50 bytes, significantly reducing data transmission volume. The Snappy streaming compression algorithm is enabled to compress the serialized event data, achieving a compression rate of up to 70%, which greatly saves network bandwidth, making it particularly suitable for cross-node and cross-cluster event reporting scenarios.

[0042] Step Six: Zero Trust Policy Engine This step implements identity-based dynamic access control, ensuring continuous verification and the principle of least privilege for network communication through fine-grained trust scoring and automated policy enforcement.

[0043] (1) Identity tag parsing Extract predefined business identity tags from the Pod annotation `nftiny.io / identity`, supporting multi-level identity separators such as ` / ` or `.`. If the annotation is missing, it automatically falls back to generating a default identity identifier using a combination of `ServiceAccount` and `Namespace`, in the specified format. <namespace> : <serviceaccount>This ensures that all workloads have a traceable identity context.

[0044] (2) Dynamic trust scoring The trust score (T) is initially set at 100 points and is dynamically adjusted based on real-time behavior. 10 points will be deducted for each abnormal event that occurs; Cross-node communication deducts 5 points, and cross-cluster communication network distance penalty deducts 10 points; When T < 60, an "isolation" action is automatically triggered, dropping data packets and recording audit events. When T = 60–80, a "rate limit" is triggered. When T > 80, normal passage is allowed. The score is recalculated every 5 seconds and supports a smooth decay mechanism, recovering 5 points per minute.

[0045] Strategy Conflict Resolution An optimistic locking mechanism is implemented using the generation field of Kubernetes CRDs to ensure data consistency during concurrent policy updates. In case of conflicts, policies are automatically merged according to the "least privilege" principle. If both allow and deny rules exist, the deny rule is prioritized, and a detailed conflict log containing fields such as policy ID, conflict fields, and timestamps is generated and written to a Kubernetes Event. This log is then linked to the original policy CRD resource for auditing and tracing by the security team.

[0046] Step 7: Orchestration and Deployment of Zero Trust Policy This step implements declarative orchestration and flexible deployment of zero-trust policies using a Kubernetes CRD (named NftinyPolicy), with a Policy Controller deployed on the management plane as the core driving component. This controller continuously monitors CRUD events on the NftinyPolicy CRD resource on the Kubernetes API Server and distributes the verified and transformed policies to the nftiny-daemon proxy on all nodes in the data plane, thus ensuring the security and flexibility of policy updates.

[0047] (1) CRD structure ```yaml apiVersion: security.nftiny.io / v1alpha1 kind: NftinyPolicy metadata: name: deny-dns-tunnel spec: selector: matchLabels: {app: gateway} rules: - proto: UDP dstPort: 53 action: RATE_LIMIT rate: 100pps ttlSeconds: 300 ``` (2) Canary Release The policy controller integrates the Argo Rollouts API and implements a canary deployment process by creating a Canary ReplicaSet. Initially, the policy is only applied to 10% of the target Pods, reducing the risk that a full deployment of a new policy may bring. Monitor the Prometheus policy execution error count metric "nftiny_policy_error_total" in real time. If this metric is 0 for 2 consecutive minutes, it indicates that the policy is running normally and the policy will be automatically published to all target Pods. If an error is detected, immediately pause the publication and trigger an alarm to facilitate troubleshooting by operations and maintenance personnel.

[0048] (3) Second-level rollback The policy controller maintains the 10 most recent policy versions. When it receives the rollback command "kubectl rollout undo", it can re-enable the previous policy definition within 3 seconds via the Kubernetes API Server, quickly fixing security issues or business failures caused by policy configuration errors.

[0049] Step 8: Telemetry and Zero-Trust Alarms This step enables real-time collection of zero-trust metrics and multi-level alerts, helping operations and maintenance personnel to promptly grasp the network security status and quickly respond to security incidents.

[0050] (1) Indicator exposure The following core metrics are exposed through the built-in Prometheus exporter: nftiny_allowed_total: The total number of network connections allowed by the policy engine, grouped by identity and namespace tags; nftiny_dropped_total: The total number of connections dropped due to policy rejection or insufficient trust score, grouped by the identity and rule_id labels; nftiny_latency_ms: The number of milliseconds that the strategy engine takes to process a request, and it includes the P50, P90, and P99 quantiles.

[0051] (2) Alarm rules The alarm engine defines two levels of alarm rules based on PromQL and connects to multiple notification channels: When rate(nftiny_dropped_total[5m]) / rate(nftiny_allowed_total[5m]+nftiny_dropped_total[5m])>0.05, a PagerDuty emergency alert is triggered, notifying a security engineer to intervene and investigate; When avg_over_time(nftiny_latency_ms[1m])>2, a DingTalk group robot notification is triggered to remind maintenance personnel to pay attention to performance degradation.

[0052] All alert events carry identity, namespace, and associated policy ID information, facilitating quick problem location.

[0053] Step Nine: Adaptive Learning and Model Update This step uses machine learning to achieve adaptive optimization of the zero-trust model, improving threat detection capabilities, while supporting zero-disruption updates to the model and ensuring business continuity.

[0054] (1) Data lake storage Suspicious anomalies identified by the policy engine, including complete metadata and traffic characteristics, are serialized using protobuf and persistently written to the Hudi data lake table in Parquet format. The partition key is the event occurrence time, accurate to the hour. A Spark batch processing task is started daily at 02:00 to retrain the graph neural network (GNN) model based on the past 7 days of data, optimizing identity behavior relationship modeling and achieving a 3.2% improvement in the AUC metric.

[0055] (2) Federated Learning Federated learning across multiple Kubernetes clusters is implemented using the Flower framework: each cluster only uploads model gradients, ensuring data privacy by keeping data within its local machine. A central aggregation server aggregates global gradients every 7 days to generate a new model and writes the model version number to the `modelVersion` field of the Kubernetes CRD. The nftiny-daemon daemon automatically hot-loads the new model by monitoring CRD changes, achieving zero-downtime updates for model iteration without restarting or interrupting business traffic.

[0056] Example 2: A lightweight security detection method for container network traffic based on eBPF and zero-trust policy orchestration, comprising the following steps: Step 1: Node Initialization: Complete image building, secure mounting of shared libraries, and daemon process configuration to provide a stable operating environment for subsequent processes; Step 2: eBPF bytecode loading and verification: This step ensures the secure loading of eBPF bytecode, laying the foundation for traffic collection and guaranteeing the compatibility of the solution with different kernel versions. Step 3: Zero-copy ring buffer construction: Efficient traffic collection is achieved through a zero-copy ring buffer, while an authentication mechanism is introduced to ensure the security of the collection process, and resource quotas are dynamically adapted without affecting business operations; Step 4: Feature Extraction and Real-time Monitoring: Complete the feature analysis and zero-trust score calculation of network traffic, and achieve efficient security detection based on compressed decision trees; Step 5: Event Reporting and Compression: Achieve efficient reporting of abnormal events, ensure the security and traceability of event transmission, and meet compliance requirements.

[0057] Step 6: Zero Trust Policy Engine: Implements identity-based dynamic access control, ensuring continuous verification of network communication and the principle of least privilege through fine-grained trust scoring and automated policy enforcement; Step 7: Zero Trust Policy Orchestration and Deployment: Implement declarative orchestration and flexible deployment of zero trust policies through Kubernetes CRDs to ensure the security and flexibility of policy updates.

[0058] Step 8: Telemetry and Zero Trust Alarms: Real-time collection of zero trust indicators and multi-level alarms help operations and maintenance personnel to keep abreast of network security status and respond quickly to security incidents.

[0059] Step 9: Adaptive Learning and Model Update: This step uses machine learning to achieve adaptive optimization of the zero-trust model, improving threat detection capabilities, while supporting zero-disruption model updates to ensure business continuity.

[0060] Furthermore, a multi-stage Dockerfile is used to build the image, shared libraries are mounted in read-only mode via HostPath, and a systemd daemon is configured to ensure service recovery in case of anomalies.

[0061] Furthermore, kernel version compatibility is achieved through CO-RE relocation technology, and bytecode security verification is performed before loading, with a fallback to user-mode bypass detection mode in case of failure.

[0062] Furthermore, a circular buffer for receiving and sending is created, an authentication mechanism is introduced, and the buffer size is dynamically adjusted according to cgroup v2 resource quotas.

[0063] Furthermore, L7 features are extracted using a lightweight protocol parser, and fast matching is performed based on a compressed decision tree. Threat scoring and aggregation analysis are then conducted on suspicious events.

[0064] Furthermore, an independent event buffer is allocated to each CPU core, epoll is used for batch reading, and protobuf and Snappy compression are used to achieve efficient event reporting.

[0065] Furthermore, identity tags are extracted from Pod annotations, dynamic trust scoring is performed based on real-time behavior, and an optimistic locking mechanism is used to resolve policy conflicts.

[0066] Furthermore, the NftinyPolicy CRD structure is defined to support canary deployment and second-level rollback, enabling flexible policy distribution and secure updates.

[0067] Furthermore, core metrics are exposed through the Prometheus exporter, alarm rules are defined based on PromQL, and multiple notification channels are connected.

[0068] Furthermore, abnormal events are persisted to the data lake, GNN models are trained periodically, and cross-cluster model aggregation and hot updates are achieved through federated learning.

[0069] Beneficial effects: Compared with existing technologies, this invention has the following significant advantages: 1. Lightweight and efficient: It adopts a three-layer decoupled architecture of "zero-trust detection engine layer + zero-trust policy orchestration layer + zero-trust telemetry management layer", with CPU overhead and memory consumption far lower than traditional service mesh solutions, perfectly adapting to high-concurrency and low-latency business scenarios. 2. Strong compatibility: Through CO-RE relocation technology, it achieves compatibility with kernel versions 3.10 to 6.x, without the need to upgrade or modify the kernel, and can be directly deployed in existing CentOS 7 / 8 production environments, reducing enterprise migration costs. 3. Dynamic and flexible: It supports three release modes: canary, rollback, and canary deployment. Policies can be declaratively distributed through Kubernetes CRDs, and the policy rollback time is ≤5 seconds, enabling rapid response to changes in business and security requirements. 4. Low invasiveness: It does not introduce sidecars, modify application images, depend on special hardware, or affect resource quotas, meeting the "five no's" design goal and minimizing interference with existing business deployment and operation.

[0070] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.< / serviceaccount> < / namespace>

Claims

1. A lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration, characterized in that, The method includes the following steps: Step 1: Node Initialization: Complete image building, secure mounting of shared libraries, and daemon process configuration to provide a stable operating environment for subsequent processes; Step 2: eBPF bytecode loading and verification: This step ensures the secure loading of eBPF bytecode, laying the foundation for traffic collection and guaranteeing the compatibility of the solution with different kernel versions. Step 3: Zero-copy ring buffer construction: Efficient traffic collection is achieved through a zero-copy ring buffer, while an authentication mechanism is introduced to ensure the security of the collection process, and resource quotas are dynamically adapted without affecting business operations; Step 4: Feature Extraction and Real-time Monitoring: Complete the feature analysis and zero-trust score calculation of network traffic, and achieve efficient security detection based on compressed decision trees; Step 5: Event Reporting and Compression: Achieve efficient reporting of abnormal events, ensure the security and traceability of event transmission, and meet compliance requirements; Step 6: Zero Trust Policy Engine: Implements identity-based dynamic access control, ensuring continuous verification of network communication and the principle of least privilege through fine-grained trust scoring and automated policy enforcement; Step 7: Zero Trust Policy Orchestration and Deployment: Implement declarative orchestration and flexible deployment of zero trust policies through Kubernetes CRDs to ensure the security and flexibility of policy updates; Step 8: Telemetry and Zero Trust Alarms: Real-time collection of zero trust indicators and multi-level alarms to help operations and maintenance personnel keep abreast of network security status and respond quickly to security incidents; Step 9: Adaptive Learning and Model Update: Through machine learning, the zero-trust model is adaptively optimized to improve threat detection capabilities, while supporting zero-disruption model updates to ensure business continuity.

2. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 1, characterized in that, The first step includes: (1) DaemonSet image construction The image is built using a multi-stage Dockerfile: the first stage is based on the golang-alpine environment, compiling the nftiny-daemon daemon and the GNN inference microservice; the second stage is based on a "distroless / static" streamlined image. The image pre-embeds the "libnftiny.so" shared library and the eBPF bytecode file "nftiny.bpf.o" to ensure that core components can be directly called after the image is deployed; (2) Secure mounting of InitContainer Mount the "libnftiny.so" shared library in read-only mode via HostPath " / opt / nftiny / lib"; set the user group to nobody ("fsGroup: 65534") to ensure that the shared library has read-only permissions (0444) after mounting. (3) systemd daemon configuration When a node starts for the first time, DaemonSet automatically creates the system service unit " / etc / systemd / system / nftiny-daemon.service". It configures the automatic restart field "Restart=always" and the restart interval field "RestartSec=5s" in case of abnormality to ensure that nftiny-daemon can resume operation within 5 seconds after the node restarts abnormally.

3. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 2, characterized in that, The second step includes: During compilation: The compilation parameters "clang -target bpf -g -O2 -mcpu=v3" are used to generate CO-RE relocation information for eBPF bytecode, recording the offset and type mapping relationship of kernel fields; During runtime: The libbpf library reads the kernel type information library file " / sys / kernel / btf / vmlinux" and automatically completes the relocation adaptation of kernel fields to achieve compatibility with kernel versions; Before loading the eBPF bytecode, the "bpf_prog_test_run" interface provided by libbpf is used to perform a loop test to simulate the bytecode operation under different traffic scenarios, detect whether there are infinite loops or illegal memory access problems, and ensure that the bytecode is safe and reliable; if the test fails, it automatically falls back to the user-space bypass detection mode.

4. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 3, characterized in that, The third step includes: Based on the eBPF MAP_TYPE_RINGBUF type, two circular buffers, RX for receiving and TX for sending, are created to collect network packets flowing into and out of the container, respectively. Before the mapping is established, the "bpf_map_update_elem" function is called to register an identity verification hook. This hook verifies whether the process accessing the buffer holds a valid kernel-allocated unique process identifier BPF cookie, and only allows valid processes to access the buffer. The nftiny-daemon process reads the CPU quota limit "cpu.max" and the memory quota limit "memory.max" configuration in real time, and dynamically adjusts the size of the ring buffer block according to the resource quota. The calculation formula is "block_size =min(1MB, memory.max / 1024)". Through this dynamic adjustment mechanism, it is ensured that the ring buffer will not occupy too much of the resource quota of the business container. Calling the "mlockall(MCL_CURRENT|MCL_FUTURE)" function locks the memory pages of the circular buffer in physical memory; the "memory.high" configuration limits the resident memory of the nftiny-daemon daemon process, ensuring the memory usage requirements of the business containers.

5. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 4, characterized in that, The fourth step includes: An embedded lightweight protocol parser optimizes parsing logic for different protocol types: for TCP / UDP protocols, port identification can be completed by parsing only the first 20 bytes of the header; for HTTP / 2 protocols, static table + QPACK decoding technology is used to quickly extract L7 features; The decision tree node is designed to be 8 bytes in size: the high 48 bits are the equal rule bitmap and the low 16 bits are the child node offset. The compact data structure reduces memory usage and access frequency. The "__builtin_bswap64" function is called to perform big-endian / little-endian byte order conversion to ensure compatibility on different CPU architectures, while realizing rule matching of a single node can be completed with a single memory access. For network events with abnormally high frequency of requests in the hit decision tree, calculate their threat score. The scoring formula is "score = base_score × entropy_penalty", where base_score is the basic threat score of the rule and entropy_penalty is the traffic entropy penalty coefficient. The higher the entropy value, the more irregular the traffic, and the larger the penalty coefficient. Set a scoring threshold: when the score is ≥ 0.85, it is judged as a high-risk event and immediately reported to the user-space daemon process; when the score is < 0.85, a 30-second sliding window is entered for secondary aggregation, and the frequency and feature changes of the event within the window are statistically analyzed.

6. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 5, characterized in that, The fifth step includes: Each CPU core is allocated an independent perf buffer to store exception events processed by that core, avoiding lock contention caused by cross-core event transmission; the nftiny-daemon daemon uses a level-triggered mode to read perf buffer events from all CPU cores in batches. The event data is serialized using the proto3 protocol and the gogoprotobuf library, simplifying the field structure so that the average size of a single exception event is less than 50 bytes; the Snappy streaming compression algorithm is enabled to compress the serialized event data.

7. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 6, characterized in that, The sixth step includes: Predefined business identity tags are extracted from the Pod annotation `nftiny.io / identity`, supporting multi-level identity separators. If the annotation is missing, it automatically falls back to the combination of ServiceAccount and Namespace to generate a default identity identifier, in the specified format. <namespace> : <serviceaccount> Ensure that all workloads have a traceable identity context;< / serviceaccount> < / namespace> The trust score T is initially set at 100 points and is dynamically adjusted based on real-time behavior. 10 points will be deducted for each abnormal event that occurs; Cross-node communication deducts 5 points, and cross-cluster communication network distance penalty deducts 10 points; When T < 60, an "isolation" action is automatically triggered, dropping data packets and recording audit events. When T = 60–80, a "rate limit" action is triggered. When T > 80, normal passage is allowed. The score is recalculated every 5 seconds and supports a smooth decay mechanism, recovering 5 points every minute. An optimistic locking mechanism is implemented using the generation field of Kubernetes CRD to ensure data consistency during concurrent policy updates. In case of conflict, policies are automatically merged according to the principle of "least privilege". If both allow and deny rules exist at the same time, the deny rule is preferred. A detailed conflict log containing the policy ID, conflict field, and timestamp field is generated and written to a Kubernetes Event, which is associated with the original policy CRD resource for the security team to audit and trace.

8. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 7, characterized in that, The seventh step includes: The zero-trust policy is implemented through a Kubernetes CRD named NftinyPolicy, which is used as the core driving component. The policy controller is deployed on the management plane. The controller continuously listens for CRUD events of NftinyPolicy CRD resources on the Kubernetes API Server and distributes the verified and transformed policies to all node agents nftiny-daemon in the data plane. The policy controller integrates the Argo Rollouts API and implements a canary deployment process by creating a Canary ReplicaSet, initially applying the policy to only 10% of the target Pods; Monitor the Prometheus policy execution error count metric "nftiny_policy_error_total" in real time. If this metric is 0 for 2 consecutive minutes, it indicates that the policy is running normally and the policy will be automatically published to all target Pods. If an error is detected, immediately stop the publication and trigger an alarm to facilitate the operation and maintenance personnel to troubleshoot the problem. The policy controller maintains the 10 most recent policy versions. When it receives the rollback command "kubectl rollout undo", it will re-enable the previous policy definition within 3 seconds via the Kubernetes API Server, quickly fixing security issues or business failures caused by policy configuration errors.

9. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 8, characterized in that, The eighth step includes: The following core metrics are exposed through the built-in Prometheus exporter: nftiny_allowed_total: The total number of network connections allowed by the policy engine, grouped by identity and namespace tags; nftiny_dropped_total: The total number of connections dropped due to policy rejection or insufficient trust score, grouped by the identity and rule_id labels; nftiny_latency_ms: The number of milliseconds that the strategy engine takes to process a request, and it includes the P50, P90, and P99 quantiles. The alarm engine defines two levels of alarm rules based on PromQL and connects to multiple notification channels: When rate(nftiny_dropped_total) / rate(nftiny_allowed_total+nftiny_dropped_total) > 0.05, a PagerDuty emergency alert is triggered, notifying a security engineer to intervene and investigate. When avg_over_time(nftiny_latency_ms)>2, a DingTalk group robot notification is triggered to remind operations and maintenance personnel to pay attention to performance degradation. All alert events carry identity, namespace, and associated policy ID information, facilitating quick problem location.

10. The lightweight security detection method for network traffic based on eBPF and zero-trust policy orchestration as described in claim 9, characterized in that, The ninth step includes: The strategy engine identifies suspicious anomalies, including complete metadata and traffic characteristics. These are serialized using protobuf and persisted to the Hudi data lake table in Parquet format, with the partition key being the event occurrence time. Spark batch processing tasks are started daily at 02:00 to retrain the graph neural network (GNN) model based on data from the past 7 days, optimizing the modeling of identity and behavior relationships. Federated learning across multiple Kubernetes clusters is achieved using the Flower framework: each cluster only uploads model gradients, ensuring data privacy by keeping the data within its local machine; the central aggregation server aggregates global gradients every 7 days to generate a new model and writes the model version number to the modelVersion field of the Kubernetes CRD; the nftiny-daemon daemon automatically hot-loads the new model by listening for CRD changes, without restarting or interrupting business traffic, achieving zero-downtime updates for model iteration.

Images