Etcd是CoreOS团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值(key-value)数据库, 用于服务发现、共享配置以及一致性保障等。目前已广泛应用在kubernetes、ROOK、CoreDNS、M3以及openstack等领域。

Etcd内部采用raft协议作为一致性算法，基于Go语言实现。从组成上来看，Etcd主要由四个部分组成：HTTP Server、Store、Raft以及WAL。我们可以通过Etcd架构图来更好的了解Etcd，Etcd架构图可见下图所示：

图-1  Etcd架构图

Etcd比较常见的版本有v2版本和v3版本，v2、v3版本的共同点是共享同一套raft协议代码，不同点是二者为两个独立的应用，互不兼容，其接口、存储都是不相同的。

值得注意的是，Kubernetes集群已经在Kubernetes v1.11中弃用Etcdv2 版本，在新版本的Kubernetes中，Kubernetes采用 Etcd v3存储数据。

在对Etcd有了初步了解之后，我们来看一下Kubernetes中Etcd的应用。

在Kubernetes集群中，存在有控制平面组件以及Node组件两大类组件，在这两类组件中包含了多种不同功能的组件，这些组件共同保证了Kubernetes集群的正常运行。Kubernetes集群组件结构可参照下图：

图- 2  Kubernetes集群组件

Etcd在Kubernetes中扮演着控制平面组件的角色，是兼具一致性和高可用性的键值数据库，在Kubernetes集群中扮演着保存 Kubernetes 所有集群数据的后台数据库的角色。

Kubernetes系统中一共有两个服务需要用到Etcd进行协同和与存储，分别是Kubernetes自身与网络插件 flannel。

在Kubernetes 集群的配置过程中，需要安装Etcd组件，Etcd的yaml文件可见下图：

图- 3  Etcd组件配置文件

从上文配置文件可见，Etcd在配置过程中需要配置两个url地址:listen-client-urls以及 listen-peer-urls，分别监听在2379端口以及2380端口。其中listen-peer-urls用于 etcd 集群同步信息并保持连接，而listen-client-urls则用于接收用户端发来的 HTTP请求。

Etcd常见风险包括：

1. 启动etcd时，未使用client-cert-auth参数打开证书校验；

2. Etcd 2379端口公网暴露；

3. 由于SSRF漏洞导致Etcd 127.0.0.1:2379 可访问；

4. Etcd cert泄露。

我们分别来看一下以上四个风险点分别是如何对Etcd造成威胁的。

首先来看一下未使用client-cert-auth参数打开证书校验带来的风险：

在启动etcd时，正确的做法是使用client-cert-auth参数打开证书校验，见下图配置文件红框处：

图- 4  开启证书校验

在打开证书校验选项后，通过本地127.0.0.1:2379地址可以免认证访问Etcd服务，但通过其他地址访问要携带cert进行认证访问

在未使用client-cert-auth参数打开证书校验时，任意地址访问Etcd服务都不需要进行证书校验，此时Etcd服务存在未授权访问风险。

接下来，我们分析一下Etcd 2379端口公网暴露所带来的风险：

在配置Etcd时，正确的做法是为listen-client-urls参数配置一个合理的IP地址，Etcd将监听在给定端口和接口上，如下图红框处：

图- 5  配置listen-client-urls

由于错误的配置，将listen-client-urls IP配置为0.0.0.0,那么Etcd 将会在所有接口上监听给定端口，这将导致Etcd 2379端口在公网暴露。

接下来，我们分析一下由于SSRF漏洞导致Etcd 127.0.0.1:2379 可访问风险：

即使Etcd进行了正确的配置，由于服务器上应用程序的SSRF漏洞，导致Etcd 127.0.0.1:2379 可访，此接口默认不需要证书校验，因此攻击者可以通过SSRF漏洞访问此接口并读取Etcd中的敏感数据。

最后，我们来看一下Etcd cert泄露所带来的风险：

在配置安全通信后， 需要使用TLS 身份验证来完成Etcd服务的访问，通常使用如下的方式有效证书证书进行访问：

ETCDCTL_API=3 etcdctl --endpoints etcd_ip:2379   --cert=/etc/kubernetes/pki/etcd/client.crt   --key=/etc/kubernetes/pki/etcd/client.key   --cacert=/etc/kubernetes/pki/etcd/ca.crt 

如果证书被窃取，攻击者可以使用获取到的证书访问Etcd服务。

在搭建Kubernetes并配置Etcd服务时，如果出现了上一章节中提到的错误配置或漏洞风险点，攻击者可以利用Etcd的风险点发起攻击。

我们在这里列举集中常见的攻击者攻击方式，通过以攻促防的方式，带领读者了解Etcd服务所面临的风险以及威胁。

在开始介绍攻击常见前，我们先来了解一款常见的etcd命令行工具——etcdctl。

etcdctl是一款命令行客户端，提供一些简洁的命令，用户无需使用HTTP API，可以直接使用etcdctl提供的指令与etcd服务进行交互。

可以通过如下地址进行下载：

https://github.com/coreos/etcd/releases

接下来我们对几种攻击场景逐一进行分析。

Etcd初始访问

Etcd 2379端口公网暴露

在这个场景中，攻击者可以利用暴露在公网上的23379端口访问Etcd服务。但在这个场景中，攻击者依然面临着两个不同的情况，即当前Etcd服务在启动时是否使用client-cert-auth参数开启证书校验。

如果当前Etcd服务未进行证书校验，则存在未授权访问漏洞，可以通过如下指令获取top-levelkeys数据

/etcdctl–endpoints=https://etcd_ip:2379/ get / –prefix –keys-only

具体操作可见下图：

图- 6  获取top-level keys数据

如果当前Etcd服务使用证书进行校验，则需要使用获取到的证书进行配置并访问

在使用etcdctl工具之前，需要配置如下三个环境变量：

• ETCDCTL_CERT

• ETCDCTL_CACERT

• ETCDCTL_KEY

在配置了正确的证书后，即可通过etcdctl工具对Etcd服务进行访问。

由于SSRF漏洞导致Etcd localhost端口访问

在这个场景中，由于SSRF漏洞导致Etcd 127.0.0.1:2379可访问，而且Etcd 127.0.0.1:2379地址默认不需要进行证书校验，即可以直接访问，因此当Etcd服务器上应用程序存在SSRF漏洞时，攻击者可以通过构造内外请求的方式，向Etcd服务API接口发送恶意指令。

Etcd凭据窃取

通过初始访问阶段，攻击者获取了Etcd服务的访问权限，并可以使用etcdctl工具读取Etcd中存储的数据，接下来介绍一下在此阶段中应用的技术。

获取clusterrole key

可以使用如下指令读取存储于Etcd中的与clusterrole有关的key

etcdctl–endpoints=https://etcd_ip:2379/ get / –prefix –keys-only | grep/secrets/kube-system/clusterrole。

图- 7  读取clusterrole有关的key

获取token key值

可以通过如下指令，通过上一步中获取到的key，读取其中的值：

etcdctl–endpoints=https://etcd_ip:2379/ get / /xxx/secrets/kube-system/clusterrole-xxx

从返回的数据中，挑选出一个具有高权限的role并读取其token。toke数据通常以字符串”ey”开头，并截取到字符串

“#kubernetes.io/service-account-token”之前部分，见下图选中部分：

图表- 8  截取token数据

至此，我们已经获取了有效的Kube Apiserver 访问token。

Kube Apiserver命令执行

通过上一阶段窃取到的token认证访问Kube Apiserver，使用kubectl接管集群。具体操作如下：

kubectl–insecure-skip-tls-verify -s https://kube_apiserver:6443/–token=”[ey…]” -n kube-system get nodes

图表- 9  使用kubectl接管集群

生成context

可以使用如下命令生成context：

图表- 10  生成context

配置context简化kubectl操作

Kubernetes通过上下文（context），使用简便的名称来对访问参数进行分组。每个上下文都有三个参数：cluster、namespace 和user。kubectl工具可以通过kubeconfig参数指定我们生成的上下文 context_config：

图表- 11  配置context

通过这个方式，即可简化kubectl操作，无需每次执行kubectl命令时填写TOKEN。

通过上文攻击场景介绍，我们提出如下的防护建议用以加固Etcd服务：

1. 在启动Etcd时，使用client-cert-auth参数打开证书校验；

2. Etcd数据加密存储，确保Etcd数据泄露后无法利用；

3. 正确的配置listen-client-urls参数，防止外网暴露；

4. 尽量避免在Etcd所在的节点上部署Web应用程序，以防通过Web应用漏洞攻击Etcd localhost地址。

Etcd组件在Kubernetes中充当着保存集群数据的后台数据库这一重要角色，因此Etcd组件安全对集群来说也是尤为重要。通过上文分析可见，虽然Etcd组件提供了较为安全的鉴权功能，以保证数据的安全性，但是由于用户在配置使用Etcd组件时安全意识不足或配置错误，将会导致集群数据被非法访问或篡改。Ectd数据泄露，将会为集群带来严重的安全问题。未来我们将持续关注Etcd组件安全问题。

https://yeasy.gitbook.io/docker_practice/etcd/etcdctl

https://kubernetes.io/zh/docs/concepts/overview/components/

https://www.huweihuang.com/kubernetes-notes/etcd/etcdctl-v3.html

https://www.cdxy.me/?p=827

https://tttang.com/archive/1465/

• 浅谈云上攻防——元数据服务带来的安全挑战
• 浅谈云上攻防——Web应用托管服务中的元数据安全隐患
• 浅谈云上攻防——对象存储服务访问策略评估机制研究
• 浅谈云上攻防——Kubelet访问控制机制与提权方法研究
• 浅谈云上攻防——国内首个对象存储攻防矩阵
• 浅谈云上攻防——SSRF漏洞带来的新威胁
• 浅谈云上攻防——CVE-2020-8562漏洞为k8s带来的安全挑战

• 浅谈云上攻防——云服务器攻防矩阵

END

更多精彩内容点击下方扫码关注哦~

   云鼎实验室视频号

  一分钟走进趣味科技

     -扫码关注我们-

原文始发于微信公众号（云鼎实验室）：浅谈云上攻防——Etcd风险剖析