ETCD 权限管理
文章目录
Kubernetes 和业务组件混用同一个 etcd 集群,存在 Key 冲突的可能性,计划通过 etcd 自带的权限机制控制 Client 能够写入的路径。
Role-based access control
etcd v3 支持基于 RBAC 的用户权限管理机制,默认情况下 etcd 的权限管理功能是关闭的。
用户启动 etcd 后需要执行以下命令开启 etcd 的权限功能:
|
|
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。
|
|
上述命令中,为 kubernetes 角色在 /registry 中创建了 readwrite 权限。目前 etcd 支持的权限类型非常简单,只有 readwrite、read、write 三种。
开启 Client Cert Auth
默认情况下,如果 etcd 通过 http 暴露 2379 端口时,用户读写 etcd 时需要提供对应的 user/password,对应的命令如下:
|
|
如果 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 之间通信时的权限问题。
参考
文章作者 yoaz
上次更新 2022-12-07
许可协议 MIT