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 之间通信时的权限问题。

参考