一、role和ClusterRole使用场景
### --- role和ClusterRole
~~~ # 该使用role还是该使用ClusterRole?
~~~ 当为某一个namespace去创建一个单独的role的话是没有去创建ClusterRole的,
~~~ 若是有很多namespace,需要创建相同的权限,这时候创建ClusterRole是比较合理的,
~~~ 因为ClusterRole既可以作用于整个集群也可以作用于单个集群。
~~~ 这个作用于谁呢?取决于RoleBinding和ClusterroleBingding
~~~ RoleBinding作用于命名空间内,将ClusterRole绑定到user,group,ServiceAccount
~~~ # ClusterRoleBinding:
~~~ 也是将ClusterRole绑定到user,group,ServiceAccount,只是作用于整个集群。
二、RoleBinding的用途
### --- 查看ingress-nginx的RoleBinding
[root@k8s-master01 ~]# kubectl get rolebinding --all-namespaces
NAMESPACE NAME ROLE AGE
ingress-nginx ingress-nginx Role/ingress-nginx 10d
~~~ # 这个serviceaccount会经常会用到的,它会把一些权限定义到serviceaccount上,
~~~ 这个ServiceAccount可以直接给pod去用,
~~~ 就是启动pod的时候可以直接指定用哪个ServiceAccount去启用
[root@k8s-master01 ~]# kubectl get rolebinding ingress-nginx -n ingress-nginx -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding // 查看到RoleBinding作用于ingress-nginx这个namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role // 它把这个role绑定到了ingress-nginx的这个角色上面
name: ingress-nginx
subjects:
- kind: ServiceAccount // 这个serviceaccount所在的namespace所在是在ingree-nginx的namespace下
name: ingress-nginx // 它把这个role绑定到了ingress-nginx的这个角色上面
namespace: ingress-nginx
### --- 查看ingress-nginx的ServiceAccount的权限
[root@k8s-master01 ~]# kubectl edit ds -n ingress-nginx
securityContext: {}
serviceAccount: ingress-nginx // 指定了运行容器的serviceaccount是谁,
serviceAccountName: ingress-nginx // 就会以这个serviceaccount去运行这个容器,这个容器就会有ServiceAccount这个权限,也就是说,它有了这个名字为ingress-nginx的ServiceAccount的权限。
terminationGracePeriodSeconds: 300
三、创建一个RoleBinding并绑定用户
### --- 就是首先创建了一个role,
[root@k8s-master01 ~]# kubectl get role -n ingress-nginx
NAME CREATED AT
ingress-nginx 2021-04-21T16:09:29Z
### --- 这个role定义了一些权限
[root@k8s-master01 ~]# kubectl get role -n ingress-nginx -oyaml
- apiVersion: rbac.authorization.k8s.io/v1
kind: Role
manager: Go-http-client
operation: Update
time: "2021-04-21T16:09:29Z"
name: ingress-nginx // 这个角色具有了下面的权限
namespace: ingress-nginx
rules: // 权限列表
- apiGroups:
- ""
resources:
- namespaces
verbs:
- get
### --- 把这个角色的权限绑定到一个叫ingress-nginx的ServiceAccount上面,
[root@k8s-master01 ~]# kubectl get rolebinding -n ingress-nginx -oyaml
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: ingress-nginx
subjects:
- kind: ServiceAccount // 这个serviceaccount就有了上面创建的role所有的权限
name: ingress-nginx // 把这个角色的权限绑定到一个叫ingress-nginx的ServiceAccount上面,
namespace: ingress-nginx
### --- 又在ds的serviceaccount里面,设置了serviceaccountname的名字叫ubgress-nginx,
~~~ 就是绑定权限的ServiceAccount
~~~ 注:所以说这个pod就是以这个身份去启动的然后这个pod就具有了这个ServiceAccount:
~~~ ingress-nginx 的所有的权限
~~~ 若是不指定这个serviceacount的权限,就是以默认的的default去启动。
~~~ default是没有什么权限的。
[root@k8s-master01 ~]# kubectl edit ds -n ingress-nginx
securityContext: {}
serviceAccount: ingress-nginx
serviceAccountName: ingress-nginx // 又在ds的serviceaccount里面,设置了serviceaccountname的名字叫ubgress-nginx,就是绑定权限的ServiceAccount
四、ClusterRoleBinding用途
### --- 查找一个具有ClusterRoleBinding权限的容器
~~~ 注:在创建dashboard的时候有一个步骤是创建admin用户,
[root@k8s-master01 ~]# kubectl get clusterrolebinding
NAME ROLE AGE
kubernetes-dashboard ClusterRole/kubernetes-dashboard
### --- admin用户具有权限的操作:
~~~ 查看ClusterRoleBinding配置的权限
[root@k8s-master01 ~]# kubectl get clusterrolebinding kubernetes-dashboard -oyaml
### --- 创建管理员用户的时候创建了一个admin-user的角色
~~~ 查看admin-user用户
[root@k8s-master01 ~]# kubectl get clusterrolebinding admin-user -oyaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding //ClusterRoleBinding集群角色绑定
*****省略部分内容***********
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin //把cluser-admin的clusterrole绑定到admin-user的serviceaccount上面
subjects:
- kind: ServiceAccount
name: admin-user
namespace: kube-system