etcd之安全性阐述

etcd安全是指安全模式下etcd的运行状态，接下来从访问安全和传输安全两方面来阐述etcd的安全性访问安全包括用户的认证和授权，传输安全指使用SSL/TLS来加密数据通道

访问安全

用户权限功能在etcd 2.1之后增加的，在2.1版本之前，etcd是一个完全开放的系统，任何用户都可以通过REST API修改etcd存储的数据。etcd在2.1中增加了用户（User）和角色（Role）的概念，引入了用户认证的功能。为了保证向后兼容和可升级性，etcd的用户权限功能默认关闭。

无论数据信道是否经过加密（SSL/TLS），etcd都支持安全认证与权限管理，etcd的权限管理借鉴了操作系统的权限管理思想，存在用户和角色（分组）两种权限管理方法。在操作系统中，默认存在一个超级管理员root，拥有最高权限，其余所有的用户权限都派生于oot。另外，系统还默认存在一个访客（guest）分组，该分组用于授权无认证登录的用户，并且该分组默认可以新增，修改以及删除其为该角色创建的数据

etcd认证体系分为User和Role，Role被授予给User，代表User拥有某项权利。etcd的认证体系中有一个特殊的用户和角色，那就是root

root用户拥有对etcd访问的全部权限，并且必须在启动认证之前预先创建。设置root用户的初衷是为了方便管理-——管理角色和普通用户。root用户必须是root角色

root角色可以授权给任何用户。一旦某个用户被授予root角色，它就拥有全局的读写权限以及修改集群认证配置的权限。一般情况下，root角色所赋予的特权用于集群维护，例如，修改集群member关系，存储碎片整理，做数据快照等

etcd包括三种类型的资源，具体如下：

• 权限资源（permission resourses） 表示用户（User）和角色（Role）信息
• 键值资源（key-value resoursses）：表示键值对数据信息
• 资源配置（settings resourses）：安全配置信息，权限配置信息和etcd集群动态配置信息（选举/心跳）

权限资源

User（用户）是一个被授予权限的身份，每一个用户都可以拥有多个角色（Role）。用户操作资源的权限（例如读写资源）根据该用户所拥有的角色来确定的。用户分为root用户和非root用户

root用户是etcd提供的一个特殊用户。在安全功能被激活之前必须创建root用户，否则会无法启动身份认证功能。root用户具有root角色功能并允许对etcd内部进行任何操作。root用户的主要目的是为了进行恢复——它会生成一个密码并存储在某一个地方，并且被授予root角色来承担系统管理员的功能。root用户在我们对etcd集群进行故障排查和恢复时很重要

Role（角色）用来关联权限。etcd每个角色（Role）都具有相对应的权限列表，这个权限列表定义了角色对键值资源的访问权限。在etcd中角色主要分为三类：root角色，guest角色和普通角色。etcd默认会创建其中两种特殊角色——root和guest

etcd默认创建root用户时即创建root角色，并为其绑定该角色，该角色拥有所有权限；guest角色，默认自动创建，主要用于非认证使用。普通角色，由root用户创建，并由root用户分配指定权限

root角色具有对所有键值资源的访问访问权限，而且只有root角色具有管理用户资源和配置资源的权限。root角色是内置的，不需要被创建而且不能被修改，但是可以被授予任何用户相同得权限

另外一个特殊的角色是guest，这个角色会被自动创建。guest角色针对未经身份验证的请求提供了访问etcd的权限，即如果没有指定任何验证方式和用户访问etcd数据库，那么请求方默认会被设定为guest角色。默认情况下，etcd的guest角色具有所有键值资源的全局访问权限——默认情况下允许访问整个key空间是考虑到向后兼容

Permission

etcd提供了两种类型的权限（permission）：读和写。对权限的所有管理和设置都需要通过root角色来实现。权限列表是一个许可的特定权限（读或写）的列表

键值资源

键值资源是指存储在etcd中的键值对信息。给定一个用于匹配的模式列表，当用户请求的key值匹配模式列表中的某项时，相应的权限就会被授予。

当前，etcd只支持key值的前缀和精确匹配，其中前缀字符串以“ * ”结尾。例如“/foo”表示一个精确的key值或者目录，那么只能该key值或者目录授予权限，而不能为它的子节点授予权限，而“/foo*”表示所有以foo开头的key值或者目录都具有该权限。单独一个“ * ”表示具有该键值资源的完整权限

传输安全

etcd支持TLS协议加密通信。TLS通道技能用于加密etcd集群内部通信，也能加密客户端与服务端的通信。如果etcd服务启动时传入参数“–client-cert-auth=true”，那么客户端TLS证书的CN子段就能被用于标识一个etcd用户，默认使用该证书登录的用户即为权限管理系统中对应的用户，这样就无需在客户端在输入密码进行权限认证

etcd的传输层安全模型使用非对称加密模型，由公钥，私钥，证书。通信基础是公私钥以及证书系统。

TLS/SSL工作原理

最新版本的TLS是IETF指定的一种新协议，TLS建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本。TLS与SSL3.0之间的差异主要是他们所支持的加密算法不同，基本原理基本相同

SSL是一个安全协议，它基于TCP/IP通信应用程序提供了隐私与完整性。HTTPS便是使用SSL实现安全通信的。在客户端与服务器之间传输的数据是通过对称算法（DES或者RC4）进行加密的。公用密钥算法（RSA）用来获取加密密钥交换和数字签名，此算法使用服务器的SSL数字证书的公钥。有了服务器的SSL数字证书，客户端便可以便可以验证服务器的身份了。

SSL/TLS认证分为单向认证和双向认证两种方式。SSL协议的版本1和版本2只提供客户端对服务器的认证，即单向认证。版本3支持客户端和服务器端互相进行身份验证，即双向认证，此认证同时需要客户端和服务端的数字证书。

SSL连接总是由客户端启动的。SSL会话开始时会先进行SSL握手。客户端和服务端的SSL握手流程如下：

1. 客户端向服务器发送消息“你好”，消息中包含SSL版本，客户端支持的密码对和客户端支持的数据压缩方法（哈希函数）等，此外，还包括28子节二点随机数
2. 服务端以消息“您好”响应客户端，此消息包含密码对和由服务器选择的数据压缩方法，以及会话标识和另外一个随机数。
3. 服务器端向客户端发送其SSL数字证书。如果服务器端需要通过数字证书与客户端进行认证，则客户端会发出“数字证书请求”的消息。在“数字证书请求中”，服务端发出支持客户端数字证书类型的列表和可接受的CA名称
4. 服务器端发出“您好完成”的消息并等待客户端响应
5. 已接受到服务器“您好完成”消息，客户端就会验证服务器的SSL数字证书的有效性，并检查服务器的“您好”消息参数是否可以接受。如果服务器请求客户端数字证书，那么客户端将发送数字证书；如果没有合适的数字证书可用，那么客户端将发送“没有数字证书”的警告。此警告仅仅是警告而已，但是如果客户端数字证书认证是强制性的，那么服务器应用程序将会使会话失败。
6. 客户端发送“客户端密钥交换”消息。此消息包含pre-master secret（一个用于对称加密密钥生成的46字节的随机数字）和消息认证代码（MAC）密钥（用服务器的公钥加密的）。如果客户端向服务器发送数字证书，客户端将发出签有客户端u你的专用密钥的“数字证书认证”消息。通过验证此消息的签名，服务器可以显示验证客户端数字证书的所有权
7. 客户端使用一系列的加密算法将pre-master secret 转换为master secret，其中将派生出所有用于加密和消息认证的密钥。然后，客户端发出“更改密码规范”消息将服务器转换为新协商的密码对。客户端发出的下一个消息为用此密码方法和密钥加密的第一条消息
8. 服务器以自己的“更改密码规范”消息响应
9. SSL握手结束，并且可以发送加密的用户数据