【ETCD】ETCD用户密码认证

目录

概述

特殊用户和角色

root用户

root角色

用户操作

角色操作

启用身份验证

使用etcdctl进行身份验证

使用TLS通用名称

概述

etcd 2.1中增加了身份验证功能。etcd v3 API对身份验证功能的API和用户界面进行了轻微修改，以更好地适应新的数据模型。本指南旨在帮助用户在etcd v3中设置基本身份验证和基于角色的访问控制。

特殊用户和角色

有一个特殊用户root和一个特殊角色root。

root用户

root用户拥有对etcd的完全访问权限，必须在启用身份验证之前创建。root用户的理念是用于管理角色和普通用户。root用户必须具有root角色，并允许更改etcd内的任何内容。

root角色

除了root用户外，还可以将root角色授予任何用户。具有root角色的用户具有全局读写访问权限以及更新集群身份验证配置的权限。此外，root角色还授予一般集群维护的特权，包括修改集群成员、对存储进行碎片整理以及拍摄快照。

用户操作

etcdctl的用户子命令处理与用户帐户有关的所有事项。

可以使用以下命令列出用户：

$ etcdctl user list
root

创建用户非常简单，只需运行：

# 创建用户 yanhaihang
$ etcdctl user add yanhaihang
Password of yanhaihang:
Type password of yanhaihang again for confirmation:
User yanhaihang created

创建新用户时会提示输入新密码。当给出--interactive=false选项时，可以从标准输入提供密码。也可以使用--new-user-password选项提供密码。

可以使用以下命令为用户授予和撤销角色：

# 授予
$ etcdctl user grant-role  yanhaihang role_yhh
Role role_yhh is granted to user yanhaihang

# 撤销

etcdctl user revoke-role   yanhaihang role_yhh
Role role_yhh is revoked from user yanhaihang

可以使用以下命令检查用户的设置：

$ etcdctl user get yanhaihang
User: yanhaihang
Roles: role_yhh

$ etcdctl user get root
User: root
Roles:

并且可以使用以下命令更改用户的密码：

$ etcdctl user passwd yanhaihang
Password of yanhaihang:
Type password of yanhaihang again for confirmation:
Password updated

更改密码会再次提示输入新密码。当给出--interactive=false选项时，可以从标准输入提供密码。

使用以下命令删除帐户：

$ etcdctl user delete yanhaihang
User yanhaihang deleted

角色操作

etcdctl的角色子命令处理与授予单个用户的特定角色的访问控制有关的所有事项。

可以使用以下命令列出角色：

$  etcdctl role list
role_yhh
root

可以使用以下命令创建新角色：

# 创建root 角色

$ etcdctl role add root
Role root created

角色没有密码；它只是定义了一组新的访问权限。

角色被授予对单个键或一系列键的访问权限。

范围可以指定为区间[start-key, end-key)，其中start-key在字母顺序上应小于end-key。

可以像以下示例中那样授予读取、写入或两者的访问权限：

# 授予对键/foo的读取访问权限

$ etcdctl role grant-permission role_yhh read /foo
Role role_yhh updated


# 授予对以/foo/为前缀的键的读取访问权限。前缀等于范围[/foo/, /foo0)

$ etcdctl role grant-permission role_yhh  --prefix=true read /foo/
Role role_yhh updated

# 授予对/foo/bar处的键的仅写入访问权限

$ etcdctl role grant-permission role_yhh  write /foo/bar
Role role_yhh updated


# 授予对[key1, key5)范围内的键的完全访问权限

$ etcdctl role grant-permission role_yhh readwrite key1 key5
Role role_yhh updated

# 授予对以/pub/为前缀的键的完全访问权限
 etcdctl role grant-permission role_yhh --prefix=true readwrite /pub/


# 要查看授予的内容，我们可以随时查看角色：
$ etcdctl role get  role_yhh
Role role_yhh
KV Read:
	/foo
	[/foo/, /foo0) (prefix /foo/)
	[key1, key5)
KV Write:
	/foo/bar
	[key1, key5)


# 撤销权限的逻辑方式与授予权限相同：
$ etcdctl role revoke-permission role_yhh  /foo/bar
Permission of key /foo/bar is revoked from role role_yhh


# 就像完全删除角色一样：

$ etcdctl role remove myrolename

启用身份验证

启用身份验证的最小步骤如下。管理员可以根据喜好在启用身份验证之前或之后设置用户和角色。

本次操作为3.3版本

设置环境变量 设置为v3 版本

 export ETCDCTL_API=3

确保已创建root用户：

$ etcdctl user add root

启用身份验证：

$ etcdctl auth enable

开启身份认证后 如果不提供密码 再执行命令就会报以下错误 ：Error: etcdserver: user name is empty

$  etcdctl get /service/patroni_test_cluster/leader
Error: etcdserver: user name is empty

之后，etcd将以启用身份验证的方式运行。

如果出于某些原因要禁用它，请使用相反的命令：

# 关闭用户密码认证 
$ etcdctl --user root:root auth disable
Authentication Disabled

这样v3 版本的访问就需要用户密码了

v2版本???

$ etcdctl --version
etcdctl version: 3.3.11
API version: 2

为什么开启认证后不加用户密码还能查数据 新增数据？？

$ etcdctl ls
/mykey
$ etcdctl --username root:123456 ls
/mykey

但是查询用户却报权限问题 ，说明有认证

$ etcdctl user get yanhaihang
Insufficient credentials

$ etcdctl --username root:123456 user get yanhaihang
User: yanhaihang
Roles:

使用etcdctl进行身份验证

etcdctl支持与curl类似的身份验证标志。

 etcdctl  --user root:root  get /service/patroni_test_cluster/leader

密码可以从提示中获取：
 

 etcdctl  --user root  get /service/patroni_test_cluster/leader
Password:

密码也可以从命令行标志--password中获取：

V3.3 版本提示没有这个参数 Error: unknown flag: --password

 etcdctl  --user="root"  --password="root"  get   /service/patroni_test_cluster/leader
Error: unknown flag: --password

否则，所有etcdctl命令都保持不变。仍然可以创建和修改用户和角色，但需要具有root角色的用户进行身份验证。

使用TLS通用名称

从v3.2版本开始，如果etcd服务器使用选项--client-cert-auth=true启动，则客户端TLS证书中的通用名称（CN）字段将用作etcd用户。在这种情况下，通用名称会验证用户，并且客户端不需要密码。请注意，如果同时满足以下条件，则基于用户名和密码的身份验证将被优先：1. 传递了--client-cert-auth=true，并且客户端提供了CN；2. 客户端提供了用户名和密码。请注意，此功能不能与gRPC-proxy和gRPC-gateway一起使用。这是因为gRPC-proxy会终止来自其客户端的TLS，因此所有客户端都共享代理的证书。gRPC-gateway在将HTTP请求转换为gRPC请求时使用内部TLS连接，因此它也具有相同的限制。因此，客户端无法正确地向服务器提供其CN。如果给定的证书具有非空的CN，gRPC-proxy将引发错误并停止。gRPC-proxy返回一个错误，指示客户端的证书中具有非空的CN。

从v3.3版本开始，如果etcd服务器使用选项--peer-cert-allowed-cn启动，则会启用CN对等连接筛选。只有当它们的CN与允许的CN匹配时，节点才能加入etcd集群。有关更多详细信息，请参阅etcd安全页面。

版本 3.3

参考 

https://etcd.io/docs/v3.3/op-guide/authentication/

官方文章 Demo 中的 Auth章节

Demo | etcd