KubeGuard: Runtime-Based Kubernetes Hardening

• KubeGuard is an LLM-assisted framework that leverages runtime logs and configuration analysis to recommend least-privilege Kubernetes manifests.
• It uses modular prompt chaining for both resource creation and refinement, targeting Roles, NetworkPolicies, and Deployments.
• Its runtime evidence-based approach reduces overly permissive configurations and is validated with high precision, recall, and F1 metrics.

KubeGuard is an LLM-assisted framework for Kubernetes hardening that uses configuration files plus runtime logs to recommend least-privilege manifests. Introduced as a novel runtime log-driven recommender framework aimed at mitigating risks by addressing overly permissive configurations, it is designed to harden Kubernetes environments through two complementary tasks, Resource Creation and Resource Refinement, and presents its output manifests as recommendations that users can review and adopt rather than as automatic cluster enforcement (Cohen et al., 4 Sep 2025). The framework is motivated by recurrent Kubernetes risks associated with unauthorized access, privilege escalation, lateral movement, overly broad RBAC permissions, overly permissive network access, and unnecessary Deployment-level resources or settings.

1. Problem setting and security scope

KubeGuard addresses a specific Kubernetes security problem: manifests often encode permissions, communication paths, or runtime settings that are broader than the workload actually uses. Most existing Kubernetes security solutions focus on detecting misconfigurations, typically through static analysis or anomaly detection, whereas KubeGuard relies on runtime-observable behavior to infer what is necessary and what may be removed or tightened (Cohen et al., 4 Sep 2025). Its central premise is that if a permission, network flow, or dependency is not observed in runtime logs, it may be unnecessary and should be removed or tightened.

This focus sits inside a broader Kubernetes hardening landscape in which security is treated as a multi-layered problem. The systematization of knowledge in "XI Commandments of Kubernetes Security: A Systematization of Knowledge Related to Kubernetes Security Practices" identifies 11 security practices, including Authentication and Authorization, Implementing Kubernetes-specific Security Policies, Vulnerability Scanning, Logging, Namespace Separation, Encrypt and Restrict Access to etcd, Continuous Update, Limit CPU and Memory Quota, Enable SSL/TLS Support, Separate Sensitive Workload, and Secure Metadata Access (Shamim et al., 2020). KubeGuard concentrates on a narrower subset of that space: least-privilege configuration of Roles, NetworkPolicies, and Deployments, informed by runtime evidence rather than only by static best-practice taxonomies.

A plausible implication is that KubeGuard should be understood less as a general-purpose compliance scanner and more as a behavior-grounded hardening assistant. Its recommendations are tied to actual API use, actual network flows, and actual provenance events, which differentiates it from frameworks that primarily enumerate known rule violations.

2. Data model, observability inputs, and preprocessing pipeline

KubeGuard is organized around three major stages: data acquisition, data preprocessing or aggregation, and LLM prompt-chaining for hardening (Cohen et al., 4 Sep 2025). Its inputs are Kubernetes manifests and three kinds of runtime logs: Kubernetes audit logs, Hubble network logs or flows, and SPADE provenance logs extended with CLARION for namespace awareness. YAML manifests are converted into JSON for processing.

The framework derives three aggregated runtime representations. Aggregated Audit Logs are collected using a minimal audit policy that logs API requests at the Metadata level, then grouped by microservice and aggregated into key-to-set-of-values structures; these provide RBAC-relevant evidence of actual API actions. Aggregated Network Logs are derived from Hubble network flow data and capture Pod-level ingress and egress, ports, directions, protocols, and peers; these are used to infer exactly what NetworkPolicies should allow. Aggregated Provenance Logs are derived from SPADE provenance logs, extended with CLARION for namespace awareness, and capture low-level container activity such as process creation, file writes, socket activity, and system-level interactions; they are associated with microservices using text-based matching against cluster metadata.

Because raw logs are too large for LLM context windows, KubeGuard applies a key-value aggregation algorithm. The paper states that the algorithm recursively traverses nested JSON logs and builds a dictionary from each key to a set of unique observed values. Its core behavior is to recurse through dictionaries and lists and, when a value is primitive, add it to the set for its key. The result is a compact key-to-set mapping that reduces token count by up to 99.96%, making analysis feasible within model context limits (Cohen et al., 4 Sep 2025).

This preprocessing layer is central to the framework’s logic. Audit logs encode observed API access and RBAC needs, network logs encode observed ingress and egress communication, and provenance logs encode observed in-container behavior and dependencies. KubeGuard treats these observations as evidence for least-privilege synthesis and refinement.

3. Prompt-chaining architecture and supported hardening tasks

KubeGuard implements two main tasks through five prompt chains total: Resource Creation and Resource Refinement (Cohen et al., 4 Sep 2025). Resource Creation is used when a resource is missing and KubeGuard needs to generate a secure manifest from observed behavior; it creates Roles and NetworkPolicies. Resource Refinement is used when a manifest already exists but is too permissive; it refines Roles, NetworkPolicies, and Deployments.

The framework uses prompt chaining rather than a single monolithic prompt. The paper defines this as feeding the output of one prompt into the next so the model can do multistep reasoning. The prompts have a fixed structure with elements such as system role, task, requirements, instructions, input, and expected output plus justification. This modularity allows distinct reasoning steps such as analyzing logs, analyzing manifests, matching observed behavior to manifest fields, producing recommendations, and revising the manifest.

Prompt chain	Inputs	Output
Role Creation	Deployment manifest, AALs	ServiceAccount, Role, RoleBinding
NetworkPolicy Creation	Deployment manifest, ANLs	NetworkPolicy with ingress and egress rules
Role Refinement	AALs, Deployment manifest, existing Role manifest	Revised Role manifest
NetworkPolicy Refinement	ANLs, Deployment manifest, existing NetworkPolicy	Revised NetworkPolicy
Deployment Refinement	AALs, APLs, existing Deployment	Hardened Deployment manifest

The Role Creation chain analyzes Aggregated Audit Logs for observed RBAC context, analyzes the Deployment manifest for security issues, creates a ServiceAccount, generates a minimal Role, and generates a RoleBinding. The NetworkPolicy Creation chain analyzes the Deployment for network-relevant configuration, inspects Aggregated Network Logs for communication patterns, and generates ingress and egress rules. Role Refinement analyzes AALs, inspects the Deployment and existing Role manifest, matches Role rules with observed usage, recommends reductions, and revises the Role. NetworkPolicy Refinement analyzes the Deployment, inspects ANLs and the existing policy, matches the policy to observed flows, validates log-to-policy matches, recommends tightening, and revises the policy. Deployment Refinement analyzes AALs and APLs, inspects the existing Deployment, matches it against logs, generates recommendations, and revises the Deployment.

The framework outputs complete hardened manifests that are correctly formatted and ready to apply, but only as recommendations for user review. This is a substantive design choice: KubeGuard hardens by advisory generation and refinement rather than by direct admission-time enforcement.

4. Evaluation methodology and reported results

KubeGuard was evaluated on two microservice applications deployed in a self-managed Kubernetes cluster on AWS: Google Online Boutique or Microservices Demo, and Azure AKS Store Demo. Representative traffic was produced using the applications’ built-in load generators. The study evaluated prompting strategies, proprietary LLMs, open-source SLMs, scaling effects, iterative refinement, sensitivity to prompt order and log duration, ablations, and comparisons to existing tools. For creation tasks, outputs were compared against least-privilege baselines derived from real application logs; for refinement tasks, synthetic manifests with injected excessive permissions were also used so that attack-surface reduction was measurable (Cohen et al., 4 Sep 2025).

The paper uses precision, recall, and F1-score, with TP defined as a permission, rule, or configuration correctly generated or refined based on logs, FP as an incorrect or unsupported permission, rule, or configuration, FN as a required permission or rule missing from hardened output, and TN as a correctly retained configuration element. Prompt chaining was the best overall strategy on NetworkPolicy Creation across GPT-4o, Gemini-1.5-Pro, and Claude-3.5-Sonnet. For GPT-4o on NetworkPolicy Creation, the reported Precision is 0.945, Recall is 0.926, and F1 is 0.935.

Using GPT-4o across all tasks, the reported scores are: Role Creation, Precision 1.00, Recall 1.00, F1 1.00; NetworkPolicy Creation, Precision 0.945, Recall 0.926, F1 0.935; Role Refinement, Precision 1.00, Recall 0.914, F1 0.953; NetworkPolicy Refinement, Precision 0.990, Recall 0.940, F1 0.961; Deployment Refinement, Precision 0.975, Recall 0.894, F1 0.929 (Cohen et al., 4 Sep 2025). Among local open-source models, the best SLM on the baseline task was Llama-3.1-8B with Precision 0.813, Recall 0.803, and F1 0.793. Its task-level F1-scores were 0.607 for Role Creation, 0.793 for NetworkPolicy Creation, 0.808 for Role Refinement, 0.504 for NetworkPolicy Refinement, and 0.728 for Deployment Refinement. The paper also reports that Qwen2.5-14B improved over Qwen2.5-7B and performed better on NetworkPolicy Refinement than Llama-3.1-8B in that setting.

The comparisons to task-equivalent baselines are especially sharp. On Role Creation, audit2rbac achieved Precision 0.208, Recall 1.00, and F1 0.343, while KubeGuard achieved Precision 1.00, Recall 1.00, and F1 1.00. On NetworkPolicy Creation in the same small-model setting used for comparison, KUBETEUS achieved Precision 0.360, Recall 0.238, and F1 0.275, while KubeGuard achieved Precision 0.444, Recall 0.265, and F1 0.332. The paper attributes audit2rbac’s weak precision to overgeneration of many rules and presents KubeGuard’s pod-centric and broader runtime context as the reason for greater precision.

The ablation study shows that removing the log-to-manifest matching step degraded all refinement tasks: Role Refinement F1 dropped to 0.835, NetworkPolicy Refinement F1 dropped to 0.652, and Deployment Refinement F1 dropped to 0.854. For Deployment Refinement, removing explanations lowered F1 from 0.929 to 0.881; omitting AALs lowered F1 to 0.829, and omitting APLs lowered F1 to 0.876. Prompt-order sensitivity on Deployment Refinement favored Logs to Manifest, with F1 0.929, over Manifest to Logs, with F1 0.909, and over an Analyze plus Match variant, with F1 0.848.

To study log collection duration, the paper uses cosine, overlap, and dice similarity:

$$\text{Cosine}(A, B) = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \cdot \sqrt{\sum_{i=1}^{n} B_i^2}}$$

$$\text{Overlap}(A, B) = \frac{|A \cap B|}{\min(|A|, |B|)}$$

$$\text{Dice}(A, B) = \frac{2 \cdot |A \cap B|}{|A| + |B|}$$

The reported convergence result is that ANLs and APLs converged after about 4 hours, whereas AALs converged after about 1.75 days. After convergence, longer collection did not add meaningful new information.

5. Position within Kubernetes hardening and scanning research

KubeGuard occupies a different position from static configuration scanners and centralized scanner aggregation systems. "A Comparison of Kubernetes Compliance Standards and Configuration Scanners" establishes a benchmark of 79 Kubernetes configuration recommendations, generated from 67 data-plane configuration recommendations extracted from eight hardening guidelines plus 12 additional best-practice recommendations, and uses 241 manifests to evaluate ten popular static configuration scanning tools (Krieger et al., 23 Jun 2026). That study reports substantial disparities in the coverage of configuration issues across hardening guidelines and scanners, uneven F1 and coverage across tools, and large inconsistencies in severity and ranking. Its core message is that Kubernetes compliance scanning is not only a detection problem but also a standardization and risk-ranking problem.

KubeGuard addresses a different but adjacent problem. Rather than benchmarking fixed rule coverage against manifest-level violations, it derives least-privilege recommendations from runtime behavior. A plausible implication is that it can complement scanner-centric workflows rather than replace them. Static scanners benchmark rule coverage over recognized configuration recommendations; KubeGuard refines manifests according to observed use. The two approaches therefore operate on different evidence bases: one on explicit configuration rules, the other on observed runtime activity.

The contrast is also visible when KubeGuard is set beside centralized misconfiguration aggregation systems. "Centralized Defense: Logging and Mitigation of Kubernetes Misconfigurations with Open Source Tools" presents a central logging solution that integrates Trivy, Kube-score, KubeSec, and Kube-Linter, normalizes heterogeneous scanner outputs, deduplicates similar findings using Python’s SequenceMatcher, and uploads consolidated JSON records to MongoDB for display in a Flask web application (Russell et al., 2024). That system is a post-scan aggregation and visualization pipeline, not an enforcement controller. KubeGuard, by contrast, does not primarily aggregate scanner outputs; it uses manifests plus runtime observability and produces hardened manifests as recommendations.

This difference is significant because the scanner-comparison literature reports not only coverage gaps but also severe disagreement about the importance of the same configuration issue. The benchmark study shows that only 9 of 10 scanners provided severity, that only 1 configuration issue was scored by all scanners, and that some configuration issues had severity spreads above 7.0 after normalization (Krieger et al., 23 Jun 2026). KubeGuard’s paper does not present itself as a new universal severity model. Its contribution is instead the translation of runtime observability into actionable least-privilege configuration guidance.

6. Related systems, naming distinctions, and limitations

The name KubeGuard should not be conflated with NimbusGuard. "NimbusGuard: A Novel Framework for Proactive Kubernetes Autoscaling Using Deep Q-Networks" proposes and evaluates NimbusGuard, an open-source Kubernetes-based autoscaling system that leverages a deep reinforcement learning agent and an LSTM workload forecaster to provide proactive autoscaling (Wanigasooriya et al., 13 Apr 2026). It is about Kubernetes autoscaling rather than hardening, and it is not a system called KubeGuard. The shared suffix may suggest a broad family of Kubernetes “guard” mechanisms, but the research problems are distinct: autoscaling for workload volatility versus hardening of overly permissive configurations.

KubeGuard is also distinct from Kubernetes-native trust architectures for physically exposed workers. "Trusting the Cloud-Native Edge: Remotely Attested Kubernetes Workers" presents an architecture that securely enrolls edge devices as trusted Kubernetes worker nodes through boot attestation rooted in a hardware TPM, modified Keylime components, and dynamic RBAC provisioning and revocation (Thijsman et al., 2024). That work is concerned with whether a node should be trusted to join and remain in the cluster at all. KubeGuard instead assumes an operational cluster and focuses on how existing workloads should be configured to minimize unnecessary privilege.

The limitations reported for KubeGuard are explicit. Its scope is limited to three resource types: Roles, NetworkPolicies, and Deployments. Prompt crafting requires expertise, and adapting to new resources or domains is nontrivial. KubeGuard recommends but does not enforce, so operators must review and apply the manifests. Representative traffic is required because runtime logs must cover real usage patterns. Open-source SLMs are less accurate, especially for difficult refinement tasks, and prompt chaining may need early stopping because iterative refinement can oscillate after several rounds (Cohen et al., 4 Sep 2025).

These limitations bound the framework’s present role. It is not a universal Kubernetes compliance engine, not an admission controller, and not a node trust system. Its specific contribution is to show that runtime observability plus modular prompt-chained LLM reasoning can produce practical least-privilege Kubernetes hardening recommendations for selected resource types.