1. 程式人生 > >Kubernetes 1.6新特性學習:RBAC授權

Kubernetes 1.6新特性學習:RBAC授權

概述

Kuberntes中API Server的訪問控制過程圖示如下:

access-control-overview

在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 getClusterRoles
  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. kubectl get roles
  4. NAME AGE
  5. pod-reader 1m

注意RBAC在Kubernetes 1.6還處於Beta階段,所以API歸屬在rbac.authorization.k8s.io,上面的apiVersionrbac.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