rbac权限管理5张表_k8s之RBAC-基于角色的访问控制

一个在名称空间内的对象的完整url模板:

Object_URL: /apis///namespaces//[OJJECT_ID]

role based access control,将权限授权给角色role,让用户扮演某个角色,这样用户就会有对应的权限.

许可授权:定义role时,会标明对哪些对象(object),做哪些操作(operations)

图解:名称空间级别的 Role,通过 RoleBinding 把用户 user 绑定到 Role 上,那么这个用户就有了管理整个名称空间的权限;集群级别的 ClusterRole,通过 ClusterRoleBinding 将用户 user 绑定到 ClusterRole 上,则该用户就有了管理整个集群的权限;通过 RoleBinding 把用户 user 绑定到 ClusterRole 上,用户依然只有管理某个名称空间的权限,但这样做的好处是不用在每个 ns 中都创建 Role 了.

1.创建一个 role

kubectl create role pods-reader --verb=get,list,watch --resource=pods --dry-run -o yamlcat role-demo.yamlapiVersion: rbac.authorization.k8s.io/v1kind: Rolemetadata:  name: pods-reader  namespace: defaultrules:- apiGroups:  - ""  resources:  - pods  verbs:  - get  - list  - watch kubectl apply -f role-demo.yaml# 通过RoleBinding把用户User绑定到Role上kubectl create rolebinding lixiang-read-pods --role=pods-reader --user=lixiang-test -o yaml --dry-runapiVersion: rbac.authorization.k8s.io/v1kind: RoleBindingmetadata:  creationTimestamp: null  name: lixiang-read-podsroleRef:  apiGroup: rbac.authorization.k8s.io  kind: Role  name: pods-readersubjects:- apiGroup: rbac.authorization.k8s.io  kind: User  name: lixiang-test # 此时我创建了一个lixiang-test,它被绑定在pods-reader上kubectl config use-context lixiang-test@kuberneteserror: no context exists with the name: "lixiang-test@kubernetes".# 说明:名字不能瞎写,得和前面的创建的lixiang@kubernetes保持一致kubectl delete rolebinding lixiang-read-podskubectl create rolebinding lixiang-read-pods --role=pods-reader --user=lixiang# 切换用户后,即可获取default下的pod读权限kubectl config use-context lixiang@kubernetes

一般这么用:系统上有一个普通用户,将~/.kube/ 拷贝到 /home/user/ 目录下,修改权限,然后切到某个context下,获取对应资源.

2.创建一个 clusterrole

kubectl create clusterrole cluster-reader --verb=get,list,watch --resource=pods -o yaml --dry-runapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:  creationTimestamp: null  name: cluster-readerrules:- apiGroups:  - ""  resources:  - pods  verbs:  - get  - list  - watch kubectl delete rolebinding lixiang-read-pods# 让用户lixiang扮演clusterrole,此时该用户有了整个集群的读权限kubectl create clusterrolebinding lixiang-read-all-pods --clusterrole=cluster-reader --user=lixiangapiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata:  name: lixiang-read-all-podsroleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-readersubjects:- apiGroup: rbac.authorization.k8s.io  kind: User  name: lixiang # 通过RoleBinding把用户user绑定到ClusterRole上,RoleBinding在哪个ns,则用户就只有该ns的管理权限kubectl delete clusterrolebinding lixiang-read-all-podskubectl create rolebinding lixiang-read-pods --clusterrole=cluster-reader --user=lixiang# admin和cluster-admin有哪些权限kubectl get clusterrole admin -o yaml# 将用户rolebinding到admin上,它就成了default名称空间的管理员kubectl create rolebinding whatever --clusterrole=admin --user=lixiang

3.kubernetes-admin 是如何获得整个集群的权限的

kubectl get clusterrolebinding cluster-admin -o yamlapiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:  annotations:    rbac.authorization.kubernetes.io/autoupdate: "true"  creationTimestamp: "2019-04-24T07:33:08Z"  labels:    kubernetes.io/bootstrapping: rbac-defaults  name: cluster-admin  resourceVersion: "108"  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/cluster-admin  uid: 350c92f1-6663-11e9-acc0-000c29b388a2roleRef:  apiGroup: rbac.authorization.k8s.io  kind: ClusterRole  name: cluster-adminsubjects:- apiGroup: rbac.authorization.k8s.io  kind: Group  name: system:masters openssl x509 -in ./apiserver-kubelet-client.crt -text -nooutSubject: O=system:masters, CN=kube-apiserver-kubelet-client

用 ClusterRoleBinding 将 system:masters 这个组绑定到了 cluster-admin 上,kubectl config view得到 kubernetes-admin 管理着整个集群,它的 CN 名字是 kube-apiserver-kubelet-client,所以它的组是 system:masters,所以这个用户有 cluster-admin 的所有权限.

subject 的 kind 还可以是 ServiceAccount,即将这些 sa 绑定到集群角色或名称空间角色上,使得以这个 sa 启动的 pod 对名称空间或集群有了一定权限,可以参考 ingress-nginx.

参考博客:http://blog.itpub.net/28916011/viewspace-2215100/