在任何将资源或服务提供给有限使用者的系统上,认证和授权都是两个必不可少的功 能,认证用于身份鉴别,而授权则实现权限分派 。 认证由 API Server 来完成,授权有 RABC 来完成。
认证:API Server 作为 Kubernetes 集群系统的网关,是访问及管理资源对象的唯一人口,所有需要访问集群资源的组件,以及此前使用的 kubectl 命令等都要经由此网关进行集群访问和管理。
授权:RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策,允许管理员通过 Kubernetes API 动态配置策略,要启用RBAC,需要在 apiserver 中添加参数–authorization-mode=RBAC,如果使用的kubeadm安装的集群,都默认开启了RBAC,可以通过查看 Master 节点上 apiserver 的静态Pod定义文件:
为了彻底搞懂认证和授权整个过程,干脆自己新建一个用户,放到 /root/.kube/config 文件下面去
第一步,生产密钥 .key 文件
# 进入目录
cd /etc/kubernetes/pki
# 生产密钥 .key 文件 (pki目录下执行)
(umask 077;openssl genrsa -out cbmljs.key 2048)
第二步,根据 .key 文件输出 .csr 文件,从此两个文件建立了关系
# 根据刚刚生成的 .key 文件输出 .csr 文件 (pki目录下执行)
openssl req -new -key cbmljs.key -out cbmljs.csr -subj "/O=k8s/CN=cbmljs"
O=组织信息,CN=用户名
这里可以设置为 /O=k8s/CN=cbmljs ,也可以设置为 /O=kubernetes/CN=cbmljs
第三步,根据 .key 和 .csr 文件生成了 .crt 文件
# 根据 .key 和 .csr 文件生成了 .crt 文件 (pki目录下执行)
openssl x509 -req -in cbmljs.csr -CA ca.crt -CAkey ca.key \
-CAcreateserial -out cbmljs.crt -days 365
好了,pki下面的三个文件结束了,下面开始生成 /root/.kube/config 文件
三个文件生成顺序:cbmljs.key -> cbmljs.csr -> cbmljs.crt ,这三个文件的表示用户
/root/.kube/config 文件是 cluster + user 组成 context
第一,cluster 是 base64 /etc/kubernetes/pki/ca.crt 构成的,对于同一个集群,所有用户都相同的
第二,user 是 base64 /etc/kubernetes/pki/cbmljs.key 和 base64 /etc/kubernetes/pki/cbmljs.crt 构成的,每个用户都不一样,比如 kubernetes-admin 用户和 cbmljs 用户不一样
第三,cluster + user 组成 context
创建集群配置clusters,如下:
# 新建集群配置 (pki目录下执行)
kubectl config set-cluster k8s --server=https://192.168.100.151:6443 \
--certificate-authority=ca.crt --embed-certs=true --kubeconfig=/root/cbmljs.conf
这一句会在 root 目录下,新建或修改一个文件 cbmljs.conf,创建完集群配置之后,查看这个 cbmljs.conf 文件,如下:
# 查看 (pki目录下执行)
kubectl config view --kubeconfig=/root/cbmljs.conf
创建用户配置users,语句是 set-credentials ,如下:
# 新建用户配置 (pki目录下执行)
kubectl config set-credentials cbmljs --client-certificate=cbmljs.crt \
--client-key=cbmljs.key --embed-certs=true --kubeconfig=/root/cbmljs.conf
创建完用户配置之后,查看
# 查看 (pki目录下执行)
kubectl config view --kubeconfig=/root/cbmljs.conf
创建context配置,语句是 set-context,如下:
# 新建上下文配置 (pki目录下执行)
kubectl config set-context cbmljs@k8s --cluster=k8s --user=cbmljs \
--kubeconfig=/root/cbmljs.conf
创建完context配置之后,查看
# 查看 (pki目录下执行)
kubectl config view --kubeconfig=/root/cbmljs.conf
刚刚新建好了context,现在切换context
# 切换上下文配置 (pki目录下执行)
kubectl config use-context cbmljs@k8s --kubeconfig=/root/cbmljs.conf
切换完context配置之后,查看
# 查看 (pki目录下执行)
kubectl config view --kubeconfig=/root/cbmljs.conf
好了,整个 /root/cbmljs.conf 文件完成了,现在开始使用这个文件了。
linux上新增一个用户 cbmljs ,然后将这个新生成的 cbmljs.conf 文件放到 /home/cbmljs/.kube/config 目录下
useradd cbmljs
mkdir -p /home/cbmljs/.kube
cd /root
cp cbmljs.conf /home/cbmljs/.kube/config
chown cbmljs.cbmljs -R /home/cbmljs/
su cbmljs
kubectl get pod
vi pods-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: pods-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
vi cbmljs-pods-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: cbmljs-pods-reader
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: pods-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cbmljs
但是此时查看其他命名空间的资源权限还是没有,另外,新建/修改/删除 default命名空间的资源 resources 的权限也没有
[root@w1 serviceaccount]# cat cluster-reader.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: cluster-reader
rules:
- apiGroups:
- ""
resources:
- pods
verbs:
- get
- list
- watch
[root@w1 serviceaccount]# cat cbmljs-read-all-pod.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: billy-read-all-pods
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-reader
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: cbmljs
新建用户账号UserAccount(实践类),完成了。
天天打码,天天进步!!
参考资料:https://blog.csdn.net/cbmljs/article/details/102953428