Pith. sign in

REVIEW 3 major objections 5 minor 1 cited by

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

T0 review · 3 major / 5 minor · reviewed 2026-08-05 · deepseek-v4-flash

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

Pith's one-line read 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.

desk verdict 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. read the letter →

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

Omri Sgan Cohen , Ehud Malul , Yair Meidan , Dudu Mimran , Yuval Elovici , Asaf Shabtai This is my paper
classification cs.CRcs.LG
keywords Kuberneteshardeningleast-privilegeconfigurationLLMpromptchainingRBACRolesNetworkPoliciesDeploymentrefinementauditandprovenancelogslog-drivensecurity
verification ladder T0 review T1 audit T2 compute T3 formal

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.

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

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

Extended reading notes

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

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.

Editorial extensions

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.

Reading between the lines

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, 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 · score 4.0 of 10

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.

  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.

Assumptions & free parameters 5 free parameters · 4 assumptions · 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).
assumptions (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.

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}
}
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 the authors.

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. 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. Illustration and example of Aggregated Audit Logs [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (11 more)
Figure 4
Figure 4. Figure 4: Illustration of the provenance data association pro [PITH_FULL_IMAGE:figures/full_fig_p005_4.png]
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]
Figure 6
Figure 6. Figure 6: Rule taxonomy used to define and evaluate exces [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]
Figure 7
Figure 7. Figure 7: Average precision, recall, and F1-score across five [PITH_FULL_IMAGE:figures/full_fig_p010_7.png]
Figure 8
Figure 8. Figure 8: Similarity between successive cumulative aggre [PITH_FULL_IMAGE:figures/full_fig_p011_8.png]
Figure 9
Figure 9. Figure 9: Illustration and example of Aggregated Network [PITH_FULL_IMAGE:figures/full_fig_p015_9.png]
Figure 11
Figure 11. Figure 11: Zero-shot prompt example of the NetworkPolicy [PITH_FULL_IMAGE:figures/full_fig_p016_11.png]
Figure 10
Figure 10. Figure 10: Illustration and example of Aggregated Prove [PITH_FULL_IMAGE:figures/full_fig_p016_10.png]
Figure 12
Figure 12. Figure 12: Chain-of-thought prompt example of the Net [PITH_FULL_IMAGE:figures/full_fig_p017_12.png]
Figure 13
Figure 13. Figure 13: NetworkPolicy Creation prompt chain [PITH_FULL_IMAGE:figures/full_fig_p019_13.png]
Figure 14
Figure 14. Figure 14: High-level illustration of the Deployment Refinement prompt chain. [PITH_FULL_IMAGE:figures/full_fig_p020_14.png]

Discussion (0). Sign in to comment.

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 of 10

    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

  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)

    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

Show all 132 references
  1. [9]

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

  2. [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

  3. [11]

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

    2024

  4. [12]

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

    2024

  5. [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

  6. [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

  7. [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

    2025 arXiv

  8. [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

  9. [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

  10. [18]

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

    2024

  11. [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

  12. [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

  13. [21]

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

    2019

  14. [22]

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

    2024 arXiv

  15. [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

  16. [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

  17. [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

  18. [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)

    2024 arXiv

  19. [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 ...

    2024 arXiv

  20. [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

  21. [29]

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

  22. [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

  23. [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

  24. [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 Info...

    2025

  25. [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

  26. [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)

    2025 arXiv

  27. [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

  28. [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

  29. [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

  30. [38]

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

    2023

  31. [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

  32. [40]

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

    2024

  33. [41]

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

    2024

  34. [42]

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

    2024

  35. [43]

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

    2024

  36. [44]

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

    2024

  37. [45]

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

    2024

  38. [46]

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

    2024

  39. [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

  40. [48]

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

    2025

  41. [49]

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

    2025

  42. [50]

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

    2025

  43. [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...

    2020

  44. [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

  45. [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

  46. [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)

    2024 arXiv

  47. [55]

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

    2023

  48. [56]

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

  49. [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 Coh...

    2022

  50. [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)

    2024 arXiv

  51. [59]

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

    2024

  52. [60]

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

    2025

  53. [61]

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

    2024

  54. [62]

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

    2025

  55. [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

    2011

  56. [64]

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

    2023

  57. [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

    2022

  58. [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)

    2024

  59. [67]

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

  60. [68]

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

    2024

  61. [69]

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

    2024

  62. [70]

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

    2023

  63. [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

    2025

  64. [72]

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

    2025

  65. [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

    2020

  66. [74]

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

    2025

  67. [75]

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

    2025

  68. [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

    2023

  69. [77]

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

    2022

  70. [78]

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

    2021

  71. [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)

    2024 arXiv

  72. [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

    2023

  73. [81]

    Azure Samples. 2025. virtual-customer (AKS Store Demo). https://github.com/ Azure-Samples/aks-store-demo/tree/main/src/virtual-customer. Part of the AKS Store Demo microservices sample for Azure Kubernetes Service

    2025

  74. [82]

    Azure Samples. 2025. virtual-worker (AKS Store Demo). https://github.com/ Azure-Samples/aks-store-demo/tree/main/src/virtual-worker. Part of the AKS Store Demo microservices sample for Azure Kubernetes Service

    2025

  75. [83]

    Komal Sarda, Zakeya Namrud, Marin Litoiu, Larisa Shwartz, and Ian Watts. 2024. Leveraging Large Language Models for the Auto-remediation of Microservice Applications: An Experimental Study. In Companion Proceedings of the 32nd ACM International Conference on the Foundations of...

    2024

  76. [84]

    Pawan Kumar Sarika, Deepika Badampudi, Sai Prashanth Josyula, and Muham- mad Usman. 2023. Automating Microservices Test Failure Analysis using Kubernetes Cluster Logs. In Proceedings of the 27th International Conference on Evaluation and Assessment in Software Engineering . 192–195

    2023

  77. [85]

    University College Dublin SATLE ’Are You AI Ready?’ Project Team. 2024. Are You AI Ready? Investigating AI Tools in Higher Education / The Structure of a Good Prompt. University College Dublin. https://ucddublin.pressbooks.pub/ StudentResourcev1_od/chapter/the-structure-of-a-g...

    2024

  78. [86]

    Amir Schreiber and Ilan Schreiber. 2025. AI for cyber-security risk: harnessing AI for automatic generation of company-specific cybersecurity risk profiles. Information & Computer Security (2025)

    2025

  79. [87]

    Md Shazibul Islam Shamim, Farzana Ahamed Bhuiyan, and Akond Rahman

  80. [88]

    Shazibul Islam Shamim. 2021. Mitigating security attacks in kubernetes mani- fests for security best practices violation. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering . 1689–1690

    2021

  81. [89]

    Ze Sheng, Fenghua Wu, Xiangwu Zuo, Chao Li, Yuxin Qiao, and Hang Lei. 2024. Research on the LLM-Driven Vulnerability Detection System Using LProtec- tor. In 2024 IEEE 4th International Conference on Data Science and Computer Application (ICDSCA). IEEE, 192–196

    2024

  82. [90]

    StackRox. 2025. KubeLinter: static analysis tool that checks Kubernetes YAML files and Helm charts to ensure the applications represented in them adhere to best practices. https://github.com/stackrox/kube-linter

    2025

  83. [91]

    Meredith Syed and Vrunda Gadesha. 2024. What is Zero-Shot Prompting? IBM. https://www.ibm.com/think/topics/zero-shot-prompting

    2024

  84. [92]

    Rust Team. 2025. Rust — A Language Empowering Everyone to Build Reliable and Efficient Software. https://www.rust-lang.org/

    2025

  85. [93]

    Tenable. 2022. Terrascan: Policy as Code for Secure Cloud Infrastructure. https://runterrascan.io/

    2022

  86. [94]

    Masaru Ueno and Tetsuya Uchiumi. 2024. Migrating Existing Container Work- load to Kubernetes–LLM Based Approach and Evaluation. arXiv preprint arXiv:2408.11428 (2024)

    2024 arXiv

  87. [95]

    Yu, Qingsong Wen, and Yang Liu

    Kun Wang, Guibin Zhang, Zhenhong Zhou, Jiahao Wu, Miao Yu, Shiqian Zhao, Chenlong Yin, Jinhu Fu, Yibo Yan, Hanjun Luo, Liang Lin, Zhihao Xu, Haolang Lu, Xinye Cao, Xinyun Zhou, Weifei Jin, Fanci Meng, Junyuan Mao, Hao Wu, Minghe Wang, Fan Zhang, Junfeng Fang, Chengwei Liu, Yif...

    2025 arXiv

  88. [96]

    Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. 2022. Chain-of-thought prompting elicits rea- soning in large language models. Advances in neural information processing systems 35 (2022), 24824–24837

    2022

  89. [97]

    Thomas Wolf, Lysandre Debut, Victor Sanh, Julien Chaumond, Clement De- langue, Anthony Moi, Pierric Cistac, Tim Rault, Rémi Louf, Morgan Funtowicz, et al. 2019. Huggingface’s transformers: State-of-the-art natural language pro- cessing. arXiv preprint arXiv:1910.03771 (2019)

    2019 arXiv

  90. [98]

    Tongshuang Wu, Michael Terry, and Carrie Jun Cai. 2022. Ai chains: Transpar- ent and controllable human-ai interaction by chaining large language model prompts. In Proceedings of the 2022 CHI conference on human factors in computing systems. 1–22

    2022

  91. [99]

    Chengcheng Xiang, Yudong Wu, Bingyu Shen, Mingyao Shen, Haochen Huang, Tianyin Xu, Yuanyuan Zhou, Cindy Moore, Xinxin Jin, and Tianwei Sheng. 2019. Towards continuous access control validation and forensics. In Proceedings of the 2019 ACM SIGSAC conference on computer and comm...

    2019

  92. [100]

    An Yang, Baosong Yang, Binyuan Hui, Bo Zheng, Bowen Yu, Chang Zhou, Chengpeng Li, Chengyuan Li, Dayiheng Liu, Fei Huang, Guanting Dong, Haoran Wei, Huan Lin, Jialong Tang, Jialin Wang, Jian Yang, Jianhong Tu, Jianwei Zhang, Jianxin Ma, Jin Xu, Jingren Zhou, Jinze Bai, Jinzheng...

    2024 arXiv

  93. [101]

    Jingfeng Yang, Hongye Jin, Ruixiang Tang, Xiaotian Han, Qizhang Feng, Haom- ing Jiang, Shaochen Zhong, Bing Yin, and Xia Hu. 2024. Harnessing the power of llms in practice: A survey on chatgpt and beyond. ACM Transactions on Knowledge Discovery from Data 18, 6 (2024), 1–32

    2024

  94. [102]

    Ziyang Ye, Triet Huynh Minh Le, and M Ali Babar. 2025. LLMSecConfig: An LLM-Based Approach for Fixing Software Container Misconfigurations. arXiv preprint arXiv:2502.02009 (2025). KubeGuard: LLM-Assisted Kubernetes Hardening via Configuration Files and Runtime Logs Analysis

    2025 arXiv

  95. [103]

    Ce Zhou, Qian Li, Chen Li, Jun Yu, Yixin Liu, Guangjing Wang, Kai Zhang, Cheng Ji, Qiben Yan, Lifang He, et al. 2024. A comprehensive survey on pretrained foundation models: A history from bert to chatgpt. International Journal of Machine Learning and Cybernetics (2024), 1–65

    2024

  96. [104]

    Hui Zhu and Christian Gehrmann. 2022. Kub-Sec, an automatic Kubernetes clus- ter AppArmor profile generation engine. In 2022 14th International Conference on COMmunication Systems & NETworkS (COMSNETS) . IEEE, 129–137. A Example Deployment Manifest Listing A provides an exampl...

    2022

  97. [108]

    Kubernetes pod deployment manifest: {deployment_manifest}

  98. [109]

    Pod's aggregated network flow logs: {ANL_dataset} ####{deployment_manifest}#### <agg network logs>{agg_network_logs}</agg network logs> Figure 11: Zero-shot prompt example of the NetworkPolicy Creation task. prompting, the CoT prompt explicitly guides the LLM through a step-by...

  99. [110]

    Analyze the pod deployment manifest: • Identify the deployment's specifications, including containers, labels, and service selections • Note any existing network configurations and dependencies • Determine the application's expected network behavior

  100. [111]

    Review the aggregated network flow logs: • Identify all legitimate communication patterns and endpoints • Determine ingress and egress requirements for the pod • Note any anomalous or unexpected traffic patterns

  101. [112]

    Create Kubernetes NetworkPolicy manifests (Main Task): • Design NetworkPolicy(ies) based on the principle of least privilege • Include only necessary ingress and egress rules derived from the flow logs

  102. [113]

    Provide security enhancement recommendations for each NetworkPolicy: • Explain the rationale behind each rule included in the NetworkPolicy(ies) • Highlight how the NetworkPolicy adheres to zero-trust networking principles • Suggest any additional network security measures or ...

  103. [114]

    Align with best practices and compliance standards: • Ensure NetworkPolicy definitions comply with Kubernetes security best practices • Suggest improvements to meet relevant standards Required Information:

  104. [115]

    Kubernetes pod deployment manifest

  105. [116]

    Aggregated network flow logs for the pod Output:

  106. [117]

    One or more Kubernetes NetworkPolicy manifests in YAML format

  107. [118]

    Security enhancement recommendations and explanations for each NetworkPolicy created, including: • Rationale for the NetworkPolicy's structure and rules • How the NetworkPolicy enhances security compared to the default allow-all network posture • Any additional network securit...

  108. [119]

    source__destination

    Justification for NetworkPolicy Rules: • For each NetworkPolicy created, provide a detailed justification for every ingress and egress rule • Explain how each rule relates to the pod's observed network behavior in the flow logs • Highlight any communication patterns that were ...

  109. [120]

    Aggregatedaudit logs Expected Output:1. Aggregated audit logsanalysis Step 7 - Manifest RevisionsTask: Revise the K8s manifestsections based on the provided mapping of recommendations to each section of the manifestdelimited by. Rely on the audit logs and provenance datamatche...

  110. [121]

    Manifest recommendationsExpected Output:

  111. [122]

    Each revised K8s manifest section. 2. Justification and reasoning for the revisions made. Step 6 - Manifest Recommendations Task: Compose recommendations for revisions for each sectionof the K8s manifest, using the mapping of the matches between the K8s manifest, theaggregated...

  112. [123]

    Aggregated audit logsmatches 3.Aggregated provenancelogs matches Expected Output:

  113. [124]

    Justification and reasoning for the recommendations

    Mapping the manifestentries to their corresponding recommendations.2. Justification and reasoning for the recommendations. Step 4 - Aggregated Audit Logs Matching Task: Match the K8s manifest analysisagainst the aggregated audit logs analysis. Your goal is to identifykey eleme...

  114. [125]

    Mapping the manifest entries to their correspondingaudit logs entries

    Deploymentmanifest analysis Expected Output: 1. Mapping the manifest entries to their correspondingaudit logs entries

  115. [126]

    Role: Act as a world-class Kubernetes expert, renowned for building the most secure and efficient K8s manifests

    Justification andreasoning for the matches. Role: Act as a world-class Kubernetes expert, renowned for building the most secure and efficient K8s manifests. Your mission is to analyze and optimize Kubernetes configurations for maximum security and performance. System Prompt St...

  116. [127]

    Aggregated provenancelogs analysis

  117. [128]

    Deployment manifest analysisExpected Output:

  118. [129]

    Justification and reasoning for the matches

    Mapping the manifestentries to their corresponding provenance data entries.2. Justification and reasoning for the matches. Step 3 - Deployment ManifestAnalysis Task: Analyze the K8s manifest with emphasis onsecurity related sections. Your task is to extract security- relevanti...

  119. [130]

    K8s manifest analysis Step 2 - AggregatedProvenance Logs Analysis Task: Analyze the K8s aggregatedprovenance data

    Deployment manifestExpected Output:1. K8s manifest analysis Step 2 - AggregatedProvenance Logs Analysis Task: Analyze the K8s aggregatedprovenance data. Your task is to extract security-relevant information fromthe provenance data to evaluate potential securityrisks and vulner...

  120. [131]

    Aggregatedprovenance logs ExpectedOutput:

  121. [132]

    Aggregated provenance dataanalysis Figure 14: High-level illustration of the Deployment Refinement prompt chain

  122. [2018]

    In Network and Distributed Systems Security Symposium

    Towards scalable cluster auditing through grammatical inference over provenance graphs. In Network and Distributed Systems Security Symposium

  123. [2020]

    2020 IEEE Secure Development (SecDev) (2020), 58–64

    Xi commandments of kubernetes security: A systematization of knowl- edge related to kubernetes security practices. 2020 IEEE Secure Development (SecDev) (2020), 58–64

    2020

  124. [2023]

    Advances in Neural Information Processing Systems 36 (2023), 46534–46594

    Self-refine: Iterative refinement with self-feedback. Advances in Neural Information Processing Systems 36 (2023), 46534–46594

    2023

Pith tools

Reviewed August 5, 2026 · model on record in the stance chip above.