答案是同一个。
我们可以验证一下。
首先,检查k8s里面是否有user/group的资源。
kubectl api-resources | grep user
kubectl api-resources | grep group
执行上面两种命令,发现并没有输出。说明user和group不是k8s的资源。serviceAccount是的。
我们在官网发现RBAC那一章有写到限制用户访问集群资源。
我们用以下例子来测试, 一个是创建ClusterRole,这个角色可以访问pods的资源。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: jaymz-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"]
接下是将ClusterRole和User进行绑定,意思是user jaymz具有访问集群pods的权限。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: read-pods-global
subjects:
- kind: User
name: jaymz
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: jaymz-reader
apiGroup: rbac.authorization.k8s.io
当然为了验证这个用户是不是对应着linux的用户,我们暂且不创建这两个yaml。
接下来,我们在linux上创建一个叫jaymz的用户。
useradd jaymz
passwd jaymz
输入密码后,表明用户创建成功。
然后将该用户创建对应的证书,表明该用户是可以接触到集群。
openssl genrsa -out jaymz.key 2048
openssl req -new -key jaymz.key -out jaymz.csr -subj "/CN=jaymz"
openssl x509 -req -in jaymz.csr -CA /etc/kubernetes/pki/ca.crt -CAkey /etc/kubernetes/pki/ca.key -CAcreateserial -out jaymz.crt -days 365
openssl x509 -in jaymz.crt -text -noout
kubectl config set-credentials jaymz --client-certificate=jaymz.crt --client-key=jaymz.key --embed-certs=true
kubectl config set-context jaymz@kubernetes --cluster=kubernetes --user=jaymz
kubectl config use-context jaymz@kubernetes
执行完之后,我们发现已经切换到jaymz这个用户连接集群。然后执行kubectl get pods -A,发现:
image.png当我们执行上述创建好的clusterrole和clusterrolebinding,再次执行该命令,发现就可以拿到pods的信息了。
image.png
网友评论