Kubernetes用户

所有 Kubernetes 集群都有两类用户：由 Kubernetes 管理的服务账号和普通用户。 服务账号就是serviceaccount,普通用户就是kubeconfig中的user。

普通用户

Kubernetes 假定普通用户是由一个与集群无关的服务通过以下方式之一进行管理的：

· 负责分发私钥的管理员

· 类似 Keystone 或者 Google Accounts 这类用户数据库

· 包含用户名和密码列表的文件

有鉴于此，Kubernetes 并不包含用来代表普通用户账号的对象。 普通用户的信息无法通过 API 调用添加到集群中。

尽管无法通过 API 调用来添加普通用户， Kubernetes 仍然认为能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。 基于这样的配置，Kubernetes 使用证书中的 'subject' 的通用名称（Common Name）字段 （例如，"/CN=bob"）来确定用户名。 接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对某资源执行特定的操作。 进一步的细节可参阅证书请求 下普通用户主题。

服务账号

与此不同，服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间， 或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。

API 请求则或者与某普通用户相关联，或者与某服务账号相关联， 亦或者被视作匿名请求。这意味着集群内外的每个进程在向 API 服务器发起请求时都必须通过身份认证，否则会被视作匿名用户。这里的进程可以是在某工作站上输入 kubectl 命令的操作人员，也可以是节点上的 kubelet 组件，还可以是控制面的成员。

创建普通用户

#为用户abcd生成kubeconfig文件
kubeadm alpha kubeconfig user --client-name=abcd --config=/root/yaml/kubeadm.yml

kubectl create serviceaccount test-read
kubectl apply -f readaccount-clusterrole.yaml

kubectl create clusterrolebinding read-bing --clusterrole=readonly-role --user=abcd

创建服务账户

kubectl create serviceaccount test-read
kubectl apply -f readaccount-clusterrole.yaml

kubectl create clusterrolebinding read-bing --clusterrole=readonly-role --serviceaccount=default:test-read