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