小桀
01.理解Kubernetes中得User Account、Service Account

01.理解Kubernetes中得User Account、Service Account

为Kubernetes集群添加用户

本实验没有达到目标，稍后再整理

User Account应该是被创造出来的概念，我不确定Kubernetes中是否有这个概念。

Kubernetes不管理用户，但是在接受API请求时，是可以认知到发出请求的用户的。实际上，所有对Kubernetes的API请求都需要绑定身份信息（UserAccount或者ServiceAccount），这就意味着，可以为User配置Kubernetes集群中的请求权限。

Kubernetes不会管理User，所以User的创建、编辑、注销等都需要依赖外部的管理机制，Kubernetes所能认知的只有一个用户名。

尽管Kubernetes认知用户靠的只有用户的名字，但是只需要一个名字就能请求Kubernetes的API显然是不合理的，所以依然需要验证此用户的身份。Kubernetes中有如下验证方式：

  • X509客户端证书

    客户端证书验证通过为API Server指定–client-ca-file=xxx选项启动，API Servier通过此ca文件来验证API请求中携带的客户端证书的有效性，一旦验证成功，API Server就会将客户端证书Subject里的CN属性作为此次请求的用户名。

  • 静态Token文件（暂不研究）

  • 静态密码文件（暂不研究）

为用户生成证书

假设我们操作的用户名为Tom

  1. 为用户创建一个私钥
1
2
3


openssl genrsa -out tom.key 2048
  1. 为此私钥创建一个csr（证书签名请求）文件，需要在subject里带上用户信息（CN为用户名，O为用户组）
1
2
3


openssl req -new -key tom.key -out tom.csr -subj "/CN=tom/O=MGM"
  1. 找到Kubernetes集群（API Server）的CA证书文件（/etc/kubernetes/pki/ca.crt），通过集群的CA证书和之前创建的csr文件来为用户颁发证书：
1
2
3
4
5
6
7
8
9


openssl x509 -req \
    -in tom.csr \
    -CA /etc/kubernetes/pki/ca.crt \
    -CAkey /etc/kubernetes/pki/ca.key \
    -CAcreateserial \
    -out tom.crt \
    -days 365

/etc/kubernetes/pki下会有两个文件，一个是CA证书（ca.crt），一个是CA私钥（ca.key）。

为用户添加基于角色的访问控制

这儿我采用使用Kubernetes集群中内置的admin的ClusterRole的方式：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tom-admin-binding
  namespace: default
subjects:
- kind: User
  name: tom
  apiGroup: ""
roleRef:
  kind: ClusterRole
  name: admin
  apiGroup: ""

为kubectl配置用户