一個在名稱空間內的對象的完整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/