Update attacking-kubernetes-from-inside-a-pod.md

src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md

@@ -72,12 +72,6 @@ Notes and troubleshooting:
 - If you cannot get a host execution path, similar writable mounts can be abused to write other persistence/priv-esc artifacts on the host if the mapped directory is security-critical (e.g., add a root SSH key if the mount maps into /root/.ssh, drop a cron/systemd unit if maps into /etc, replace a root-owned binary in PATH that the host will execute, etc.). Feasibility depends entirely on what path is mounted.
 - This technique also works with plain Docker bind mounts; in Kubernetes it’s typically a hostPath volume (readOnly: false) or an incorrectly scoped subPath.
 
-Mitigations:
-- Avoid hostPath where possible; prefer dedicated volumes.
-- If hostPath is required, enforce readOnly: true and use restrictive mount options (nosuid,noexec,nodev). Apply Pod Security Standards/Admission to forbid hostPath by default.
-- Run containers as non-root and drop capabilities; use SELinux/AppArmor and readOnlyRootFilesystem when possible.
-- Monitor for unexpected SUID files on host and integrity changes under directories exposed to containers.
-
 ### Abusing Kubernetes Privileges
 
 As explained in the section about **kubernetes enumeration**: