Kubernetes 1.6新特性：RBAC受權

概述

Kuberntes中API Server的訪問控制過程圖示以下：

在Kubernetes中，受權(authorization)是在認證(authentication)以後的一個步驟。受權就是決定一個用戶(普通用戶或ServiceAccount)是否有權請求Kubernetes API作某些事情。

以前，Kubernetes中的受權策略主要是ABAC(Attribute-Based Access Control)。對於ABAC，Kubernetes在實現上是比較難用的，並且須要Master Node的SSH和根文件系統訪問權限，受權策略發生變化後還須要重啓API Server。

Kubernetes 1.6中，RBAC(Role-Based Access Control)基於角色的訪問控制進入Beta階段。RBAC訪問控制策略可使用kubectl或Kubernetes API進行配置。使用RBAC能夠直接受權給用戶，讓用戶擁有受權管理的權限，這樣就再也不須要直接觸碰Master Node。在Kubernetes中RBAC被映射成API資源和操做。

RBAC API的資源對象

在Kubernetes 1.6中經過啓動參數--authorization-mode=RBAC.API Overview爲API Server啓用RBAC。

使用kubeadm初始化的1.6版本的Kubernetes集羣，已經默認爲API Server開啓了RBAC，能夠查看Master Node上API Server的靜態Pod定義文件：

1. cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep RBAC
2. - --authorization-mode=RBAC

RBAC API定義了四個資源對象用於描述RBAC中用戶和資源之間的鏈接權限：

• Role
• ClusterRole
• RoleBinding
• ClusterRoleBinding

Role和ClusterRole

Role是一系列權限的集合。Role是定義在某個Namespace下的資源，在這個具體的Namespace下使用。ClusterRole與Role類似，只是ClusterRole是整個集羣範圍內使用的。

下面咱們使用kubectl打印一下Kubernetes集羣中的Role和ClusterRole：

1. kubectl get roles --all-namespaces
2. NAMESPACE NAME AGE
3. kube-public system:bootstrap-signer-clusterinfo 6d
4. kube-public system:controller:bootstrap-signer 6d
5. kube-system extension-apiserver-authentication-reader 6d
6. kube-system system:controller:bootstrap-signer 6d
7. kube-system system:controller:token-cleaner 6d

1. kubectl get ClusterRoles
2. NAME AGE
3. admin 6d
4. cluster-admin 6d
5. edit 6d
6. flannel 5d
7. system:auth-delegator 6d
8. system:basic-user 6d
9. system:controller:attachdetach-controller 6d
10. ......
11. system:kube-aggregator 6d
12. system:kube-controller-manager 6d
13. system:kube-dns 6d
14. system:kube-scheduler 6d
15. system:node 6d
16. system:node-bootstrapper 6d
17. system:node-problem-detector 6d
18. system:node-proxier 6d
19. system:persistent-volume-provisioner 6d
20. view 6d

能夠看到以前建立的這個Kubernetes集羣中已經內置或建立不少的Role和ClusterRole。

下面在default命名空間內建立一個名稱爲pod-reader的Role，role-pord-reader.yaml文件以下：

1. kind: Role
2. apiVersion: rbac.authorization.k8s.io/v1beta1
3. metadata:
4. namespace: default
5. name: pod-reader
6. rules:
7. - apiGroups: [""] # "" indicates the core API group
8. resources: ["pods"]
9. verbs: ["get", "watch", "list"]

1. kubectl create -f role-pord-reader.yaml
2. role "pod-reader" created
3.  
4. kubectl get roles
5. NAME AGE
6. pod-reader 1m

注意RBAC在Kubernetes 1.6還處於Beta階段，因此API歸屬在rbac.authorization.k8s.io，上面的apiVersion爲rbac.authorization.k8s.io/v1beta1。

下面再給一個ClusterRole的定義文件：

1. kind: ClusterRole
2. apiVersion: rbac.authorization.k8s.io/v1beta1
3. metadata:
4. # "namespace" omitted since ClusterRoles are not namespaced
5. name: secret-reader
6. rules:
7. - apiGroups: [""]
8. resources: ["secrets"]
9. verbs: ["get", "watch", "list"]

RoleBinding和ClusterRoleBinding

RoleBinding把Role綁定到帳戶主體Subject，讓Subject繼承Role所在namespace下的權限。ClusterRoleBinding把ClusterRole綁定到Subject，讓Subject集成ClusterRole在整個集羣中的權限。

帳戶主體Subject在這裏仍是叫「用戶」吧，包含組group，用戶user和ServiceAccount。

1. kubectl get rolebinding --all-namespaces
2. NAMESPACE NAME AGE
3. kube-public kubeadm:bootstrap-signer-clusterinfo 6d
4. kube-public system:controller:bootstrap-signer 6d
5. kube-system system:controller:bootstrap-signer 6d
6. kube-system system:controller:token-cleaner 6d

1. kubectl get clusterrolebinding
2. NAME AGE
3. cluster-admin 6d
4. flannel 6d
5. kubeadm:kubelet-bootstrap 6d
6. kubeadm:node-proxier 6d
7. system:basic-user 6d
8. system:controller:attachdetach-controller 6d
9. system:controller:certificate-controller 6d
10. ......
11. system:controller:ttl-controller 6d
12. system:discovery 6d
13. system:kube-controller-manager 6d
14. system:kube-dns 6d
15. system:kube-scheduler 6d
16. system:node 6d
17. system:node-proxier 6d

實際上一個RoleBinding既能夠引用相同namespace下的Role；又能夠引用一個ClusterRole，RoleBinding引用ClusterRole時用戶繼承的權限會被限制在RoleBinding所在的namespace下。

1. kind: RoleBinding
2. apiVersion: rbac.authorization.k8s.io/v1beta1
3. metadata:
4. name: read-pods
5. namespace: default
6. subjects:
7. - kind: User
8. name: jane
9. apiGroup: rbac.authorization.k8s.io
10. roleRef:
11. kind: Role
12. name: pod-reader
13. apiGroup: rbac.authorization.k8s.io

1. kind: RoleBinding
2. apiVersion: rbac.authorization.k8s.io/v1beta1
3. metadata:
4. name: read-secrets
5. namespace: development # This only grants permissions within the "development" namespace.
6. subjects:
7. - kind: User
8. name: dave
9. apiGroup: rbac.authorization.k8s.io
10. roleRef:
11. kind: ClusterRole
12. name: secret-reader
13. apiGroup: rbac.authorization.k8s.io

Kubernetes中默認的Role和RoleBinding

API Server已經建立一系列ClusterRole和ClusterRoleBinding。這些資源對象中名稱以system:開頭的，表示這個資源對象屬於Kubernetes系統基礎設施。也就說RBAC默認的集羣角色已經完成足夠的覆蓋，讓集羣能夠徹底在 RBAC的管理下運行。修改這些資源對象可能會引發未知的後果，例如對於system:node這個ClusterRole定義了kubelet進程的權限，若是這個角色被修改，可能致使kubelet沒法工做。

可使用kubernetes.io/bootstrapping=rbac-defaults這個label查看默認的ClusterRole和ClusterRoleBinding：

1. kubectl get clusterrole -l kubernetes.io/bootstrapping=rbac-defaults
2. NAME AGE
3. admin 6d
4. cluster-admin 6d
5. edit 6d
6. system:auth-delegator 6d
7. system:basic-user 6d
8. system:controller:attachdetach-controller 6d
9. system:controller:certificate-controller 6d
10. ......
11. system:node-problem-detector 6d
12. system:node-proxier 6d
13. system:persistent-volume-provisioner 6d
14. view 6d

1. kubectl get clusterrolebinding -l kubernetes.io/bootstrapping=rbac-defaults
2. NAME AGE
3. cluster-admin 6d
4. system:basic-user 6d
5. system:controller:attachdetach-controller 6d
6. system:controller:certificate-controller 6d
7. system:controller:cronjob-controller 6d
8. system:controller:daemon-set-controller 6d
9. system:controller:deployment-controller 6d
10. ......
11. system:discovery 6d
12. system:kube-controller-manager 6d
13. system:kube-dns 6d
14. system:kube-scheduler 6d
15. system:node 6d
16. system:node-proxier 6d

關於這些角色詳細的權限信息能夠查看Default Roles and Role Bindings

參考

• Using RBAC Authorization
• RBAC Support in Kubernetes
• Controlling Accessing to the Kubernetes API

標題：Kubernetes 1.6新特性學習：RBAC受權
原創連接：http://blog.frognew.com/2017/04/kubernetes-1.6-rbac.html