一个在名称空间内的对象的完整url模板:
Object_URL: /apis/<GROUP>/<VERSION>/namespaces/<NAMESPACE_NAME>/<KIND>[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 yaml cat role-demo.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pods-reader namespace: default rules: - 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-run apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: creationTimestamp: null name: lixiang-read-pods roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: pods-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: lixiang-test # 此时我创建了一个lixiang-test,它被绑定在pods-reader上 kubectl config use-context lixiang-test@kubernetes error: no context exists with the name: "lixiang-test@kubernetes". # 说明:名字不能瞎写,得和前面的创建的lixiang@kubernetes保持一致 kubectl delete rolebinding lixiang-read-pods kubectl 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-run apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: creationTimestamp: null name: cluster-reader rules: - 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=lixiang apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRoleBinding metadata: name: lixiang-read-all-pods roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-reader subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: lixiang # 通过RoleBinding把用户user绑定到ClusterRole上,RoleBinding在哪个ns,则用户就只有该ns的管理权限 kubectl delete clusterrolebinding lixiang-read-all-pods kubectl 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 yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
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-000c29b388a2
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: Group
name: system:masters
openssl x509 -in ./apiserver-kubelet-client.crt -text -noout
Subject: 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/