1. etcc RBAC 认证
身份验证是在 etcd 2.1 中添加的。etcd v3 API 略微修改了身份验证功能的 API 和用户界面，以更好地适应新的数据模型。本指南旨在帮助用户在 etcd v3 中设置基本身份验证和基于角色的访问控制。
RBAC 是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。
1.1. 特殊用户和角色
有一个特殊用户 root 和一个特殊角色 root。
1.1.1. 特殊用户 root
在激活身份验证之前，必须创建对 etcd 具有完全访问权限的 root 用户。root 用户背后的想法是出于管理目的：管理角色和普通用户。该 root 用户必须具有 root 的作用，具有整个集群的管理权限，能够修改任何 etcd 中的配置。
注意：
在激活身份认证前，需要先创建好 root 用户，否则启用认证后无法再访问集群。
1.1.2. 特殊角色 root
可以将 root 角色授予除 root 用户之外的任何用户。具有该root角色的用户既具有全局读写访问权限，又具有更新集群的身份验证配置的权限。此外，该root角色还授予常规集群维护的特权，包括修改集群成员资格，对存储进行碎片整理以及创建快照。
1.2. 用户管理
etcdctl user 子命令能够处理所有用户相关事情。
可以通过以下方式找到用户列表：
$ etcdctl user list创建用户
$ etcdctl user add myusername创建新用户将提示您输入新密码。指定 --interactive=false 选项可以从标准输入中提供密码。
可以通过以下方式为用户授予和撤消角色：
$ etcdctl user grant-role myusername foo
$ etcdctl user revoke-role myusername bar可以使用以下命令检查用户的设置：
$ etcdctl user get myusername用户密码可以通过
$ etcdctl user passwd myusername更改密码将再次提示您输入新密码。指定 --interactive=false 选项可以从标准输入中提供密码。
删除具有以下内容的帐户：
$ etcdctl user delete myusername1.3. 角色管理
etcdctl role 子命令能够管理角色相关的事情。
列出角色：
$ etcdctl role list使用以下方法创建新角色：
$ etcdctl role add myrolename角色没有密码；它仅定义了一组新的访问权限。
授予角色访问单个 ke y或一系列 key 的权限。
范围可以指定为间隔[start-key，end-key]，其中 start-key 应按字母顺序在词汇上小于 end-key。
可以将访问权限授予读取，写入或同时授予两者，如以下示例所示：
# 授予 myrolename 角色对 key /foo 的 read 权限
$ etcdctl role grant-permission myrolename read /foo
# 首页 myrolename 对一批以 /foo/ 为前缀的 key 的 read 权限。这个前缀的范围是 [/foo/, /foo0) ，即包含 /foo/ 但不包含 /foo0
$ etcdctl role grant-permission myrolename --prefix=true read /foo/
# 授予 myrolename 角色对 key /foo/bar 的 write 权限
$ etcdctl role grant-permission myrolename write /foo/bar
# 授予 myrolename 角色对一个范围内的 key [key1, key5) 的完全访问权限，即 readwrite 权限
$ etcdctl role grant-permission myrolename readwrite key1 key5
# 授予 myrolename 角色对一批以 /pub/ 前缀的 key 的完全访问权限，即 readwrite
$ etcdctl role grant-permission myrolename --prefix=true readwrite /pub/要查看授予的权限，我们可以随时查看该角色：
$ etcdctl role get myrolename撤消权限是按照相同的逻辑方式完成的：
$ etcdctl role revoke-permission myrolename /foo/bar完全删除角色：
$ etcdctl role remove myrolename2. 启用身份验证
启用身份验证的步骤如下。管理员可以根据喜好在启用身份验证之前或之后设置用户和角色。
确保已创建root用户：
$ etcdctl user add root
Password of root:启用身份验证：
$ etcdctl auth enable此后，etcd 在启用身份验证的情况下运行。要出于任何原因禁用它，请使用 disable 命令：
$ etcdctl --user root:rootpw auth disable2.1. etcdctl 认证示例
etcdctl 支持与 curl 身份验证类似的标志。
$ etcdctl --user user:password get foo可以从提示符处输入密码：
$ etcdctl --user user get foo所有 etcdctl 命令使用方式均保持不变，只是每次操作都需要携带认证信息。
用户和角色仍然可以创建和修改，但是需要具有 root 角色的用户进行身份验证。
2.2. 使用 TLS 通用名称
从v3.2版本开始，如果使用参数 --client-cert-auth=true 启动etcd服务器，则客户端的TLS证书中的 “通用名称（CN）” 字段将用作 etcd 用户。在这种情况下，公用名将对用户进行身份验证，并且客户端不需要密码。
请注意，如果同时传递了 --client-cert-auth=true 且客户端提供了 CN，并且客户端提供了用户名和密码，则将优先考虑基于用户名和密码的身份验证。
请注意，此功能不能与 gRPC-proxy 和 gRPC-gateway 一起使用。这是因为 gRPC-proxy 会从其客户端终止 TLS，因此所有客户端都共享代理证书。 gRPC-gateway 内部使用 TLS 连接将 HTTP 请求转换为 gRPC 请求，因此它具有相同的限制。因此，客户端不能正确地将其 CN 提供给服务器。如果给定证书的 CN 不为空，则 gRPC-proxy 将导致错误并停止。 gRPC-proxy 返回错误，表明客户端证书中的CN为非空。
从 v3.3 版本开始，如果启用了带有选项 --peer-cert-allowed-cn 或 --peer-cert-allowed-hostname 的 etcd 服务器启动，则对等节点连接筛选。如果节点的 TLS 证书身份与允许的节点匹配，则节点只能加入 etcd 集群。