Measurement method of Kubernetes network strategy

Abstract

The invention discloses a method for measuring a Kubernetes network strategy, which is characterized in that a system for realizing the method adopts a multi-layer technical architecture, and the omnibearing perception and interception of a network configuration change event are realized by deeply integrating the native AdmissionWebhook and Operator mechanism of Kubernetes; the core of the system comprises an access interception layer, a configuration monitoring layer, a measurement calculation layer and a verification service layer, and closed-loop management from event capture and data processing to credible verification is completed through mutual cooperation. The AdmissionWebhook mechanism is used for intercepting and pre-checking before network strategy resources are applied to a cluster, and it is ensured that each strategy change is verified by a trusted measurement process; the Operator mechanism is responsible for continuously monitoring the change of a CNI plug-in configuration file, and immediately triggering a measurement and verification process once configuration modification is detected; the change of the iptables rule is monitored in real time on each node through a monitoring Agent deployed by Daemon Set, and complete monitoring coverage from an application layer to a system layer is formed.

Description

TECHNICAL FIELD

[0001] The application relates to a Kubernetes network policy measurement method and belongs to the technical field of network security. BACKGROUND

[0002] With the rapid development of cloud native technology and the deepening of enterprise digital transformation, the container orchestration system Kubernetes (k8s) has become the de facto standard for container orchestration and microservice governance. Through the container network interface (CNI) and network policy (NetworkPolicy) mechanism, it provides flexible network isolation and traffic control capabilities for distributed applications. In the Kubernetes container network architecture, network policy is a layer 2 / layer 3 traffic control mechanism based on labels (Label), which defines ingress / egress rules through APIServer, and is converted into host iptables / ipset rules by CNI plugins (such as Calico, Flannel), finally realizing network isolation between pods and between pods and the outside.

[0003] However, with the expansion of application scale and the complexity of deployment environment, especially in multi-tenant cloud environment, edge computing and hybrid cloud architecture, traditional network security protection methods have serious shortcomings. Most existing solutions focus on network traffic monitoring and encryption (such as service mesh, network policy execution), but generally ignore the reliability, integrity and credibility of network policy configuration itself. Once attackers obtain configuration modification capabilities through legitimate privilege escalation or management vulnerabilities, they can tamper with network policy definition YAML files, CNI plugin configuration files or host iptables rules. Such attacks are not only highly concealed and difficult to trace, but also directly lead to the failure of cluster network isolation policies, causing large-scale data leakage or service interruption risks.

[0004] Currently, there are some technical solutions trying to solve the network security problem in Kubernetes environment. For example, the invention patent with publication number CN110661657A, "Network security monitoring method and system for Kubernetes cloud native application", proposes a network security monitoring method for Kubernetes cloud native application, including the steps of initializing system configuration, starting system management interface component, system self-checking and system configuration, request initiation to receiving reply, traffic log and audit component receiving log message, etc. This scheme can effectively monitor the network status of chart application running time by adding traffic transparent proxy in kuberneteschart cloud native application, and discover potential security risks. The system includes proxy synchronization component, management interface component, traffic transparent proxy client, proxy injection component, authorization policy component, traffic log and audit component, quasi-real-time monitoring component, link tracking component and abnormal alarm component. However, the core defect of this scheme is that it mainly focuses on network traffic monitoring and anomaly detection, but lacks verification mechanism for the integrity and credibility of network policy itself. When the network policy configuration file, CNI plug-in configuration or related iptables rules are maliciously tampered with, this system cannot effectively detect and protect. In addition, this scheme relies on proxy injection and traffic interception, which has a certain impact on system performance, and cannot provide credible audit and traceability for network policy changes.

[0005] The invention patent with publication number CN112887290A, "Control method for network security access based on kubernetes", proposes a scheme to manage the life cycle of NetworkPolicy through custom resource objects. This scheme listens to and drives the ServiceRule resource to experience a series of state transitions such as Initial, Created, Updated, Synced, etc. through the cos-access-control component, and finally the weave-npc controller responds to the state changes and calls the WeaveNetCNI plug-in to generate corresponding filtering rules in the iptables of all nodes in the cluster, thereby realizing unified access control across cloud environments. However, the security of this scheme is built on the trust and correctness of CNI plug-in and its control link, and lacks independent verification mechanism for the integrity of policy definition, plug-in configuration and underlying rules.

[0006] Another research result published in 2025, Preventing IPSpoofing in Kubernetes Using eBPF (DOI: 10.32604 / cmc.2025.062628), proposes a PodCA framework based on eBPF technology. This framework deploys eBPF programs on each node through DaemonSet, maintains a Container Network Map in kernel mode to record the legal binding relationship between Pods and IPs, and hooks and verifies the legality of the source IP address when data packets enter and exit the container network interface (veth). It can effectively intercept spoofing attacks with forged source IPs, and achieve near-zero latency detection performance and low resource consumption. However, its protection range is limited to data packet metadata verification, and it cannot handle higher-level configuration security threats such as malicious modification of network policies, tampering of CNI plugin parameters, or illegal changes to iptables rules. In addition, the deployment and maintenance of eBPF programs are complex, and the scheme does not provide configuration change audit tracing function, making it difficult to meet compliance requirements.

[0007] Through in-depth analysis of existing technical solutions, it can be clearly identified that there is a key technical gap in the current Kubernetes network security field. Existing solutions generally focus on network traffic level security protection, and pay insufficient attention to the authenticity verification and integrity protection of network policy configuration. In actual security threat scenarios, attackers often try to obtain configuration modification permissions first, and then use methods such as tampering with network policies, modifying CNI configurations, or adjusting iptables rules to systematically undermine network security boundaries. This type of attack has strong concealment, and traditional traffic monitoring systems are difficult to detect in a timely manner. In addition, existing technical solutions also have obvious shortcomings in the audit tracing ability of network configuration changes. Once a security incident occurs, it is difficult to accurately locate the root cause and assess the impact range. These technical limitations severely restrict the overall effectiveness of the Kubernetes network security protection system, and new technical solutions are needed to fill the gap. SUMMARY

[0008] The present application proposes a method for measuring Kubernetes network policies, aiming to solve the shortcomings of existing Kubernetes network security solutions in network policy authenticity verification, configuration integrity protection, and change auditing. By introducing trust measurement technology, key network configurations such as network policy definitions, CNI plugin configurations, and iptables rules are measured and verified in real time, achieving non-tamperability and trust traceability of network policies, and building a more secure and reliable container network environment.

[0009] The technical scheme adopted by the application is a Kubernetes network policy measurement method. The system implementing the method adopts a multi-level technical architecture, and through deep integration of Kubernetes native AdmissionWebhook and Operator mechanisms, realizes all-round perception and interception of network configuration change events. The core of the system includes an admission interception layer, a configuration monitoring layer, a measurement calculation layer and a verification service layer, which complete the closed-loop management from event capture, data processing to trusted verification through mutual cooperation. The AdmissionWebhook mechanism is used to intercept and pre-check before the network policy resource is applied to the cluster, ensuring that each policy change is verified by the trusted measurement process. The Operator mechanism is responsible for continuously monitoring the changes of the CNI plugin configuration file, and once the configuration modification is detected, the measurement and verification process is triggered immediately. The monitoring agent deployed by DaemonSet monitors the changes of iptables rules in real time on each node, forming complete monitoring coverage from the application layer to the system layer. The specific implementation process of the method is as follows: Step 1: system deployment and data source integration; First, deploy the core components of the measurement system in the target Kubernetes cluster: (1) Deploy the AdmissionWebhook controller in the target cluster. Create a ValidatingWebhookConfiguration resource and configure the rules to intercept the CREATE, UPDATE and DELETE operations of all NetworkPolicy resources in the networking.k8s.io / v1 group.

[0010] (2) Deploy the Operator to monitor the CNI configuration. Operator manages monitoring policies through custom resource definition CRD. Its Pod needs to mount the / etc / cni / net.d directory of the host machine to directly access the CNI configuration file. Key parameters include network segment network.cidr, IP allocation policy ipam, and security policy policy. After the Operator is started, it listens to the changes of KubernetesNode objects and network-related custom resources through the Informer mechanism, and initializes the file system event listener to monitor the target configuration file directory in real time.

[0011] (3) DaemonSet form deployment node monitoring Agent, ensure that each work node runs an agent Pod. The agent Pod must run in privileged mode and mount the host network namespace, PID namespace and / usr / sbin / , / etc / , / var / log system directory to be able to access the iptables, ipset and other commands and rule files completely. The Agent integrates a rule collection module inside, which can choose to execute the iptables-save command periodically or load eBPF programs to capture netfilter rule hook events in real time to achieve efficient and low-overhead monitoring of rule changes.

[0012] Step 2: Event capture and configuration standardization; When each monitoring component detects a configuration change event, it immediately enters the standardization process. When the AdmissionWebhook intercepts a NetworkPolicy operation request, it first extracts the core configuration information of the policy, including the name and namespace in the policy metadata, the label selector rules podSelector and namespaceSelector, the ingress and egress details, and removes all variable fields.

[0013] The Operator detects changes in CNI configuration files through file system event listening and timing polling mechanisms, extracts key configuration parameters such as network CIDR configuration, IPAM settings, network mode configuration and security policy related parameters.

[0014] The node Agent monitors the iptables rule addition, deletion and modification operations in real time, and pays special attention to the rules related to Kubernetes network policy, including KUBE-NWPLCY-* rule chain, KUBE-PODSELECTOR-* chain, custom chain generated by CNI plugin and container network related NAT and FILTER rules. The technical implementation of iptables monitoring uses a combination of iptables-save command periodic snapshot and netlink socket real-time listening. By parsing / proc / net / ip_tables_names to get the current loaded table name, then using iptables-save -t $table to get the complete rule snapshot. For real-time monitoring, the system establishes a netlink socket connection to the kernel's NETLINK_NETFILTER protocol family, listens to NFNLGRP_CONNTRACK_NEW, NFNLGRP_CONNTRACK_UPDATE, NFNLGRP_CONNTRACK_DESTROY events, and captures connection tracking table changes to indirectly monitor rule execution effect.

[0015] Step 3: Trustworthiness measurement hash calculation; The standardized configuration data is sent to the measurement module for processing. For the first occurrence of the configuration, the calculated hash value will be stored as the initial baseline value in the baseline library; for the existing configuration, the new hash value will be compared with the baseline value. The measurement module uses the SM3 algorithm to calculate the hash digest of the network policy configuration, CNI configuration file and iptables rule set.

[0016] Step 4: Integrity verification and abnormal response; The verification service provides a RESTful API interface to receive integrity verification requests. When receiving a verification request, the service first calculates the hash value of the current configuration, and then queries the historical measurement records and configuration baseline values in the baseline library. Compare the current hash value with the baseline value and the historical records: if the current hash is consistent with the baseline value and the latest historical record, it is determined that the configuration is in a trusted state; if the current hash does not match the baseline value but matches a historical record, it indicates that the configuration has been legally changed, but the baseline value needs to be updated, then notify the administrator to review and update the configuration baseline value; if an unauthorized change is detected, i.e. the current hash does not match the baseline value and the historical records, immediately trigger the security alarm mechanism, while supporting automatic rollback to the last verified trusted version. The verification result is output in multiple ways, including generating an audit report of network policy changes, real-time verification status feedback.

[0017] Further, the Webhook service itself is deployed as a separate Deployment, with corresponding Service and certificate Secret to realize mTLS secure communication with the APIServer.

[0018] Further, the egress rule egress details include port, protocol type and IP address segment ipBlock information; Further, the KUBE-NWPLCY-* rule chain is the main chain of network policy; Further, the KUBE-PODSELECTOR-* chain is the Pod selector chain; Further, parse / proc / net / ip_tables_names to get the current loaded table names including filter, nat, mangle, raw.

[0019] Further, in the implementation of step 3, detailed audit logs and reports are generated, recording the time, operator, and measurement results of all measurement operations, providing complete data support for subsequent audit and verification.

[0020] The present application realizes an important change from passive protection to active verification by introducing credibility measurement technology into the field of Kubernetes network policy management. Traditional container network security protection mainly relies on traffic monitoring and anomaly detection, which often discovers problems after an attack occurs, and has obvious hysteresis. The present application can immediately discover and prevent attackers from modifying network policies through real-time verification of network policy configuration integrity, advancing the time window of security protection from post-detection to pre-prevention, and greatly improving the security protection capability of container networks.

[0021] Secondly, the innovative design of a multi-level network configuration monitoring architecture. Traditional container network security monitoring mainly focuses on data plane traffic analysis, and the present application innovatively establishes a three-layer trusted monitoring system covering control plane policy definition, data plane plugin configuration, and execution plane rule implementation. This layered monitoring architecture not only provides comprehensive configuration security protection, but more importantly, establishes a complete traceability chain from policy definition to rule execution, which can accurately identify the root cause of network security policy failure. BRIEF DESCRIPTION OF DRAWINGS

[0022] Figure 1 Kubernetes network policy credibility measurement system architecture diagram.

[0023] Figure 2 Kubernetes network policy credibility measurement flowchart. DETAILED DESCRIPTION

[0024] The present application is described in detail below in conjunction with the drawings and examples.

[0025] Figure 1 Kubernetes network policy credibility measurement system architecture diagram.

[0026] Figure 2 Kubernetes network policy credibility measurement flowchart.

[0027] The technical solution adopted by the present application is a Kubernetes network policy measurement method, and the implementation process of the method is as follows: Process 1: System deployment and data source integration First, deploy the core components of the measurement system in the target Kubernetes cluster: (1) Deploy AdmissionWebhook controller in the target cluster. Create ValidatingWebhookConfiguration resource, configure rules to intercept all network.k8s.io / v1 group NetworkPolicy resource CREATE, UPDATE and DELETE operations. Webhook service itself is deployed as a separate Deployment, configure corresponding Service and certificate Secret (usually automatically managed by tools such as cert-manager) to achieve mTLS secure communication with APIServer (2) Deploy Operator to monitor CNI configuration. Operator manages monitoring strategies through custom resource definition (CRD), its Pod needs to mount the host's / etc / cni / net.d directory to directly access CNI configuration files, key parameters include network.cidr (network segment), ipam (IP allocation strategy), policy (security policy). Operator starts to listen to KubernetesNode objects and network-related custom resource changes through Informer mechanism, at the same time initializes file system event listener (such as based on inotify) to real-time monitor target configuration file directory.

[0028] (3) Deploy node monitoring Agent in the form of DaemonSet, ensure that an Agent Pod runs on each worker node. The Pod must run in privileged mode (privileged:true) and mount the host network namespace, PID namespace, and / usr / sbin / , / etc / , / var / log system directories to be able to access commands and rule files such as iptables, ipset completely. Agent integrates rule collection module internally, which can choose to execute iptables-save command periodically or load eBPF program to capture netfilter rule hook events in real time, to achieve efficient and low-overhead monitoring of rule changes.

[0029] Process 2: Event capture and configuration standardization When each monitoring component detects a configuration change event, it immediately enters a standardized processing flow, which is the key to ensuring consistency of metrics. When the AdmissionWebhook intercepts a NetworkPolicy operation request, it first extracts the core configuration information of the policy, including the name and namespace in the policy metadata, the label selector rule (podSelector and namespaceSelector), the ingress and egress rule details (including port, protocol type, and IP address segment ipBlock), and removes all variable fields (such as metadata.uid, metadata.resourceVersion, metadata.managedFields, creationTimestamp, etc.).

[0030] The Operator detects changes in CNI configuration files (such as 10-calico.conflist) through file system event listening and timing polling mechanisms, extracts key configuration parameters such as network CIDR configuration, IPAM settings, network mode (Overlay / Underlay) configuration, and security policy related parameters.

[0031] The NodeAgent monitors the addition, deletion, and modification of iptables rules in real time, paying special attention to rules related to Kubernetes network policies, including KUBE-NWPLCY-* rule chains (network policy main chain), KUBE-PODSELECTOR-* chains (Pod selector chain), custom chains generated by CNI plugins, and container network related NAT and FILTER rules. The technical implementation of iptables monitoring uses a combination of iptables-save command regular snapshots and netlink socket real-time listening. By parsing / proc / net / ip_tables_names to get the current table name (filter, nat, mangle, raw), and then using iptables-save -t $table to get the complete rule snapshot. For real-time monitoring, the system establishes a netlink socket connection to the kernel's NETLINK_NETFILTER protocol family, listens to events such as NFNLGRP_CONNTRACK_NEW, NFNLGRP_CONNTRACK_UPDATE, NFNLGRP_CONNTRACK_DESTROY, and captures connection tracking table changes to indirectly monitor rule execution results.

[0032] Process 3: Trust metric calculation hash The standardized configuration data is sent to the metric module for processing. For the first occurrence of the configuration, the calculated hash value is stored as an initial baseline value in the baseline library; for the existing configuration, the new hash value is compared with the baseline value. The metric module calculates the hash digest of the network policy configuration, CNI configuration file and iptables rule set using the SM3 algorithm. In this process, detailed audit logs and reports need to be generated to record the time, operator, metric result and other key information of all metric operations, providing complete data support for subsequent audit and verification.

[0033] Process 4: Integrity verification and abnormal response The verification service provides a RESTful API interface to receive integrity verification requests. When a verification request is received, the service first calculates the hash value of the current configuration, and then queries the historical metric records and configuration baseline values in the baseline library. The system compares the current hash value with the baseline value and historical records: if the current hash is consistent with the baseline value and the latest historical record, the configuration is determined to be in a trusted state; if the current hash does not match the baseline value but matches a historical record, it indicates that the configuration has been legally changed, but the baseline value needs to be updated, and the system will notify the administrator to review and update the configuration baseline value; if an unauthorized change is detected (the current hash does not match the baseline value and historical records), the security alarm mechanism is triggered immediately, and automatic rollback to the last verified trusted version is supported. The verification result is output in multiple ways, including generating an audit report of network policy changes, real-time verification status feedback, etc.

[0034] The present application introduces a trusted metric technology into the field of Kubernetes network policy management, realizing an important change from passive protection to active verification.

[0035] Through real-time verification of the integrity of network policy configuration, the present application can immediately discover and prevent attackers from modifying network policies, advancing the time window of security protection from post-detection to pre-prevention, and greatly improving the security protection capability of container networks.

[0036] The present application innovatively establishes a three-layer trusted monitoring system covering control plane policy definition, data plane plugin configuration, and execution plane rule implementation. This layered monitoring architecture not only provides comprehensive configuration security protection, but more importantly, establishes a complete traceability chain from policy definition to rule execution, enabling accurate identification of the root cause of network security policy failure.

Claims

1. A method for measuring Kubernetes network policies, characterized in that: The system implementing this method adopts a multi-layered technical architecture. By deeply integrating Kubernetes' native AdmissionWebhook and Operator mechanisms, it achieves comprehensive awareness and interception of network configuration change events. The core of the system includes an admission interception layer, a configuration monitoring layer, a measurement calculation layer, and a verification service layer. Through mutual cooperation, they complete closed-loop management from event capture and data processing to trusted verification. The AdmissionWebhook mechanism is used to intercept and pre-check network policy resources before they are applied to the cluster, ensuring that every policy change is verified through a trusted measurement process. The Operator mechanism is responsible for continuously monitoring changes to the CNI plugin configuration file. If a configuration change is detected, it triggers the measurement and verification process. The monitoring Agent deployed through DaemonSet monitors changes to iptables rules on each node in real time, forming a complete monitoring coverage from the application layer to the system layer.

2. The Kubernetes network policy measurement method according to claim 1, characterized in that: The specific implementation process of this method is as follows: Step 1: System deployment and data source integration; First, deploy the core components of the metrics system in the target Kubernetes cluster: (1) Deploy the AdmissionWebhook controller in the target cluster; a ValidatingWebhookConfiguration resource needs to be created and rules configured to intercept CREATE, UPDATE and DELETE operations of all NetworkPolicy resources under the networking.k8s.io / v1 group; (2) Deploy Operator to monitor CNI configuration; Operator manages and monitors policies by defining CRD through custom resources. Its Pod needs to mount the / etc / cni / net.d directory of the host machine to directly access the CNI configuration file. Key parameters include network segment network.cidr, IP allocation policy ipam, and security policy policy; After the Operator starts, it listens for changes in KubernetesNode objects and network-related custom resources through the Informer mechanism, and initializes file system event listeners to monitor the target configuration file directory in real time. (3) Deploy the node monitoring agent in DaemonSet form to ensure that an agent Pod runs on each worker node; the agent Pod runs in privileged mode and mounts the host network namespace, PID namespace and the system directories / usr / sbin / , / etc / , and / var / log, and has full access to iptables, ipset commands and rule files; the agent integrates a rule collection module, which can choose to periodically execute the iptables-save command or load the eBPF program to capture netfilter rule hook events in real time; Step 2: Standardize event capture and configuration; When each monitoring component detects a configuration change event, it immediately enters a standardized processing flow. When AdmissionWebhook intercepts a NetworkPolicy operation request, it first extracts the core configuration information of the policy, focusing on the name and namespace in the policy metadata, the podSelector and namespaceSelector rules, the inbound rule ingress and the outbound rule egress details, and removes all variable fields. Operator detects changes to CNI configuration files through file system event listening and timed polling mechanisms, and extracts key configuration parameters such as network CIDR configuration, IPAM settings, network mode configuration, and security policy-related parameters. The node agent monitors iptables rules for addition, deletion, and modification in real time, paying particular attention to rule chains related to Kubernetes network policies, including KUBE-NWPLCY-* rule chains, KUBE-PODSELECTOR-* chains, custom chains generated by CNI plugins, and NAT and FILTER rules related to container networks. The iptables monitoring is implemented using a combination of periodic snapshots via the iptables-save command and real-time listening via netlinksocket. The system obtains the currently loaded table names by parsing / proc / net / ip_tables_names, and then uses iptables-save-t$table to obtain a complete rule snapshot. For real-time monitoring, the system establishes a netlinksocket connection to the kernel's NETLINK_NETFILTER protocol family, listening for NFNLGRP_CONNTRACK_NEW, NFNLGRP_CONNTRACK_UPDATE, and NFNLGRP_CONNTRACK_DESTROY events, capturing changes in the connection tracking table to indirectly monitor the rule execution effect. Step 3: Calculate the hash for the trust metric; The standardized configuration data is sent to the metrics module for processing. For a configuration appearing for the first time, its calculated hash value will be stored in the baseline database as the initial baseline value; for an existing configuration, its new hash value will be compared with the baseline value. The metrics module uses the SM3 algorithm to calculate hash digests of network policy configurations, CNI configuration files, and iptables rule sets; Step 4: Integrity verification and exception response; The verification service provides a RESTful API interface to receive integrity verification requests. When a verification request is received, the service first calculates the hash value of the current configuration, then queries the historical metric records and configuration baseline values ​​in the baseline database. The current hash value is compared with the baseline value and historical records: if the current hash matches the baseline value and the latest historical record, the configuration is determined to be in a trusted state; if the current hash does not match the baseline value but matches a certain historical record, it indicates that the configuration has undergone a legitimate change but the baseline value needs to be updated, so the administrator is notified to review and update the configuration baseline value; if an unauthorized change is detected, i.e., the current hash does not match the baseline value and historical records, a security alarm mechanism is immediately triggered, and automatic rollback to the previous verified trusted version is supported; the verification results are output in multiple ways, including generating an audit report on network policy changes and real-time verification status feedback.

3. The Kubernetes network policy measurement method according to claim 2, characterized in that: The Webhook service itself is deployed as a standalone Deployment, configured with the corresponding Service and certificate Secret to enable secure mTLS communication with the API Server.

4. The Kubernetes network policy measurement method according to claim 2, characterized in that: Outbound rule egress details include port, protocol type, and IP address range ipBlock information.

5. A method for measuring Kubernetes network policies according to claim 2, characterized in that: KUBE-NWPLCY-* rule chain is the main chain for network policies.

6. A method for measuring Kubernetes network policies according to claim 2, characterized in that: The KUBE-PODSELECTOR-* chain is a Pod selector chain.

7. A method for measuring Kubernetes network policies according to claim 2, characterized in that: Parse / proc / net / ip_tables_names to get the names of currently loaded tables, including filter, nat, mangle, and raw.

8. A method for measuring Kubernetes network policies according to claim 2, characterized in that: Step 3 generates detailed audit logs and reports, recording the time, operator, and results of all measurement operations, providing complete data support for subsequent audits and verifications.

Images