在我看来，现在关于k8s的攻击面很小，除了容器逃逸，敏感信息和配置不当，很难有其他有效的横向移动的手段了吧，反正据我了解暂时是这样子的，慢慢积累吧还是。

回顾一下Pod中那几项不安全的配置 ：

• hostNetwork：true，使用宿主机的网络
• hostPID：true，使用宿主机进程空间（ps命令）
• hostIPC：true，允许Pod共享宿主机的IPC命名空间
• privileged：true，是特权容器
• hostPath：path：/ ，允许使用宿主机的根目录/

通常来说，Node节点也应该是一个服务器，上面有kubectl类似的工具来方便我们操作，既然是服务器，那么我们怎么登陆呢？

模仿登陆Pod的方式是不行的，这时我们可以使用docker来查看

 

很清晰了吧，其实Node节点是一个docker容器，那么我们就可以通过docker进入Node节点从而管理集群了。

BadPods--everything-allowed-exec-pod的挂载目录的效果体现的不是很明显，为了方便区分，我们在master-node和worker-node上分别建立一个标志文件 

 使用docker进入worker-node

docker exec -it 容器id bash

 

同理master节点

然后我们删除原来的pod（可以同时删除多个）

kubectl delete pod everything-allowed-exec-pod hostpath-exec-pod nothing-allowed-exec-pod

 然后重新创建pod

kubectl apply -f ./manifests/everything-allowed/pod/everything-allowed-exec-pod.yaml

然后我们进入容器并查看/host目录

这样子就很清晰了吧，那么下面进入正题，看看其他的配置该如何利用。

一.BadPods配置学习

1.1 priv

是特权容器，直接用CDK，可以逃逸，pass

1.2 hostipc

若该配置为true，那么允许Pod共享宿主机的IPC命名空间，IPC的作用类似目录文件共享，在/dev/shm目录下的文件是共享的。

进入容器直接拿CDK进行扫描

发现我们不是特权容器，也没有什么能直接逃逸的权限。

因为这个pod是运行在worker-node节点上，那么它应该与workerr-node上的/dev/shm目录下的文件共享，我们尝试创建一个文件

 然后在Pod中查看结果

只有该配置的Pod的进一步渗透的话就需要运气了，没有逃逸或者其他的权限，只能靠寻找敏感信息，其他的没啥想法。。

1.3 hostnetwork

首先还是使用CDK进行扫描，没有可以利用逃逸的点

然后查看扫描输出字段 Net Namespace

提示我们这个容器是加了--net=host启动的，查看配置文件我们就能看到

这个参数我们知道，是使用宿主机的网络，那么我们查看一下Pod的ip和节点的ip进行对比即可

我的Pod里啥都没有，所以先安装一下

apt-get update

apt-get install net-tools

在Pod中运行ifconfig

其中node节点Ip

发现可以ping通master节点

那么我们在这个网段中，横向渗透的面就大了，运气好就能继续拿到其他服务器的权限，然后慢慢拿到master节点的权限。

1.4 hostpath 

直接CDK扫描，看结果中的

发现有host下有很多敏感文件，于是进入host目录

此时可以看到我们worker节点的目录已经被挂载进来了

1.5 hostpid 

hostPID：true，使用宿主机进程空间（ps命令）

使用CDK进行扫描，没啥有价值的输出

然后使用命令：ps -aux

发现可以看到宿主机的进程，然后看每个进程环境变量，运气好能找到有用的信息

for e in `ls /proc/*/environ`; do echo; echo $e; xargs -0 -L1 -a $e; done > envs.txt

其他的话就是结束进程了：pkill -f 进程名

1.6 Nothing

这个的话就是靠运气和其他的了，类似RBAC权限滥用，或者K8S集群中某些配置不当，其他的话我暂时就没有什么渗透思路了。

---

总结：BadPods的练习就是熟悉一下配置，或者以后真拿到了一个可以create pods的账号，利用这些配置就可以轻松拿到master节点了。

之后打算先写写污点这方面，然后顺便说一说类似deployment，daemonset等组件的作用，要不然都不知道它们有什么作用也不太好哈