k8s之RBAC-基于角色的访问控制

一个在名称空间内的对象的完整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/