Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

Kubernetes hardening can be driven entirely by runtime logs: LLM prompt chains turn audit, network, and provenance data into least-privilege Roles, NetworkPolicies, and Deployments, reaching a perfect F1 on Role creation.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

KubeGuard generates and refines Kubernetes Roles, NetworkPolicies, and Deployments from aggregated audit, network, and provenance logs using prompt-chained LLMs, achieving F1 up to 0.96 with GPT-4o.

T0 review reviewed 2026-08-05 challenge →

load-bearing objection KubeGuard is a well-executed LLM+multi-log pipeline for Kubernetes least-privilege manifests; the evaluation is encouraging on its own terms, but the baseline's dependence on the same logs leaves a real completeness gap. the 3 major comments →

arxiv 2509.04191 v1 pith:F6DZLDOJ submitted 2025-09-04 cs.CR cs.LG

KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis

Omri Sgan Cohen , Ehud Malul , Yair Meidan , Dudu Mimran , Yuval Elovici , Asaf Shabtai This is my paper
classification cs.CR cs.LG
keywords Kubernetes hardeningleast-privilege configurationLLM prompt chainingRBAC RolesNetworkPoliciesDeployment refinementaudit and provenance logslog-driven security
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

KubeGuard is a recommender framework that hardens Kubernetes clusters by converting runtime observability into least-privilege configuration. It collects three kinds of logs — API audit records, network flows, and OS-level provenance — compresses them into compact key-value summaries, and feeds them through LLM prompt chains (sequences of prompts where each output seeds the next) to create missing Roles and NetworkPolicies or refine overly permissive ones. The paper's central claim is that observed behavior, properly aggregated, is sufficient signal to generate accurate least-privilege manifests, and it reports strong results: with GPT-4o, Role creation scores a perfect F1 of 1.00, and Role, NetworkPolicy, and Deployment refinement reach 0.953, 0.961, and 0.929. The framework also works with open-source local models such as Llama-3.1-8B, making it usable in privacy-sensitive settings. If the claim holds, operators gain a practical path from detecting misconfigurations to adaptively generating the tighter configuration.

Core claim

The paper's central claim: multi-source runtime logs, compressed into key-value summaries, carry enough information for an LLM to derive Kubernetes manifests that grant only the permissions, connections, and settings an application actually uses. KubeGuard implements this as Resource Creation (generate Roles or NetworkPolicies from scratch) and Resource Refinement (strip unused verbs, redundant ports, and over-broad rules from existing manifests). The discovery is that prompt chaining — decompose each task into analyze, match, recommend, revise — is what makes this reliable, and that the log-to-manifest matching step is load-bearing: removing it drops refinement F1 across all resources (Netw

What carries the argument

Two mechanisms carry the argument. (1) K-V aggregation: raw audit logs, Hubble network flows, and SPADE provenance records are flattened into key-to-set-of-values maps grouped by microservice, compressing model input tokens by up to 99.96% while preserving the behavioral facts a manifest must encode. (2) Prompt chaining: each task is a fixed sequence of structured prompts — analyze logs, analyze manifest, match logs to manifest, recommend revisions, revise — where each prompt's output becomes the next prompt's input; the matching step is what ties declared permissions to observed activity. Together they turn the least-privilege principle into a concrete, log-derived editing operation on YAML

Load-bearing premise

The framework assumes the logs collected during the observation window include every legitimate operation the application will ever need; any permission or connection absent from those logs is pruned as excessive, even if a rare scheduled job or failover path requires it.

What would settle it

Run KubeGuard on a workload with a documented rare-but-legal operation (e.g., a nightly batch job or a failover endpoint) that is excluded from the traffic fed into the logs; if the hardened Role or NetworkPolicy drops the permission or connection that operation needs and the workload breaks, the completeness assumption fails. A cheaper check: compare KubeGuard's refined manifests against the full documented API surface of a mature application and count pruned permissions that are later exercised in production.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Operators can replace static, rule-based hardening tools with adaptive, behavior-aware configuration: every generated or refined manifest is grounded in the cluster's own audit, network, and provenance records.
  • Kubernetes hardening becomes measurable: a refined manifest's residual attack surface is quantified by the permissions and rules left after matching against observed behavior, scored with precision, recall, and F1 against a log-derived baseline.
  • Privacy-constrained organizations can run the full workflow offline with an 8-billion-parameter local model (Llama-3.1-8B), accepting a moderate accuracy drop (e.g., Role refinement F1 0.808) in exchange for keeping cluster data on-premises.
  • Iterative refinement offers a cheap accuracy boost for weaker models: recursing the NetworkPolicy refinement chain lifts Llama-3.1-8B recall from 0.385 to 0.593 over three iterations, at the cost of oscillation and diminishing returns in later rounds.
  • The framework is model-agnostic and resource-agnostic, so the same creation-and-refinement pattern extends to additional Kubernetes resource types beyond Roles, NetworkPolicies, and Deployments.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The completeness assumption cuts both ways: KubeGuard prunes what the logs do not show, so any legitimate operation absent from the observation window — nightly batch jobs, failover paths, manual debugging access — will be dropped unless an operator reviews the output; the paper's convergence result (audit logs stabilize after ~1.75 days) suggests collecting at least that long before trusting a Ro
  • If KubeGuard is right that aggregated observability is the right input signal, the same aggregation-plus-chaining recipe should transfer to other policy surfaces beyond Kubernetes, such as cloud IAM or service-mesh authorization, where declared configuration can be checked against observed calls.
  • A testable extension would be to pair KubeGuard's log-derived baseline with an explicit operator-supplied keep-list of rare-but-legitimate operations, turning the completeness assumption from an unstated gap into a controllable input.
  • The near-perfect Role-creation score may reflect how cleanly audit logs encode RBAC actions (each API request names verb, resource, and subject), whereas NetworkPolicy and Deployment refinement must reason from noisier flow and provenance data — so future work should expect harder ceilings for network- and container-level hardening.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. KubeGuard is a log-driven Kubernetes hardening framework that aggregates audit logs, Hubble network flows, and SPADE provenance data into key-value summaries and feeds them, together with existing manifests, through modular LLM/SLM prompt chains. It supports two tasks: creating least-privilege Roles and NetworkPolicies from observed behavior, and refining existing Roles, NetworkPolicies, and Deployments. The paper evaluates KubeGuard on two microservice applications, using GPT-4o and several open-source models, and reports precision/recall/F1 against baseline manifests 'derived from real application logs' (Sec. 4.2), with additional ablations, sensitivity analyses, and comparisons to audit2rbac and KUBETEUS. The strongest reported results are perfect F1 for Role Creation and high F1 for the refinement tasks with GPT-4o.

Significance. If the evaluation supported the completeness of the generated policies, KubeGuard would be a valuable practical contribution: it combines multiple runtime data sources, uses a modular prompt-chain design, and demonstrates that local SLMs provide a usable privacy-preserving alternative. The paper includes a substantial set of experiments: prompt-strategy selection, model comparisons, iterative refinement, sensitivity to log duration and prompt order, ablation of matching steps and data sources, and two external baseline comparisons. These are real strengths and go beyond what is typical in this line of work. The main weakness is that the evaluation measures extraction fidelity from the input logs rather than the correctness of the hardening recommendation with respect to the application's true operational requirements. Because the ground truth is derived from the same logs KubeGuard consumes, false negatives are defined only relative to what is present in those logs. This limits the strength of the central claim that KubeGuard preserves functionality while reducing attack surface.

major comments (3)
  1. [Sec. 5.8.2] The ground-truth baselines are 'derived from real application logs' (Sec. 4.2), and a false negative is defined as a required element 'despite being evidenced in the logs' (Sec. 4.3.1). This makes the evaluation circular with respect to log completeness: if a legitimate Role verb, network flow, or Deployment setting never appears in the collected audit/Hubble/provenance data, it is also absent from the baseline and is never counted as a miss. The reported F1 scores therefore show how well KubeGuard recovers the evidence contained in the logs, not whether the resulting least-privilege manifest is complete for the application. This is a load-bearing gap for the paper's 'maintaining application functionality' claim. I ask the authors to provide a concrete test of completeness, for example by (a) constructing ground-truth policies from application semantics or documentation that include oper
  2. [Sec. 5.8.2] The convergence analysis uses Cosine, Overlap, and Dice similarity between successive cumulative aggregated-log segments (Fig. 8). This establishes that the token sets stabilize over time, but it does not establish that the stabilized set is complete relative to the application's true permission/network requirements. A stable set can still omit a rare but legitimate scheduled job, a failover path, or an administrative action. The paper's own limitation section (Sec. 6) correctly notes that 'capturing sufficient log data requires representative traffic,' and the convergence argument does not close that gap. I suggest adding an evaluation that varies the length of the log-collection window and measures the effect on the generated policy's recall against a ground truth that includes operations outside the observed window, or, at minimum, an analysis of which rare tokens are absent from the
  3. [Table 3, Role Creation row] The perfect F1 of 1.00 for Role Creation is suspicious given the baseline construction. If the baseline Roles are a rule-based extraction of verbs/resources from the AALs, and KubeGuard's prompt chain is designed to translate AALs into Roles, then perfect agreement may reflect deterministic information transfer rather than the model learning to generalize to unseen permission requirements. The same concern applies to the high refinement scores, which may be inflated because the baseline contains only elements already present in the logs. Please clarify how the baselines were constructed (human review, rule-based extraction, or a combination), and report at least one metric that is defined against an independent source of required permissions/connections, not against the logs themselves.
minor comments (5)
  1. [Sec. 5.8.2] The text refers to 'similarity metrics (Sec. 5.9.1)', but the Cosine, Overlap, and Dice metrics are defined in Sec. 4.3.2. The cross-reference should be corrected.
  2. [Sec. 5.3, Table 4] The text says Qwen2.5-7B's precision was 0.722, while Table 4 reports 0.772±0.122. One of these is a typo; please correct it.
  3. [Sec. 5.5, Fig. 7] Figure 7 shows iterative refinement results without the standard-deviation bars that accompany the other tables. Since the earlier tables report ± values, adding the same confidence information to the figure would help the reader judge the stability of the oscillation claim.
  4. [Sec. 5.2 and Sec. 5.10] The paper repeatedly mentions 'postprocessing' as a mitigation for recall drops and underspecified rules, but never describes what postprocessing is or whether the reported numbers include it. Please clarify, since this is a free parameter in the evaluation. The axiom ledger in the review identifies postprocessing as a free parameter; the manuscript should state exactly how and when it was applied.
  5. [Sec. 3.2.2, NetworkPolicy Refinement step 4] The chain has both step 4 and step '4.A' (validation of log-to-policy matches), but the text does not explain what the validation consists of or how it differs from the matching step. A brief description or a pointer to Figure 13/14 would make the workflow easier to follow.

Circularity Check

1 steps flagged

Evaluation baselines are derived from the same runtime logs KubeGuard consumes, so reported F1 measures agreement with the input rather than external correctness; log completeness is assumed but untested.

specific steps
  1. self definitional [Section 4.2 (Task-Specific Evaluation) and Section 4.3.1 (Task Effectiveness metrics)]
    "KubeGuard's tasks were evaluated through log-based assessments by comparing their output manifests with least-privilege baseline policies, derived from real application logs. ... False Negative (FN): A required permission or rule that is missing from the hardened output, either because it was not created or not refined by the framework, despite being evidenced in the logs."

    The 'least-privilege baseline policies' are derived from the same aggregated audit, network, and provenance logs that KubeGuard consumes as input (Sec. 3.1). A false negative is defined only as a missing element 'despite being evidenced in the logs.' Therefore, any legitimate permission, network flow, or deployment configuration that is absent from the collected logs is also absent from the baseline and is never counted as a miss. The F1 scores (e.g., 1.00 Role Creation) thus measure how well the LLM reproduces a log-derived target, not whether the output is complete or correct relative to the application's true requirements. The paper acknowledges in Sec. 6 that 'capturing sufficient log data requires representative traffic,' and Sec. 5.8.2's convergence analysis only shows token-set simi

full rationale

KubeGuard's derivation chain is a log-to-manifest translation pipeline: aggregated logs (AALs/ANLs/APLs) are fed into prompt chains that produce or refine manifests. The method itself is not circular; it is an LLM-based transformation of log evidence. The circularity lies in the evaluation: the ground-truth 'least-privilege baseline policies' are built from the same logs that constitute the system's input, and the metric definitions (TP/FP/FN/TN) are all anchored to 'observed behavior' in those logs. This design validates that KubeGuard can reconstruct the log-derived baseline, but it cannot detect omissions of legitimate operations that never appear in the collected logs, such as rare scheduled jobs or failover paths. The paper explicitly acknowledges the representative-traffic limitation in Sec. 6, which is honest but does not remove the self-referential nature of the reported F1 scores. Convergence analysis in Sec. 5.8.2 shows only that aggregated token sets stabilize over time, not that the stabilized set equals the true set of required permissions/connections. There is no load-bearing self-citation: the related work cites GenKubeSec [58] by overlapping authors, but that citation is contextual and not used to justify KubeGuard's design or evaluation. External comparisons to audit2rbac and KUBETEUS are also measured against the same log-derived baselines, so they inherit the same limitation. Overall, the framework has substantial independent content (multi-source log integration, prompt-chain design, model comparisons), but the central quantitative claim of least-privilege correctness is partially circular because the evaluation target is derived from the system's own input.

Axiom & Free-Parameter Ledger

5 free parameters · 4 axioms · 0 invented entities

No new physical or conceptual entities are introduced; the framework's components (AALs, ANLs, APLs, prompt chains) are composite representations of existing data. The free parameters are design choices tuned on the evaluation, and the axioms are domain assumptions about log completeness and representativeness.

free parameters (5)
  • Prompt chain order = Logs-to-Manifest
    Chosen after sensitivity analysis on Deployment Refinement (Sec. 5.8.1); the reverse order and Analyze-Match order performed worse.
  • Matching step presence = Included
    Kept based on ablation results showing F1 drops when removed from refinement chains (Sec. 5.9.2).
  • Data explanations = Per-task toggle
    Explanations are added for complex tasks and removed for simple tasks like Role Creation, where they hurt performance (Sec. 5.9.1).
  • Iterative refinement rounds = 5 iterations
    Chosen after observing that F1 stops improving beyond the third iteration and oscillates later (Sec. 5.5).
  • Postprocessing = Unspecified but recommended
    The paper repeatedly suggests postprocessing to correct underspecified rules but does not define it, leaving an unquantified knob (Secs. 5.2, 5.10).
axioms (4)
  • domain assumption Metadata-level audit logs capture all API actions relevant for RBAC inference
    Section 3.1.2 states AALs serve as ground truth for exercised API actions; if the minimal audit policy misses request bodies or certain verbs, the derived Roles could be wrong.
  • domain assumption K-V aggregation preserves all security-relevant information from raw logs
    Section 3.1 claims aggregation condenses raw logs 'while preserving all essential information'; if aggregation discards ordering or fine-grained context, the LLM may miss required permissions.
  • domain assumption The log-derived least-privilege baselines are the correct ground truth
    Section 4.2 defines baselines derived from real application logs; the evaluation measures agreement with these baselines, not with an independent security oracle.
  • domain assumption Load-generator traffic is representative of real production usage
    Section 4.1.2 uses native load generators to produce 'representative traffic'; the paper acknowledges in Section 6 that representative traffic is required for correctness.

reviewed 2026-08-05 · how reviews work

0 comments
Cite this review

Pith. "Pith review of KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis." pith.science (2026). https://pith.science/paper/F6DZLDOJ

@misc{pith2026250904191,
  author       = {Pith},
  title        = {Pith review of: KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/F6DZLDOJ}},
  note         = {Machine review of arXiv:2509.04191}
}
Share X Bluesky LinkedIn Reddit HN
read the original abstract

The widespread adoption of Kubernetes (K8s) for orchestrating cloud-native applications has introduced significant security challenges, such as misconfigured resources and overly permissive configurations. Failing to address these issues can result in unauthorized access, privilege escalation, and lateral movement within clusters. Most existing K8s security solutions focus on detecting misconfigurations, typically through static analysis or anomaly detection. In contrast, this paper presents KubeGuard, a novel runtime log-driven recommender framework aimed at mitigating risks by addressing overly permissive configurations. KubeGuard is designed to harden K8s environments through two complementary tasks: Resource Creation and Resource Refinement. It leverages large language models (LLMs) to analyze manifests and runtime logs reflecting actual system behavior, using modular prompt-chaining workflows. This approach enables KubeGuard to create least-privilege configurations for new resources and refine existing manifests to reduce the attack surface. KubeGuard's output manifests are presented as recommendations that users (e.g., developers and operators) can review and adopt to enhance cluster security. Our evaluation demonstrates that KubeGuard effectively generates and refines K8s manifests for Roles, NetworkPolicies, and Deployments, leveraging both proprietary and open-source LLMs. The high precision, recall, and F1-scores affirm KubeGuard's practicality as a framework that translates runtime observability into actionable, least-privilege configuration guidance.

Figures

Figures reproduced from arXiv: 2509.04191 by Asaf Shabtai, Dudu Mimran, Ehud Malul, Omri Sgan Cohen, Yair Meidan, Yuval Elovici.

Figure 1
Figure 1. Figure 1: Example of log-driven manifest hardening. An [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Overview of the KubeGuard framework: (a) collect manifests and runtime logs, (b) preprocess into aggregated [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Figure 3: Illustration and example of Aggregated Audit Logs [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Illustration of the provenance data association pro [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: Illustration of the Role Refinement prompt chain process: An overly permissive Role is analyzed, matched with [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Rule taxonomy used to define and evaluate exces [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: Average precision, recall, and F1-score across five [PITH_FULL_IMAGE:figures/full_fig_p010_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: Similarity between successive cumulative aggre [PITH_FULL_IMAGE:figures/full_fig_p011_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: Illustration and example of Aggregated Network [PITH_FULL_IMAGE:figures/full_fig_p015_9.png] view at source ↗
Figure 11
Figure 11. Figure 11: Zero-shot prompt example of the NetworkPolicy [PITH_FULL_IMAGE:figures/full_fig_p016_11.png] view at source ↗
Figure 10
Figure 10. Figure 10: Illustration and example of Aggregated Prove [PITH_FULL_IMAGE:figures/full_fig_p016_10.png] view at source ↗
Figure 12
Figure 12. Figure 12: Chain-of-thought prompt example of the Net [PITH_FULL_IMAGE:figures/full_fig_p017_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: NetworkPolicy Creation prompt chain [PITH_FULL_IMAGE:figures/full_fig_p019_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: High-level illustration of the Deployment Refinement prompt chain. [PITH_FULL_IMAGE:figures/full_fig_p020_14.png] view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Does Runtime Topology Context Improve LLM-Generated Kubernetes Security Patches?

    cs.CR 2026-07 conditional novelty 6.0

    Providing LLMs with live cluster topology and service-account context raised correct Kubernetes security patches from 11.1% to 78.0% on topology-dependent findings, with no change on a topology-independent control.

Reference graph

Works this paper leans on

132 extracted references · 70 canonical work pages · cited by 1 Pith paper · 4 internal anchors

  1. [1]

    Mashal Abbas, Shahpar Khan, Abdul Monum, Fareed Zaffar, Rashid Tahir, David Eyers, Hassaan Irshad, Ashish Gehani, Vinod Yegneswaran, and Thomas Pasquier. 2022. PACED: provenance-based automated container escape detec- tion. In 2022 IEEE International Conference on Cloud Engineering (IC2E) . IEEE, 261–272

    2022

  2. [2]

    Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Flo- rencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shya- mal Anadkat, et al. 2023. Gpt-4 technical report. arXiv preprint arXiv:2303.08774 (2023)

    Pith/arXiv arXiv 2023

  3. [3]

    Muntaha Alawneh and Imad M Abbadi. 2022. Expanding DevSecOps prac- tices and clarifying the concepts within kubernetes ecosystem. In 2022 Ninth International Conference on Software Defined Systems (SDS) . IEEE, 1–7

    2022

  4. [4]

    Sponsored by Red Hat Ansible. 2025. Ansible Community Documentation - Ansible offers open-source automation that is simple, flexible, and powerful. KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis https://docs.ansible.com/

    2025

  5. [5]

    Anthropic. 2024. Chain Prompts. https://docs.anthropic.com/en/docs/build- with-claude/prompt-engineering/chain-prompts Accessed: 2025-04-14

    2024

  6. [6]

    Anthropic. 2024. Claude 3. https://www.anthropic.com/news/claude-3-family

    2024

  7. [7]

    AppArmor. [n. d.]. AppArmor: Linux kernel security module. https://apparmor. net/

  8. [8]

    Aqua Security. 2024. kube-hunter: an Open Source Tool for Discovering Security Issues in Kubernetes Clusters. https://github.com/aquasecurity/kube-hunter

    2024

  9. [9]

    Ashish Gehani (ashish gehani). [n. d.]. SPADE. https://github.com/ashish- gehani/SPADE

  10. [10]

    hassaanirshad ashish gehani. [n. d.]. SPADE: Configuring namespace report- ing. https://github.com/ashish-gehani/SPADE/wiki/Collecting-system-wide- provenance-on-Linux-with-Audit#configuring-namespace-reporting

  11. [11]

    hassaanirshad ashish-gehani (Ashish Gehani). 2024. SPADE Audit Provenance: Data Model and Schema. https://github.com/ashish-gehani/SPADE/wiki/Audit- provenance

    2024

  12. [12]

    Azure-Samples. 2024. AKS Store Demo. https://github.com/Azure-Samples/aks- store-demo

    2024

  13. [13]

    Daniele Bringhenti, Riccardo Sisto, and Fulvio Valenza. 2023. Security automa- tion for multi-cluster orchestration in Kubernetes. In2023 IEEE 9th International Conference on Network Softwarization (NetSoft) . IEEE, 480–485

    2023

  14. [14]

    Clinton Cao, Agathe Blaise, Sicco Verwer, and Filippo Rebecchi. 2022. Learning state machines to monitor and detect anomalies on a kubernetes cluster. In Proceedings of the 17th International Conference on A vailability, Reliability and Security. 1–9

    2022

  15. [15]

    Carmine Cesarano and Roberto Natella. 2025. KubeFence: Security Hardening of the Kubernetes Attack Surface. arXiv:2504.11126 [cs.CR] https://arxiv.org/ abs/2504.11126

    work page internal anchor Pith review Pith/arXiv arXiv 2025

  16. [16]

    Checmarx. 2021. KICS: keeping infrastructure as code secure is an open source solution for static code analysis of Infrastructure as Code. https://kics.io/index. html

    2021

  17. [17]

    Xutong Chen, Hassaan Irshad, Yan Chen, Ashish Gehani, and Vinod Yeg- neswaran. 2021. CLARION: Sound and clear provenance tracking for microser- vice deployments. In 30th USENIX Security Symposium (USENIX Security 21) . 3989–4006

    2021

  18. [18]

    Cilium. 2024. Hubble. https://github.com/cilium/hubble

    2024

  19. [19]

    Cilium. 2025. Inspecting the Cluster’s Network Traffic with Hubble Relay. https://docs.cilium.io/en/stable/observability/hubble/hubble-cli/ #inspecting-the-cluster-s-network-traffic-with-hubble-relay

    2025

  20. [20]

    Henry Clausen, Robert Flood, and David Aspinall. 2019. Traffic generation using containerization for machine learning. In Proceedings of the 2019 Workshop on DYnamic and Novel Advances in Machine Learning and Intelligent Cyber Security . 1–12

    2019

  21. [21]

    Prisma Cloud. 2019. Checkov: Policy-as-code for everyone. https://www. checkov.io/

    2019

  22. [22]

    DeepSeek-AI. 2024. DeepSeek-V3 Technical Report. arXiv:2412.19437 [cs.CL] https://arxiv.org/abs/2412.19437

    Pith/arXiv arXiv 2024

  23. [23]

    Alaeddine Diaf, Abdelaziz Amara Korba, Nour Elislem Karabadji, and Yacine Ghamri-Doudane. 2024. BARTPredict: Empowering IoT Security with LLM- Driven Cyber Threat Prediction. In GLOBECOM 2024-2024 IEEE Global Commu- nications Conference. IEEE, 1239–1244

    2024

  24. [24]

    Boubacar Diarra, Karine Guillouard, Meryem Ouzzif, Philippe Merle, and Jean- Bernard Stefani. 2024. In-depth analysis of Kubernetes manifest verification tools for robust CNF deployment. In 2024 27th Conference on Innovation in Clouds, Internet and Networks (ICIN) . IEEE, 17–24

    2024

  25. [25]

    Ashish Gehani and Dawood Tariq. 2012. SPADE: Support for provenance audit- ing in distributed environments. In ACM/IFIP/USENIX International Conference on Distributed Systems Platforms and Open Distributed Processing . Springer, 101–120

    2012

  26. [26]

    Aaron Grattafiori, Abhimanyu Dubey, Abhinav Jauhri, Abhinav Pandey, Ab- hishek Kadian, Ahmad Al-Dahle, Aiesha Letman, Akhil Mathur, Alan Schel- ten, Alex Vaughan, et al . 2024. The llama 3 herd of models. arXiv preprint arXiv:2407.21783 (2024)

    Pith/arXiv arXiv 2024

  27. [27]

    Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y. Wu, Y. K. Li, Fuli Luo, Yingfei Xiong, and Wen- feng Liang. 2024. DeepSeek-Coder: When the Large Language Model Meets Programming – The Rise of Code Intelligence. arXiv:2401.14196 [cs.SE] https://arxiv.org/abs/2401.14196

    Pith/arXiv arXiv 2024

  28. [28]

    Mubin Ul Haque, M Mehdi Kholoosi, and M Ali Babar. 2022. Kgsecconfig: a knowledge graph based approach for secured container orchestrator configura- tion. In 2022 IEEE International Conference on Software Analysis, Evolution and Reengineering (SANER). IEEE, 420–431

    2022

  29. [29]

    Wajih Ul Hassan, Lemay Aguse, Nuraini Aguse, Adam Bates, and Thomas Moyer

  30. [30]

    Jonatan Heyman, Carl Byström, Joakim Hamrén, Hugo Heyman, and contribu- tors. 2025. Locust: An open source load testing tool. https://locust.io/

    2025

  31. [31]

    Ben Hirschberg. 2022. Kubescape: A Kubernetes Open-Source Plat- form Providing a Multi-Cloud Kubernetes Single Pane of Glass. https://www.armosec.io/blog/kubescape-the-first-tool-for-runningnsa- and-cisa-kubernetes-hardening-tests/

    2022

  32. [32]

    Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, et al. 2025. A survey on hallucination in large language models: Principles, taxonomy, challenges, and open questions. ACM Transactions on Information Systems 43, 2 (2025), 1–55

    2025

  33. [33]

    Sandeep Kampa. 2024. Navigating the Landscape of Kubernetes Security Threats and Challenges. Journal of Knowledge Learning and Science Technology ISSN: 2959-6386 (online) 3, 4 (2024), 274–281

    2024

  34. [34]

    Ahmad Faraz Khan, Azal Ahmad Khan, Anas Mohamed, Haider Ali, Suchithra Moolinti, Sabaat Haroon, Usman Tahir, Mattia Fazzini, Ali R Butt, and Ali Anwar. 2025. LADs: Leveraging LLMs for AI-Driven DevOps. arXiv preprint arXiv:2502.20825 (2025)

    Pith/arXiv arXiv 2025

  35. [35]

    Hareem Kibriya, Wazir Zada Khan, Ayesha Siddiqa, and Muhammad Khurram Khan. 2024. Privacy issues in large language models: a survey. Computers and Electrical Engineering 120 (2024), 109698

    2024

  36. [36]

    Bom Kim, Hyeonjun Park, and Seungsoo Lee. 2025. KUBETEUS: An Intelli- gent Network Policy Generation Framework for Containers. Cybersecurity Convergence Laboratory (CCLAB) at Incheon National University (2025)

    2025

  37. [37]

    Hirokuni Kitahara, Kugamoorthy Gajananan, and Yuji Watanabe. 2020. Highly- scalable container integrity monitoring for large-scale kubernetes cluster. In 2020 IEEE International Conference on Big Data (Big Data) . IEEE, 449–454

    2020

  38. [38]

    Danila Koryugin. 2023. Analysing and alerting on application logs within Kuber- netes infrastructure. B.S. thesis. University of Twente

    2023

  39. [39]

    Nane Kratzke and André Drews. 2024. Don’t Train, Just Prompt: Towards a Prompt Engineering Approach for a More Generative Container Orchestration Management.. In CLOSER. 248–256

    2024

  40. [40]

    Kubernetes. 2024. Auditing. https://kubernetes.io/docs/tasks/debug/debug- cluster/audit/

    2024

  41. [41]

    Kubernetes. 2024. Describing a Kubernetes Object. https://kubernetes.io/docs/ concepts/overview/working-with-objects/#describing-a-kubernetes-object

    2024

  42. [42]

    Kubernetes. 2024. Kubernetes - Operator Pattern. https://kubernetes.io/docs/ concepts/extend-kubernetes/operator/

    2024

  43. [43]

    Kubernetes. 2024. Kubernetes Documentation / Concepts / Overview. https: //kubernetes.io/docs/concepts/overview/

    2024

  44. [44]

    Kubernetes. 2024. Kubernetes Documentation / Concepts / Security / Service Accounts. https://kubernetes.io/docs/concepts/security/service-accounts/

    2024

  45. [45]

    Kubernetes. 2024. Kubernetes Documentation / Concepts Configuration / ConfigMaps. https://kubernetes.io/docs/concepts/configuration/configmap/

    2024

  46. [46]

    Kubernetes. 2024. Network Policies - Kubernetes. https://kubernetes.io/docs/ concepts/services-networking/network-policies/

    2024

  47. [47]

    Kubernetes. 2025. Auditing – Audit policy (minimal audit policy file to log all requests at the Metadata level). https://kubernetes.io/docs/tasks/debug/debug- cluster/audit/

    2025

  48. [48]

    Kubernetes. 2025. Kubernetes Deployment. https://kubernetes.io/docs/ concepts/workloads/controllers/deployment/

    2025

  49. [49]

    Kubernetes. 2025. Kubernetes Documentation / Concepts / Storage / Persistent Volumes. https://kubernetes.io/docs/concepts/storage/persistent-volumes/

    2025

  50. [50]

    Kubernetes. 2025. Kubernetes Documentation / Reference / API Access Control / Using RBAC Authorization - Kubernetes Role. https://kubernetes.io/docs/ reference/access-authn-authz/rbac/

    2025

  51. [51]

    Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rock- täschel, et al. 2020. Retrieval-augmented generation for knowledge-intensive nlp tasks. Advances in neural information processing systems 33 (2020), 9459– 9474

    2020

  52. [52]

    Haoran Li, Jun Sun, and Xiong Ke. 2024. AI-driven optimization system for large-scale Kubernetes clusters: Enhancing cloud infrastructure availability, security, and disaster recovery. Journal of Artificial Intelligence General science (JAIGS) ISSN: 3006-4023 2, 1 (2024), 281–306

    2024

  53. [53]

    Xing Li, Yan Chen, Zhiqiang Lin, Xiao Wang, and Jim Hao Chen. 2021. Automatic policy generation for{Inter-Service} access control of microservices. In 30th USENIX Security Symposium (USENIX Security 21) . 3971–3988

    2021

  54. [54]

    Z Li, S Dutta, and M Naik. 2024. LLM-Assisted Static Analysis for Detecting Security Vulnerabilities. arXiv 2024. arXiv preprint arXiv:2405.17238 (2024)

    Pith/arXiv arXiv 2024

  55. [55]

    Jordan Liggitt. 2023. audit2rbac: Autogenerate RBAC policies based on Kuber- netes audit logs. https://github.com/liggitt/audit2rbac

    2023

  56. [56]

    Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al

  57. [57]

    Vijay B Mahajan and Sunil B Mane. 2022. Detection, analysis and counter- measures for container based misconfiguration using docker and kubernetes. In 2022 International Conference on Computing, Communication, Security and Intelligent Systems (IC3SIS). IEEE, 1–6. Omri Sgan Cohen, Ehud Malul, Yair Meidan, Dudu Mimran, Yuval Elovici, Asaf Shabtai

    2022

  58. [58]

    Ehud Malul, Yair Meidan, Dudu Mimran, Yuval Elovici, and Asaf Shabtai. 2024. GenKubeSec: LLM-Based Kubernetes Misconfiguration Detection, Localization, Reasoning, and Remediation. arXiv preprint arXiv:2405.19954 (2024)

    Pith/arXiv arXiv 2024

  59. [59]

    Meta AI. 2024. Llama-3.1-70B-Instruct. https://huggingface.co/meta-llama/ Llama-3.1-70B-Instruct

    work page 2024

  60. [60]

    Michael Kerrisk. 2025. namespaces(7) — Linux manual page . man7.org. https: //man7.org/linux/man-pages/man7/namespaces.7.html

    work page 2025

  61. [61]

    mistralai. 2024. ministral. https://mistral.ai/news/ministraux

    work page 2024

  62. [62]

    MongoDB. 2025. MongoDB: The World’s Leading Modern Database. https: //www.mongodb.com/

    work page 2025

  63. [63]

    Luc Moreau, Ben Clifford, Juliana Freire, Joe Futrelle, Yolanda Gil, Paul Groth, Natalia Kwasnikowska, Simon Miles, Paolo Missier, Jim Myers, et al. 2011. The open provenance model core specification (v1. 1). Future generation computer systems 27, 6 (2011), 743–756

    work page 2011

  64. [64]

    Ioannis Morfonios. 2023. Kubernetes cybersecurity . Master’s thesis. Π𝛼𝜈𝜀𝜋𝜄𝜎𝜏 ´𝜂𝜇𝜄 o Π𝜀𝜄𝜌𝛼𝜄 ´𝜔𝜍

    work page 2023

  65. [65]

    ANIRUDH MUSTYALA. 2022. Comprehensive Monitoring and Logging in Kubernetes: Best Practices and Tools. EPH-International Journal of Science And Engineering 8, 4 (2022), 05–14

    work page 2022

  66. [66]

    Andrzej Mycek and Maryna Łukaczyk. 2024. SECURITY OF CONTAINER- IZATION PLATFORMS: THREAT MODELLING, VULNERABILITY ANALYSIS, AND RISK MITIGATION. ECMS - The European Council for Modelling and Simulation (2024)

    work page 2024

  67. [67]

    NP-Guard. [n. d.]. NP-Guard: Shift-left Automation for Generating and Main- taining Kubernetes Network Policies. https://np-guard.github.io/

    work page

  68. [68]

    NVIDIA. 2024. rtx6000. https://www.nvidia.com/en-us/design-visualization/ rtx-6000/

    work page 2024

  69. [69]

    OpenAI. 2024. GPT-4o System Card. https://openai.com/index/gpt-4o-system- card/

    work page 2024

  70. [70]

    Sundar Pichai and Demis Hassabis. 2023. Introducing Gemini: our largest and most capable AI model. Google. Retrieved December 8 (2023), 2023

    work page 2023

  71. [71]

    Google Cloud Platform. 2025. Load Generator for microservices-demo (Online Boutique). https://github.com/GoogleCloudPlatform/microservices-demo/tree/ main/src/loadgenerator. Part of the microservices-demo repository

    work page 2025

  72. [72]

    Google Cloud Platform. 2025. Online Boutique: Microservices Demo Applica- tion. https://github.com/GoogleCloudPlatform/microservices-demo

    work page 2025

  73. [73]

    Mike Prechtl, Robin Lichtenthäler, and Guido Wirtz. 2020. Investigating possi- bilites for protecting and hardening installable faas platforms. In Symposium and Summer School on Service-oriented Computing . Springer, 107–126

    work page 2020

  74. [74]

    Cilium Project. 2025. Special Identities — Cilium Documentation. https://docs. cilium.io/en/latest/gettingstarted/terminology/#special-identities

    work page 2025

  75. [75]

    RabbitMQ. 2025. RabbitMQ: One broker to queue them all. https://www. rabbitmq.com/

    work page 2025

  76. [76]

    Akond Rahman, Shazibul Islam Shamim, Dibyendu Brinto Bose, and Rahul Pandita. 2023. Security misconfigurations in open source kubernetes manifests: An empirical study. ACM Transactions on Software Engineering and Methodology 32, 4 (2023), 1–36

    work page 2023

  77. [77]

    Monika Rangta. 2022. Tools for Security Auditing and Hardening in Microservices Architecture. Master’s thesis. Aalto University

    work page 2022

  78. [78]

    Zhengping Ruan. 2021. Network security prediction method based on ku- bernetes. In Journal of Physics: Conference Series , Vol. 2010. IOP Publishing, 012109

    work page 2021

  79. [79]

    Eoghan Russell and Kapal Dev. 2024. Centralized Defense: Logging and Mitiga- tion of Kubernetes Misconfigurations with Open Source Tools. arXiv preprint arXiv:2408.03714 (2024)

    work page internal anchor Pith review Pith/arXiv arXiv 2024

  80. [80]

    Areeg Samir and Håvard Dagenborg. 2023. Adaptive Controller to Identify Mis- configurations and Optimize the Performance of Kubernetes Clusters and IoT Edge Devices. In European Conference on Service-Oriented and Cloud Computing . Springer, 170–187

    work page 2023

Showing first 80 references.

This paper was first reviewed by deepseek-v4-flash on August 5, 2026.