<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Kubernetes on ShieldedBytes</title>
    <link>https://linuxeries.org/tags/kubernetes/</link>
    <description>Recent content in Kubernetes on ShieldedBytes</description>
    <generator>Hugo</generator>
    <language>en</language>
    <lastBuildDate>Sat, 07 Nov 2026 10:03:34 +0200</lastBuildDate>
    <atom:link href="https://linuxeries.org/tags/kubernetes/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Pruning false positives when hunting for lateral movement inside Kubernetes pods.</title>
      <link>https://linuxeries.org/post/2026-11-07-pruning-false-positives-when-hunting-for-late/</link>
      <pubDate>Sat, 07 Nov 2026 10:03:34 +0200</pubDate>
      <guid>https://linuxeries.org/post/2026-11-07-pruning-false-positives-when-hunting-for-late/</guid>
      <description>&lt;p&gt;When an attacker gets a foothold in a cluster, the next move is usually to hop around pods, namespaces, or even nodes. Catching that hop is a staple of any Kubernetes security program, but the noise can drown you out. A single benign &lt;code&gt;kubectl exec&lt;/code&gt; or a normal service‑mesh sidecar can set off the same alerts that a malicious container‑to‑container exfiltration would trigger. Below is a practical, repeatable walk‑through to cut the noise while still keeping the detection surface wide enough to catch the bad guys.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
