RBAC——基于角色的訪問控制 · kubernetes完整攻略

# RBAC——基于角色的訪問控制以下內容是 [xingzhou](https://github.com/xingzhou) 對 kubernetes 官方文檔的翻譯，原文地址 https://k8smeetup.github.io/docs/admin/authorization/rbac/ 基于角色的訪問控制（Role-Based Access Control, 即”RBAC”）使用”rbac.authorization.k8s.io” API Group實現授權決策，允許管理員通過Kubernetes API動態配置策略。截至Kubernetes 1.6，RBAC模式處于beta版本。要啟用RBAC，請使用`--authorization-mode=RBAC`啟動API Server。 ## API概述本節將介紹RBAC API所定義的四種頂級類型。用戶可以像使用其他Kubernetes API資源一樣（例如通過`kubectl`、API調用等）與這些資源進行交互。例如，命令`kubectl create -f (resource).yml` 可以被用于以下所有的例子，當然，讀者在嘗試前可能需要先閱讀以下相關章節的內容。 ### Role與ClusterRole 在RBAC API中，一個角色包含了一套表示一組權限的規則。權限以純粹的累加形式累積（沒有”否定”的規則）。角色可以由命名空間（namespace）內的`Role`對象定義，而整個Kubernetes集群范圍內有效的角色則通過`ClusterRole`對象實現。一個`Role`對象只能用于授予對某一單一命名空間中資源的訪問權限。以下示例描述了”default”命名空間中的一個`Role`對象的定義，用于授予對pod的讀訪問權限： ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # 空字符串""表明使用core API group resources: ["pods"] verbs: ["get", "watch", "list"] ``` `ClusterRole`對象可以授予與`Role`對象相同的權限，但由于它們屬于集群范圍對象，也可以使用它們授予對以下幾種資源的訪問權限： - 集群范圍資源（例如節點，即node） - 非資源類型endpoint（例如”/healthz”） - 跨所有命名空間的命名空間范圍資源（例如pod，需要運行命令`kubectl get pods --all-namespaces`來查詢集群中所有的pod）下面示例中的`ClusterRole`定義可用于授予用戶對某一特定命名空間，或者所有命名空間中的secret（取決于其[綁定](https://k8smeetup.github.io/docs/admin/authorization/rbac/#rolebinding-and-clusterrolebinding)方式）的讀訪問權限： ```yaml kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: # 鑒于ClusterRole是集群范圍對象，所以這里不需要定義"namespace"字段 name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] ``` ### RoleBinding與ClusterRoleBinding 角色綁定將一個角色中定義的各種權限授予一個或者一組用戶。角色綁定包含了一組相關主體（即subject, 包括用戶——User、用戶組——Group、或者服務賬戶——Service Account）以及對被授予角色的引用。在命名空間中可以通過`RoleBinding`對象授予權限，而集群范圍的權限授予則通過`ClusterRoleBinding`對象完成。 `RoleBinding`可以引用在同一命名空間內定義的`Role`對象。下面示例中定義的`RoleBinding`對象在”default”命名空間中將”pod-reader”角色授予用戶”jane”。這一授權將允許用戶”jane”從”default”命名空間中讀取pod。 ```yaml # 以下角色綁定定義將允許用戶"jane"從"default"命名空間中讀取pod。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-pods namespace: default subjects: - kind: User name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io ``` `RoleBinding`對象也可以引用一個`ClusterRole`對象用于在`RoleBinding`所在的命名空間內授予用戶對所引用的`ClusterRole`中定義的命名空間資源的訪問權限。這一點允許管理員在整個集群范圍內首先定義一組通用的角色，然后再在不同的命名空間中復用這些角色。例如，盡管下面示例中的`RoleBinding`引用的是一個`ClusterRole`對象，但是用戶”dave”（即角色綁定主體）還是只能讀取”development” 命名空間中的secret（即`RoleBinding`所在的命名空間）。 ```yaml # 以下角色綁定允許用戶"dave"讀取"development"命名空間中的secret。 kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets namespace: development # 這里表明僅授權讀取"development"命名空間中的資源。 subjects: - kind: User name: dave apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io ``` 最后，可以使用`ClusterRoleBinding`在集群級別和所有命名空間中授予權限。下面示例中所定義的`ClusterRoleBinding` 允許在用戶組”manager”中的任何用戶都可以讀取集群中任何命名空間中的secret。 ```yaml # 以下`ClusterRoleBinding`對象允許在用戶組"manager"中的任何用戶都可以讀取集群中任何命名空間中的secret。 kind: ClusterRoleBinding apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: read-secrets-global subjects: - kind: Group name: manager apiGroup: rbac.authorization.k8s.io roleRef: kind: ClusterRole name: secret-reader apiGroup: rbac.authorization.k8s.io ``` ### 對資源的引用大多數資源由代表其名字的字符串表示，例如”pods”，就像它們出現在相關API endpoint的URL中一樣。然而，有一些Kubernetes API還包含了”子資源”，比如pod的logs。在Kubernetes中，pod logs endpoint的URL格式為： ``` GET /api/v1/namespaces/{namespace}/pods/{name}/log ``` 在這種情況下，”pods”是命名空間資源，而”log”是pods的子資源。為了在RBAC角色中表示出這一點，我們需要使用斜線來劃分資源與子資源。如果需要角色綁定主體讀取pods以及pod log，您需要定義以下角色： ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: pod-and-pod-logs-reader rules: - apiGroups: [""] resources: ["pods", "pods/log"] verbs: ["get", "list"] ``` 通過`resourceNames`列表，角色可以針對不同種類的請求根據資源名引用資源實例。當指定了`resourceNames`列表時，不同動作種類的請求的權限，如使用”get”、”delete”、”update”以及”patch”等動詞的請求，將被限定到資源列表中所包含的資源實例上。例如，如果需要限定一個角色綁定主體只能”get”或者”update”一個configmap時，您可以定義以下角色： ```yaml kind: Role apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: namespace: default name: configmap-updater rules: - apiGroups: [""] resources: ["configmap"] resourceNames: ["my-configmap"] verbs: ["update", "get"] ``` 值得注意的是，如果設置了`resourceNames`，則請求所使用的動詞不能是list、watch、create或者deletecollection。由于資源名不會出現在create、list、watch和deletecollection等API請求的URL中，所以這些請求動詞不會被設置了`resourceNames` 的規則所允許，因為規則中的`resourceNames`部分不會匹配這些請求。 #### 一些角色定義的例子在以下示例中，我們僅截取展示了`rules`部分的定義。允許讀取core API Group中定義的資源”pods”： ```yaml rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] ``` 允許讀寫在”extensions”和”apps” API Group中定義的”deployments”： ```yaml rules: - apiGroups: ["extensions", "apps"] resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` 允許讀取”pods”以及讀寫”jobs”： ```yaml rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list", "watch"] - apiGroups: ["batch", "extensions"] resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` 允許讀取一個名為”my-config”的`ConfigMap`實例（需要將其通過`RoleBinding`綁定從而限制針對某一個命名空間中定義的一個`ConfigMap`實例的訪問）： ```yaml rules: - apiGroups: [""] resources: ["configmaps"] resourceNames: ["my-config"] verbs: ["get"] ``` 允許讀取core API Group中的”nodes”資源（由于`Node`是集群級別資源，所以此`ClusterRole`定義需要與一個`ClusterRoleBinding`綁定才能有效）： ```yaml rules: - apiGroups: [""] resources: ["nodes"] verbs: ["get", "list", "watch"] ``` 允許對非資源endpoint “/healthz”及其所有子路徑的”GET”和”POST”請求（此`ClusterRole`定義需要與一個`ClusterRoleBinding`綁定才能有效）： ```yaml rules: - nonResourceURLs: ["/healthz", "/healthz/*"] # 在非資源URL中，'*'代表后綴通配符 verbs: ["get", "post"] ``` ### 對角色綁定主體（Subject）的引用 `RoleBinding`或者`ClusterRoleBinding`將角色綁定到*角色綁定主體*（Subject）。角色綁定主體可以是用戶組（Group）、用戶（User）或者服務賬戶（Service Accounts）。用戶由字符串表示。可以是純粹的用戶名，例如”alice”、電子郵件風格的名字，如 “bob@example.com” 或者是用字符串表示的數字id。由Kubernetes管理員配置[認證模塊](https://k8smeetup.github.io/docs/admin/authentication/) 以產生所需格式的用戶名。對于用戶名，RBAC授權系統不要求任何特定的格式。然而，前綴`system:`是為Kubernetes系統使用而保留的，所以管理員應該確保用戶名不會意外地包含這個前綴。 Kubernetes中的用戶組信息由授權模塊提供。用戶組與用戶一樣由字符串表示。Kubernetes對用戶組字符串沒有格式要求，但前綴`system:`同樣是被系統保留的。 [服務賬戶](https://k8smeetup.github.io/docs/tasks/configure-pod-container/configure-service-account/)擁有包含 `system:serviceaccount:`前綴的用戶名，并屬于擁有`system:serviceaccounts:`前綴的用戶組。 #### 角色綁定的一些例子以下示例中，僅截取展示了`RoleBinding`的`subjects`字段。一個名為”alice@example.com”的用戶： ```yaml subjects: - kind: User name: "alice@example.com" apiGroup: rbac.authorization.k8s.io ``` 一個名為”frontend-admins”的用戶組： ```yaml subjects: - kind: Group name: "frontend-admins" apiGroup: rbac.authorization.k8s.io ``` kube-system命名空間中的默認服務賬戶： ```yaml subjects: - kind: ServiceAccount name: default namespace: kube-system ``` 名為”qa”命名空間中的所有服務賬戶： ```yaml subjects: - kind: Group name: system:serviceaccounts:qa apiGroup: rbac.authorization.k8s.io ``` 在集群中的所有服務賬戶： ```yaml subjects: - kind: Group name: system:serviceaccounts apiGroup: rbac.authorization.k8s.io ``` 所有認證過的用戶（version 1.5+）： ```yaml subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io ``` 所有未認證的用戶（version 1.5+）： ```yaml subjects: - kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io ``` 所有用戶（version 1.5+）： ```yaml subjects: - kind: Group name: system:authenticated apiGroup: rbac.authorization.k8s.io - kind: Group name: system:unauthenticated apiGroup: rbac.authorization.k8s.io ``` ## 默認角色與默認角色綁定 API Server會創建一組默認的`ClusterRole`和`ClusterRoleBinding`對象。這些默認對象中有許多包含`system:`前綴，表明這些資源由Kubernetes基礎組件”擁有”。對這些資源的修改可能導致非功能性集群（non-functional cluster）。一個例子是`system:node` ClusterRole對象。這個角色定義了kubelets的權限。如果這個角色被修改，可能會導致kubelets無法正常工作。所有默認的ClusterRole和ClusterRoleBinding對象都會被標記為`kubernetes.io/bootstrapping=rbac-defaults`。 ### 自動更新每次啟動時，API Server都會更新默認ClusterRole所缺乏的各種權限，并更新默認ClusterRoleBinding所缺乏的各個角色綁定主體。這種自動更新機制允許集群修復一些意外的修改。由于權限和角色綁定主體在新的Kubernetes釋出版本中可能變化，這也能夠保證角色和角色綁定始終保持是最新的。如果需要禁用自動更新，請將默認ClusterRole以及ClusterRoleBinding的`rbac.authorization.kubernetes.io/autoupdate` 設置成為`false`。請注意，缺乏默認權限和角色綁定主體可能會導致非功能性集群問題。自Kubernetes 1.6+起，當集群RBAC授權器（RBAC Authorizer）處于開啟狀態時，可以啟用自動更新功能. ### 發現類角色 | 默認ClusterRole | 默認ClusterRoleBinding | 描述 | | --------------------- | ---------------------------------------- | ---------------------------------------- | | **system:basic-user** | **system:authenticated** and **system:unauthenticated**groups | 允許用戶只讀訪問有關自己的基本信息。 | | **system:discovery** | **system:authenticated** and **system:unauthenticated**groups | 允許只讀訪問API discovery endpoints, 用于在API級別進行發現和協商。 | ### 面向用戶的角色一些默認角色并不包含`system:`前綴，它們是面向用戶的角色。這些角色包含超級用戶角色（`cluster-admin`），即旨在利用ClusterRoleBinding（`cluster-status`）在集群范圍內授權的角色，以及那些使用RoleBinding（`admin`、`edit`和`view`）在特定命名空間中授權的角色。 | 默認ClusterRole | 默認ClusterRoleBinding | 描述 | | ----------------- | ------------------------ | ---------------------------------------- | | **cluster-admin** | **system:masters** group | 超級用戶權限，允許對任何資源執行任何操作。在**ClusterRoleBinding**中使用時，可以完全控制集群和所有命名空間中的所有資源。在**RoleBinding**中使用時，可以完全控制RoleBinding所在命名空間中的所有資源，包括命名空間自己。 | | **admin** | None | 管理員權限，利用**RoleBinding**在某一命名空間內部授予。在**RoleBinding**中使用時，允許針對命名空間內大部分資源的讀寫訪問，包括在命名空間內創建角色與角色綁定的能力。但不允許對資源配額（resource quota）或者命名空間本身的寫訪問。 | | **edit** | None | 允許對某一個命名空間內大部分對象的讀寫訪問，但不允許查看或者修改角色或者角色綁定。 | | **view** | None | 允許對某一個命名空間內大部分對象的只讀訪問。不允許查看角色或者角色綁定。由于可擴散性等原因，不允許查看secret資源。 | ### Core Component Roles ### 核心組件角色 | 默認ClusterRole | 默認ClusterRoleBinding | 描述 | | ---------------------------------- | ---------------------------------------- | ---------------------------------------- | | **system:kube-scheduler** | **system:kube-scheduler** user | 允許訪問kube-scheduler組件所需要的資源。 | | **system:kube-controller-manager** | **system:kube-controller-manager** user | 允許訪問kube-controller-manager組件所需要的資源。單個控制循環所需要的權限請參閱[控制器（controller）角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#controller-roles). | | **system:node** | **system:nodes** group (deprecated in 1.7) | 允許對kubelet組件所需要的資源的訪問，**包括讀取所有secret和對所有pod的寫訪問**。自Kubernetes 1.7開始, 相比較于這個角色，更推薦使用[Node authorizer](https://kubernetes.io/docs/admin/authorization/node/) 以及[NodeRestriction admission plugin](https://kubernetes.io/docs/admin/admission-controllers#NodeRestriction)，并允許根據調度運行在節點上的pod授予kubelets API訪問的權限。自Kubernetes 1.7開始，當啟用`Node`授權模式時，對`system:nodes`用戶組的綁定將不會被自動創建。 | | **system:node-proxier** | **system:kube-proxy** user | 允許對kube-proxy組件所需要資源的訪問。 | ### 其它組件角色 | 默認ClusterRole | 默認ClusterRoleBinding | 描述 | | ---------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | | **system:auth-delegator** | None | 允許委托認證和授權檢查。通常由附加API Server用于統一認證和授權。 | | **system:heapster** | None | [Heapster](https://github.com/kubernetes/heapster)組件的角色。 | | **system:kube-aggregator** | None | [kube-aggregator](https://github.com/kubernetes/kube-aggregator)組件的角色。 | | **system:kube-dns** | **kube-dns** service account in the **kube-system**namespace | [kube-dns](https://k8smeetup.github.io/docs/admin/dns/)組件的角色。 | | **system:node-bootstrapper** | None | 允許對執行[Kubelet TLS引導（Kubelet TLS bootstrapping）](https://k8smeetup.github.io/docs/admin/kubelet-tls-bootstrapping/)所需要資源的訪問. | | **system:node-problem-detector** | None | [node-problem-detector](https://github.com/kubernetes/node-problem-detector)組件的角色。 | | **system:persistent-volume-provisioner** | None | 允許對大部分動態存儲卷創建組件（dynamic volume provisioner）所需要資源的訪問。 | ### 控制器（Controller）角色 [Kubernetes controller manager](https://k8smeetup.github.io/docs/admin/kube-controller-manager/)負責運行核心控制循環。當使用`--use-service-account-credentials`選項運行controller manager時，每個控制循環都將使用單獨的服務賬戶啟動。而每個控制循環都存在對應的角色，前綴名為`system:controller:`。如果不使用`--use-service-account-credentials`選項時，controller manager將會使用自己的憑證運行所有控制循環，而這些憑證必須被授予相關的角色。這些角色包括： - system:controller:attachdetach-controller - system:controller:certificate-controller - system:controller:cronjob-controller - system:controller:daemon-set-controller - system:controller:deployment-controller - system:controller:disruption-controller - system:controller:endpoint-controller - system:controller:generic-garbage-collector - system:controller:horizontal-pod-autoscaler - system:controller:job-controller - system:controller:namespace-controller - system:controller:node-controller - system:controller:persistent-volume-binder - system:controller:pod-garbage-collector - system:controller:replicaset-controller - system:controller:replication-controller - system:controller:resourcequota-controller - system:controller:route-controller - system:controller:service-account-controller - system:controller:service-controller - system:controller:statefulset-controller - system:controller:ttl-controller ## 初始化與預防權限升級 RBAC API會阻止用戶通過編輯角色或者角色綁定來升級權限。由于這一點是在API級別實現的，所以在RBAC授權器（RBAC authorizer）未啟用的狀態下依然可以正常工作。用戶只有在擁有了角色所包含的所有權限的條件下才能創建／更新一個角色，這些操作還必須在角色所處的相同范圍內進行（對于`ClusterRole`來說是集群范圍，對于`Role`來說是在與角色相同的命名空間或者集群范圍）。例如，如果用戶”user-1”沒有權限讀取集群范圍內的secret列表，那么他也不能創建包含這種權限的`ClusterRole`。為了能夠讓用戶創建／更新角色，需要： 1. 授予用戶一個角色以允許他們根據需要創建／更新`Role`或者`ClusterRole`對象。 2. 授予用戶一個角色包含他們在`Role`或者`ClusterRole`中所能夠設置的所有權限。如果用戶嘗試創建或者修改`Role`或者`ClusterRole`以設置那些他們未被授權的權限時，這些API請求將被禁止。用戶只有在擁有所引用的角色中包含的所有權限時才可以創建／更新角色綁定（這些操作也必須在角色綁定所處的相同范圍內進行）*或者*用戶被明確授權可以在所引用的角色上執行綁定操作。例如，如果用戶”user-1”沒有權限讀取集群范圍內的secret列表，那么他將不能創建`ClusterRole`來引用那些授予了此項權限的角色。為了能夠讓用戶創建／更新角色綁定，需要： 1. 授予用戶一個角色以允許他們根據需要創建／更新`RoleBinding`或者`ClusterRoleBinding`對象。 2. 授予用戶綁定某一特定角色所需要的權限： - 隱式地，通過授予用戶所有所引用的角色中所包含的權限 - 顯式地，通過授予用戶在特定Role（或者ClusterRole）對象上執行`bind`操作的權限例如，下面例子中的ClusterRole和RoleBinding將允許用戶”user-1”授予其它用戶”user-1-namespace”命名空間內的`admin`、`edit`和`view`等角色和角色綁定。 ```yaml apiVersion: rbac.authorization.k8s.io/v1beta1 kind: ClusterRole metadata: name: role-grantor rules: - apiGroups: ["rbac.authorization.k8s.io"] resources: ["rolebindings"] verbs: ["create"] - apiGroups: ["rbac.authorization.k8s.io"] resources: ["clusterroles"] verbs: ["bind"] resourceNames: ["admin","edit","view"] --- apiVersion: rbac.authorization.k8s.io/v1beta1 kind: RoleBinding metadata: name: role-grantor-binding namespace: user-1-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: role-grantor subjects: - apiGroup: rbac.authorization.k8s.io kind: User name: user-1 ``` 當初始化第一個角色和角色綁定時，初始用戶需要能夠授予他們尚未擁有的權限。初始化初始角色和角色綁定時需要： - 使用包含`system：masters`用戶組的憑證，該用戶組通過默認綁定綁定到`cluster-admin`超級用戶角色。 - 如果您的API Server在運行時啟用了非安全端口（`--insecure-port`），您也可以通過這個沒有施行認證或者授權的端口發送角色或者角色綁定請求。 ## 一些命令行工具有兩個`kubectl`命令可以用于在命名空間內或者整個集群內授予角色。 ### `kubectl create rolebinding` 在某一特定命名空間內授予`Role`或者`ClusterRole`。示例如下： - 在名為”acme”的命名空間中將`admin` `ClusterRole`授予用戶”bob”： `kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme` - 在名為”acme”的命名空間中將`view` `ClusterRole`授予服務賬戶”myapp”： `kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme` ### `kubectl create clusterrolebinding` 在整個集群中授予`ClusterRole`，包括所有命名空間。示例如下： - 在整個集群范圍內將`cluster-admin` `ClusterRole`授予用戶”root”： `kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root` - 在整個集群范圍內將`system:node` `ClusterRole`授予用戶”kubelet”： `kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet` - 在整個集群范圍內將`view` `ClusterRole`授予命名空間”acme”內的服務賬戶”myapp”： `kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp` 請參閱CLI幫助文檔以獲得上述命令的詳細用法 ## 服務賬戶（Service Account）權限默認的RBAC策略將授予控制平面組件（control-plane component）、節點（node）和控制器（controller）一組范圍受限的權限，但對于”kube-system”命名空間以外的服務賬戶，則*不授予任何權限*（超出授予所有認證用戶的發現權限）。這一點允許您根據需要向特定服務賬號授予特定權限。細粒度的角色綁定將提供更好的安全性，但需要更多精力管理。更粗粒度的授權可能授予服務賬號不需要的API訪問權限（甚至導致潛在授權擴散），但更易于管理。從最安全到最不安全可以排序以下方法： 1. 對某一特定應用程序的服務賬戶授予角色（最佳實踐）要求應用程序在其pod規范（pod spec）中指定`serviceAccountName`字段，并且要創建相應服務賬戶（例如通過API、應用程序清單或者命令`kubectl create serviceaccount`等）。例如，在”my-namespace”命名空間中授予服務賬戶”my-sa”只讀權限： ```bash kubectl create rolebinding my-sa-view \ --clusterrole=view \ --serviceaccount=my-namespace:my-sa \ --namespace=my-namespace ``` 2. 在某一命名空間中授予”default”服務賬號一個角色如果一個應用程序沒有在其pod規范中指定`serviceAccountName`，它將默認使用”default”服務賬號。注意：授予”default”服務賬號的權限將可用于命名空間內任何沒有指定`serviceAccountName`的pod。下面的例子將在”my-namespace”命名空間內授予”default”服務賬號只讀權限： ```bash kubectl create rolebinding default-view \ --clusterrole=view \ --serviceaccount=my-namespace:default \ --namespace=my-namespace ``` 目前，許多[加載項（addon）](https://kubernetes.io/docs/concepts/cluster-administration/addons/)作為”kube-system”命名空間中的”default”服務帳戶運行。要允許這些加載項使用超級用戶訪問權限，請將cluster-admin權限授予”kube-system”命名空間中的”default”服務帳戶。注意：啟用上述操作意味著”kube-system”命名空間將包含允許超級用戶訪問API的秘鑰。 ```bash kubectl create clusterrolebinding add-on-cluster-admin \ --clusterrole=cluster-admin \ --serviceaccount=kube-system:default ``` 3. 為命名空間中所有的服務賬號授予角色如果您希望命名空間內的所有應用程序都擁有同一個角色，無論它們使用什么服務賬戶，您可以為該命名空間的服務賬戶用戶組授予角色。下面的例子將授予”my-namespace”命名空間中的所有服務賬戶只讀權限： ```bash kubectl create rolebinding serviceaccounts-view \ --clusterrole=view \ --group=system:serviceaccounts:my-namespace \ --namespace=my-namespace ``` 4. 對集群范圍內的所有服務賬戶授予一個受限角色（不鼓勵）如果您不想管理每個命名空間的權限，則可以將集群范圍角色授予所有服務帳戶。下面的例子將所有命名空間中的只讀權限授予集群中的所有服務賬戶： ```bash kubectl create clusterrolebinding serviceaccounts-view \ --clusterrole=view \ --group=system:serviceaccounts ``` 5. 授予超級用戶訪問權限給集群范圍內的所有服務帳戶（強烈不鼓勵）如果您根本不關心權限分塊，您可以對所有服務賬戶授予超級用戶訪問權限。警告：這種做法將允許任何具有讀取權限的用戶訪問secret或者通過創建一個容器的方式來訪問超級用戶的憑據。 ```bash kubectl create clusterrolebinding serviceaccounts-cluster-admin \ --clusterrole=cluster-admin \ --group=system:serviceaccounts ``` ## 從版本1.5升級在Kubernetes 1.6之前，許多部署使用非常寬泛的ABAC策略，包括授予對所有服務帳戶的完整API訪問權限。默認的RBAC策略將授予控制平面組件（control-plane components）、節點（nodes）和控制器（controller）一組范圍受限的權限，但對于”kube-system”命名空間以外的服務賬戶，則*不授予任何權限*（超出授予所有認證用戶的發現權限）。雖然安全性更高，但這可能會影響到期望自動接收API權限的現有工作負載。以下是管理此轉換的兩種方法： ### 并行授權器（authorizer）同時運行RBAC和ABAC授權器，并包括舊版ABAC策略： ``` --authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl ``` RBAC授權器將嘗試首先授權請求。如果RBAC授權器拒絕API請求，則ABAC授權器將被運行。這意味著RBAC策略*或者*ABAC策略所允許的任何請求都是可通過的。當以日志級別為2或更高（`--v = 2`）運行時，您可以在API Server日志中看到RBAC拒絕請求信息（以`RBAC DENY:`為前綴）。您可以使用該信息來確定哪些角色需要授予哪些用戶，用戶組或服務帳戶。一旦[授予服務帳戶角色](https://k8smeetup.github.io/docs/admin/authorization/rbac/#service-account-permissions)，并且服務器日志中沒有RBAC拒絕消息的工作負載正在運行，您可以刪除ABAC授權器。 ### 寬泛的RBAC權限您可以使用RBAC角色綁定來復制一個寬泛的策略。 **警告：以下政策略允許所有服務帳戶作為集群管理員。運行在容器中的任何應用程序都會自動接收服務帳戶憑據，并且可以對API執行任何操作，包括查看secret和修改權限。因此，并不推薦使用這種策略。** ```bash kubectl create clusterrolebinding permissive-binding \ --clusterrole=cluster-admin \ --user=admin \ --user=kubelet \ --group=system:serviceaccounts ```