Kubernetes 和业务组件混用同一个 etcd 集群，存在 Key 冲突的可能性，计划通过 etcd 自带的权限机制控制 Client 能够写入的路径。

Role-based access control

etcd v3 支持基于 RBAC 的用户权限管理机制，默认情况下 etcd 的权限管理功能是关闭的。

用户启动 etcd 后需要执行以下命令开启 etcd 的权限功能：

1
2
3
4
5
6
7

# 创建特殊 user 和 role ，并且绑定
etcdctl user add root --new-user-password=Hell0@ETCD
etcdctl role add root
etcdctl user grant-role root root

# 开启权限功能
etcdctl auth enable

etcd 要求用户在开启权限功能前，需要创建一个特殊的 user 和 role ，其中 root 用户作为 etcd 集群的超级用户，可以拥有所有权限， 而 root 角色拥有和 root 用户一致的权限，我们可以通 grant-role 命令将 root role 和任意 user 绑定。

创建 Kubenretes 角色

在使用 kubeadmin 部署 kubernetes 时，默认生成以下几个 client 证书用于访问 etcd：

  • /etc/kubernetes/pki/apiserver-etcd-client.crt
  • /etc/kubernetes/pki/etcd/healthcheck-client.crt

其对应的 CN 取值分别为：

  • kube-apiserver-etcd-client
  • kube-etcd-healthcheck-client

默认情况下 kube-apiserver 读写 etcd 时 key 的前缀是 “/registry” （可以通过参数 –etcd-prefix 指定），所以我们通过以下命令创建对应的 user 和 role。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 创建用户
etcdctl user add kube-apiserver-etcd-client   --new-user-password=kubernetes
etcdctl user add kube-etcd-healthcheck-client --new-user-password=kubernetes

# 创建 kubernetes role ，并配置读写权限
etcdctl role add kubernetes
etcdctl role grant-permission kubernetes --prefix=true readwrite /registry”

# 绑定 user 和 role
etcdctl user grant-role kube-apiserver-etcd-client   kubernetes
etcdctl user grant-role kube-etcd-healthcheck-client kubernetes

上述命令中，为 kubernetes 角色在 /registry 中创建了 readwrite 权限。目前 etcd 支持的权限类型非常简单，只有 readwrite、read、write 三种。

开启 Client Cert Auth

默认情况下，如果 etcd 通过 http 暴露 2379 端口时，用户读写 etcd 时需要提供对应的 user/password，对应的命令如下：

1
2

# 通过 User/Passwd 访问
etcdctl --user root --password Hell0@ETCD  get <key>

如果 etcd 通过 https 暴露 2379 端口，我们需要配置 –client-cert-auth=true ，此时客户端的 TLS 证书中 CN 字段将用作 etcd 用户，这种情况下，client 无需提供 user 的密码。

PS：gRPC-proxy 和 gRPC-gateway 场景中，server 端无法从 client 的证书中获取对应 CN 信息，因此用户需要额外传 user/password 信息。

PS：用户同时提供 tls 证书和 user/password 时，etcd 以后者为 认证的依据。

疑问：似乎不需要关心 peer 之间通信时的权限问题。

参考