Source-linked AI summary
Improving Service Availability in KubeEdge-Based Architectures Using Lightweight Intrusion Detection
Harrol Ndjeudji Kuibou, Mostafa Anouar Ghorab, Mohamed Aymen Saied
TL;DR
Vulnerabilities in container images and attacks on KubeEdge-based systems pose risks to service availability, and the paper examines their effects in edge deployments. It proposes RIDRS, a lightweight rule-based detection mechanism, and reports improved resilience through early detection and mitigation, including eliminated service disruption in multiple scenarios.
Problem
The study examines how container-image vulnerabilities and security attacks affect availability and stability in KubeEdge-based edge systems.
Source: §1 · p. 2Method
The paper proposes RIDRS, a lightweight rule-based intrusion detection mechanism for resource-constrained edge environments.
Source: §8 · p. 19Results
RIDRS significantly improves resilience through early detection and mitigation, effectively eliminating service disruption in multiple scenarios.
Source: §8 · p. 19Takeaways & Limitations
Image vulnerabilities are widespread and unevenly distributed, and critical risks can remain even in seemingly low-risk images.
Source: §8 · pp. 18–19The Raspberry Pi testbed may not represent larger or more heterogeneous deployments, and minor system or measurement variations may affect reported timing metrics.
Source: §6 · p. 18
Abstract
from arXiv · showhide
The increasing adoption of the Internet of Things (IoT) and cloud computing has accelerated the evolution of edge computing paradigms [1]. Industry forecasts estimate that the number of connected IoT devices will reach approximately 50 billion by 2030, following an estimated 38 billion connections by 2025 [34], resulting in an unprecedented growth in data generation. This trend necessitates efficient, scalable, and secure data processing mechanisms at the network edge. Consequently, ensuring the reliable management and protection of IoT applications and devices has become a critical challenge. In this context, KubeEdge extends cloud-native capabilities to edge environments, enabling distributed orchestration while introducing new security concerns. This paper investigates the security of container images in IoT-driven and distributed edge architectures. Specifically, we analyze the impact of major security threats, including Denial of Service (DoS) attacks and malicious container deployments, on the availability and operational stability of KubeEdge-based systems. To address these challenges, we propose a lightweight Recommended Intrusion Detection Rule Set (RIDRS) tailored for resource-constrained edge environments. The proposed approach improves system resilience by enabling timely detection and mitigation of security threats. We define system stability as the ability to maintain consistent operational behavior and to recover autonomously under adversarial conditions. Experimental results demonstrate that RIDRS significantly reduces system downtime and enhances service availability, particularly in scenarios involving code injection and malicious pod deployment attacks.
1 Introduction
KubeEdge brings containerized workloads to resource-constrained edge environments, but compromised images, misconfigurations, and network attacks threaten service availability. The study examines these risks and asks whether lightweight intrusion detection can improve edge-service resilience.
1 Introduction
- Critical applications may require availability exceeding 99.999% uptime, making service continuity a central concern for KubeEdge deployments.The paper notes healthcare, transportation, and industrial automation as examples of critical domains.Source: §1 · p. 2
- Compromised images, outdated dependencies, and supply-chain attacks threaten container security, while edge nodes face resource constraints and physical exposure.The paper cites a 2018 Docker Hub incident involving more than five million downloads of compromised images.Source: §1 · p. 2
- Misconfigured pod policies, unverified images, and insecure orchestration can enable unauthorized execution or node compromise, while cloud–edge communications face interception, hijacking, and DoS.The paper identifies these threats as potential impacts on system performance and reliability.Source: §1 · p. 2
- The study defines stability as predictable behavior and autonomous recovery during security incidents, but does not formally quantify it.Stability is discussed as an indicator of resilience and a direction for future work.Source: §1 · p. 2
- The paper evaluates image vulnerabilities, simulates DoS and code-injection attacks, and asks whether lightweight intrusion detection can improve KubeEdge availability and resilience.Its research questions cover image vulnerabilities, their effects on availability and stability, and the extent to which lightweight detection can help.Source: §1 · p. 3
2 Background
The background describes Kubernetes orchestration and KubeEdge's extension of cloud–edge management. KubeEdge's distributed, resource-constrained setting brings security risks that can affect availability and reliability.
2.1 Kubernetes
- Kubernetes uses a control-plane–worker-node architecture: the control plane manages cluster state and scheduling, while worker nodes run containerized workloads.The control plane uses the API Server, Scheduler, Controller Manager, and etcd; workers run kubelet, a container runtime, Pods, and kube-proxy.Source: §2.1 · pp. 3–4, Figure 1 · p. 4
- Kubernetes supports automated deployment, scaling, and self-healing across clusters [8].These features are presented as foundations of cloud-native systems.Source: §2.1 · pp. 3–4
2.2 KubeEdge
- KubeEdge extends orchestration to constrained edge environments, improving local autonomy and reducing latency while introducing security concerns.Edge nodes face risks including configuration errors, vulnerable images, and supply-chain attacks that can affect availability and reliability.Source: §2.2 · pp. 4–5
- KubeEdge connects CloudCore and EdgeCore through bidirectional messaging, coordinating cloud orchestration with local workload execution and IoT-device interaction.CloudCore manages Pods and devices; EdgeCore handles local applications, metadata, device state, and service interactions.Source: §2.2 · p. 5, Figure 2 · p. 5
3 Related Work
Prior work examines KubeEdge threats, centralized security, availability, and IoT-edge monitoring, but leaves a gap in lightweight, runtime-aware protection suited to edge constraints. The paper presents RIDRS as a decentralized, proactive detection approach and describes it as a proof of concept requiring further large-scale evaluation.
3 Related Work
- KubeEdge security audits and edge-service attack studies characterize threats and availability impacts, but do not establish practical runtime mitigation under edge constraints.The cited audit is diagnostic, while the attack study focuses mainly on attack characterization.Source: §3 · p. 6
- Centralized validation may create a single control point that becomes a bottleneck and point of failure; availability-controller assumptions of sufficient computational resources and stable infrastructure limit applicability in resource-constrained edge contexts.Vayghan et al. reported recovery-time improvements ranging from 55% to 99%, but their solution adds system complexity and overhead and remains reactive, operating after failures rather than preventing them.Source: §3 · pp. 6–7
- Empirical work finds Kubernetes self-healing does not guarantee high availability, with outages after node or Pod failures lasting longer than expected.A related controller reports recovery-time improvements of 55% to 99% while adding complexity and overhead.Source: §3 · pp. 6–7
- IoT-edge coordination and monitoring proposals support interoperability or observability, but the cited approaches do not provide runtime security enforcement or intrusion detection.Source: §3 · p. 7
- RIDRS is presented as a lightweight, decentralized, edge-native rule set that detects and mitigates anomalous runtime behavior without relying on centralized control.The paper frames it as a proof of concept and says larger-scale evaluation is still required.Source: §3 · p. 7
4 Methodology
The methodology combines a Raspberry Pi KubeEdge testbed, IoT image vulnerability analysis, controlled attacks, temporal availability metrics, and a lightweight rule-based detector. RIDRS uses behavioral rules and optional mitigation actions, including resource-use monitoring and network-attack response.
4.1 Experimental Setup
- The testbed uses three Raspberry Pi 3 B+ edge nodes, with one active-workload node and two failover nodes, coordinated by a virtual-machine CloudCore.It uses Ubuntu 22.04, Docker 20.10.14, KubeEdge 1.12.1, automatic pod rescheduling, synchronized clocks, and a counter application for availability monitoring.Source: §4.1 · pp. 8–9, Figure 3 · p. 8
4.2 Dataset Construction and Vulnerability Analysis (RQ1)
- The image audit targets the limited quantitative evidence on IoT and edge container-image security by collecting 500 IoT-tagged images from public registries and manually verifying their use cases.Trivy identifies CVEs and classifies severity from LOW to CRITICAL, including vulnerabilities in dependencies and misconfigurations.Source: §4.2 · p. 9
4.3 Attack Scenarios and Evaluation Metrics (RQ2)
- The attack scenarios cover DoS traffic, compromised-container deployment, and code injection, with real-time logs, CPU and memory measurements, and service-availability tracking.The evaluation defines attack introduction and KubeEdge reaction times, along with intervention, recovery, and outage times.Source: §4.3 · p. 10
- The temporal metrics distinguish when an attack affects behavior, when KubeEdge detects anomalies, when recovery actions begin, how long recovery takes, and total service unavailability.Recovery actions include restarting containers or redeploying Pods; the metrics support comparison across scenarios.Source: §4.3 · p. 10
4.4 Lightweight Intrusion Detection Mechanism (RQ3)
- RIDRS uses behavioral rules for memory and CPU consumption and ICMP floods, with event logging and optional process termination or firewall updates.Its memory rule sets a dynamic threshold from average normal usage plus α times total RAM, with α set to 15% in the experiments; rules can integrate with open-source IDS tools or lightweight agents.Source: §4.4 · p. 11
5 Results and Discussion
The results show widespread, uneven vulnerability exposure in IoT container images and reveal that KubeEdge handles localized failures better than attacks affecting shared resources. RIDRS prevents outages in code-injection and malicious-pod scenarios, but does not restore availability under DoS.
5.1 Vulnerability Distribution and Risk Exposure (RQ1)
- The vulnerability analysis used Trivy to identify known vulnerabilities and classify them from LOW to CRITICAL, including findings in embedded dependencies and misconfigurations.The results characterize vulnerability prevalence, severity, and exposure across the analyzed images.Source: §5.1 · p. 12
- More than 95% of analyzed images contain vulnerabilities across multiple severity levels, and vulnerability counts alone do not reliably indicate risk.Some images with fewer than ten vulnerabilities still contain HIGH or CRITICAL issues.Source: §5.1 · p. 12
- Vulnerability exposure is uneven: some images concentrate many findings, while even relatively low-count images can contain critical issues.Figure 4 shows variability across severity levels; Figure 5 contrasts the ten most and least vulnerable images.Source: §5.1 · p. 13, Figure 4 · p. 13, Figure 5 · p. 14
5.2 Impact of Security Attacks on System Availability (RQ2)
- Code injection caused 21.17 seconds of outage, while malicious-pod deployment exhausted resources and triggered cascading failures that persisted until manual intervention.KubeEdge redeployed a clean pod after code injection but rescheduled the malicious pod onto another node.Source: §5.2 · p. 15
- In the DoS scenario, resource saturation disrupted network communication and caused service failure after 17.10 seconds; KubeEdge detected anomalies after 24.58 seconds, with availability restored only after external mitigation.Source: §5.2 · pp. 15–16
5.3 Impact of RIDRS on Availability (RQ3)
- 0 seconds of outage and 0 seconds to impact were reported for code injection and malicious-pod attacks with RIDRS; DoS remained largely unaffected.Code injection was detected within 1.33 seconds and malicious-pod activity within 30.12 seconds.Source: Table 2 · p. 16, §5.3 · p. 17
- RIDRS detected DoS traffic within 9.1 seconds, but network-resource saturation continued and intervention and recovery times remained effectively infinite.The authors conclude that node-level detection alone is insufficient for large-scale network attacks.Source: §5.3 · p. 17
- RIDRS is tailored to resource-constrained edge devices and is presented as a lightweight alternative to cloud-oriented Falco and Suricata.The paper reports minimal computational overhead for RIDRS.Source: §5.3 · p. 17
6 Threats to Validity
The study uses controlled, repeatable scenarios and a Raspberry Pi KubeEdge testbed, but identifies limits in measurement, deployment scale, image coverage, and attack diversity.
6 Threats to Validity
- Results from the resource-constrained Raspberry Pi testbed may vary in larger or more heterogeneous deployments.The setup is intended to reflect realistic edge conditions.Source: §6 · p. 18
- The manually validated sample of 500 public-registry IoT images is diverse but does not exhaustively cover deployment scenarios.Source: §6 · p. 18
- Common attack scenarios and a rule-based RIDRS were evaluated; more complex or adaptive attacks could extend the assessment.Measurement precision and system-behavior variation may also affect reported timing metrics.Source: §6 · p. 18
7 Future Work
The paper proposes extending RIDRS with network-level mitigation, adaptive rule refinement, broader deployment evaluation, and additional resilience and threat measures.
7 Future Work
- Integrate RIDRS with network-level mechanisms to unify local detection and global mitigation against large-scale attacks.Source: §7 · p. 18
- Explore automated rule refinement to enhance detection while preserving RIDRS's lightweight nature.Source: §7 · p. 18
- Evaluate RIDRS in larger and more heterogeneous edge environments to further assess robustness and generalizability.Source: §7 · p. 18
- Broaden evaluation beyond availability to additional resilience indicators and more advanced threat scenarios.Source: §7 · p. 18
8 Conclusion
The conclusion reports widespread, unevenly distributed vulnerabilities in IoT container images and distinguishes localized failures from attacks affecting shared resources or multiple nodes. RIDRS improves resilience against internal attacks, while large-scale DoS remains challenging and calls for network-level defenses.
8 Conclusion
- Vulnerabilities in IoT container images are widespread and unevenly distributed, with critical risks even in seemingly low-risk images.Source: §8 · pp. 18–19
- KubeEdge handles localized failures but remains vulnerable to shared-resource attacks and cross-node propagation, where failover may amplify impact.Source: §8 · p. 19
- RIDRS improves resilience against internal attacks through early detection and mitigation, eliminating service disruption in multiple scenarios.The paper reports outage time falling to zero in two of three scenarios, compared with KubeEdge's default behavior.Source: §8 · p. 19
- Large-scale DoS remains challenging, and node-level detection must be complemented by network-level defenses.Source: §8 · p. 19