原創(chuàng)譯文 轉(zhuǎn)載請標(biāo)明出處

[TOC]

簡介

基于角色的權(quán)限控制，使用 rbac.authorization.k8s.io API 組來驅(qū)動授權(quán)決策，允許管理員通過K8S API 來動態(tài)的配置安全策略

RBAC 模式在1.6版本仍然是BETA 狀態(tài)，要啟用RBAC 需要在API SERVER的啟動參數(shù)中添加

--authorization-mode=RBAC

API 概覽

此章節(jié)包含 RBAC API 聲明的四種頂層類型。用戶可以像使用其他API 資源（resource）（通過kubectl，API調(diào)用等）一樣來使用這些資源進(jìn)行交互。 比如kubectl -f (resource).yaml ，這種形式，也可以用于本章節(jié)的權(quán)限資源

角色與集群角色(role and cluster role)

在 RBAC API 中， 角色包含了一組代表權(quán)限的規(guī)則，權(quán)限聲明只有單純的允許聲明，沒有某種權(quán)限申明為拒絕訪問的申明形式。一個(gè)角色可以使用Role 類型定義到一個(gè)namespace 中?；蛘咭部梢允褂肅lusterRole 類型定義到整個(gè)急群眾

一個(gè)Role 類型的角色只能訪問其所在的namespace的資源，例如如下例子定義了一個(gè)default namespace中讀取pod 權(quán)限的角色

kind: Role

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

namespace: default

name: pod-reader

rules:

- apiGroups: [""] # "" indicates the core API group

resources: ["pods"]

verbs: ["get", "watch", "list"]

ClusterRole 類型的角色授權(quán)與Role 類型(kind)的角色相似。不過因?yàn)镃lusterRole類型是集群范圍，所以其還可以添加下列權(quán)限

• 集群范圍的資源(cluster-scope resource) 比如 nodes

• 非資源類型的 endpoints （non-resource endpoints）比如 /healthz

• 夸命名空間資源 (namespaced resource) 比如 kubectl get pod --all-namespaces

下面這個(gè)ClusterRole 可以讀取某個(gè)具體namespace的secret 也可以讀取所有明明空間的secret

kind: ClusterRole

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

# "namespace" omitted since ClusterRoles are not namespaced

name: secret-reader

rules:

- apiGroups: [""]

resources: ["secrets"]

verbs: ["get", "watch", "list"]

角色綁定與集群角色綁定（RoleBinding and ClusterRoleBinding）

角色綁定(Rolebinding)將角色（role）與用戶（user）聯(lián)系起來，角色綁定包含了一系列的子對象（users,groups,或者 service accounts）,然后將這些對象連接到一個(gè)擁有某種授權(quán)的角色(role)上，Rolebinding 綁定某個(gè)具體namespace的角色（Role）， ClusterRoleBinding，綁定 ClusterRole 類型的角色。

# This role binding allows "jane" to read pods in the "default" namespace.

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 也可以引用CulsterRole 來配置命名空間范圍內(nèi)的資源的訪問策略，這種方式允許管理員定義一些針對namespace的通用的角色（我的理解是基礎(chǔ)權(quán)限），然后重用此類型的ClusterRole 到某個(gè)具體的namespace中，而不必為每個(gè)namespace 建立獨(dú)立的Role

比如下面這個(gè)例子，雖然引用了ClusterRole，但是其仍然只能訪問Development 命名空間（RoleBinding 的namespace ）內(nèi)的資源

# This role binding allows "dave" to read secrets in the "development" namespace.

kind: RoleBinding

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

name: read-secrets

namespace: development # This only grants permissions within the "development" namespace.

subjects:

- kind: User

name: dave

apiGroup: rbac.authorization.k8s.io

roleRef:

kind: ClusterRole

name: secret-reader

apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding 用于授權(quán)集群范圍內(nèi)所有命名空間的權(quán)限。 下面的例子，允許manager 組內(nèi)的所有用戶，讀取任何namespace 中的secret

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.

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

引用資源 Referring to resource

大多數(shù)資源都是通過一個(gè)字符串來表示其自身的，比如 pods, 就先它在API URL 中的表現(xiàn)形式一樣，盡管如此，某些 API 包含了子資源，比如 pod的log 他的 API URL 如下

GET /api/v1/namespaces/{namespace}/pods/{name}/log

這種情況下，log是pod的子資源，在RBAC 授權(quán)中，要表達(dá)這種關(guān)系，用反斜杠定義資源與子資源，要允許一個(gè)對象(subject) 讀取pod 和pod 的日志，要如下書寫Role 對象

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"]

資源出了通過類型名稱(pods,secrets 等）進(jìn)行引用之外，也可以用過資源名稱（Resource name）引用某個(gè)具體的資源。同時(shí)，可以通過Verbs，限定在某個(gè)具體資源上的操作權(quán)限，例如

kind: Role

apiVersion: rbac.authorization.k8s.io/v1beta1

metadata:

namespace: default

name: configmap-updater

rules:

- apiGroups: [""]

resources: ["configmap"]

resourceNames: ["my-configmap"]

verbs: ["update", "get"]

verbs 限定了只能更新和讀取 configmap 類型中的my-configmap 實(shí)例中的內(nèi)容。

注意如果使用的resourceNames verbs 中的權(quán)限不能為 list, watch, create, deletecollection，因?yàn)橘Y源名稱不包含在create watch, create, deletecollection的API URL 中。

Role example

下面的例子只包含了rules 部分

允許在core api 組中讀取pod

rules:

- apiGroups: [""]

resources: ["pods"]

verbs: ["get", "list", "watch"]

允許在 extensions 和 apps ,API 組中讀取和寫入 deployments

rules:

- apiGroups: ["extensions", "apps"]

resources: ["deployments"]

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允許讀取 pod， 和在jobs 資源中讀取寫入

rules:

- apiGroups: [""]

resources: ["pods"]

verbs: ["get", "list", "watch"]

- apiGroups: ["batch", "extensions"]

resources: ["jobs"]

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允許讀取 my-config (ConfigMap 類型的資源）實(shí)例的內(nèi)容( 必須通過RoleBinding 綁定到一個(gè)具體的namespace，權(quán)限在此namespace 范圍內(nèi)生效）

rules:

- apiGroups: [""]

resources: ["configmaps"]

resourceNames: ["my-config"]

verbs: ["get"]

允許在core api group中讀取 nodes 資源 (因?yàn)閚ode 是集群范圍內(nèi)的資源，所以必須使用ClusterRole 和ClusterRoleBingding來綁定才能生效）

rules:

- apiGroups: [""]

resources: ["nodes"]

verbs: ["get", "list", "watch"]

允許對非資源的 endpoint 和其subpath 使用“get”和“post”請求（必須使用ClusterRole 和ClusterRoleBingding來綁定才能生效）

rules:

- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match

verbs: ["get", "post"]

引用對象(Reffering Subjects)

RoleBinding 和 ClusterRoleBinding 將 角色（role）綁定到對象（subject）上，對象（subject）可以是用戶（user），組（group），或者 service account

用戶可以通過字符來表示，其形式包含 一般用戶名，email 形式的用戶名，和數(shù)字id 形式的用戶名，具體形式取決于管理員的配置。在RABC 授權(quán)系統(tǒng)中，并不要求某種具體的形式，但是前綴 system: 是一個(gè)保留字，所以用戶名中不能包含此前綴。

組在K8S 中通過Authenticator modules 來提供，組(group) 和用戶（user）一樣，通過字符來表示。并且沒有限定具體的形式，不過system: 仍然不能作為組名的前綴

Service Account 的用戶名擁有 system:serviceaccount: 前綴，并且屬于擁有 system:serviceaccounts (注意末尾的S）前綴的組

RoleBinding 例子

下面的例子只包含了RoleBinding 中的 subjects 部分

引用 alice@example.com 的 subject 部分

subjects:

- kind: User

name: "alice@example.com"

apiGroup: rbac.authorization.k8s.io

引用組 frontend-admins 的 subject 部分

subjects:

- kind: Group

name: "frontend-admins"

apiGroup: rbac.authorization.k8s.io

kube-system 命名空間(namespace) 中，引用名為 default 的service account

subjects:

- kind: ServiceAccount

name: default

namespace: kube-system

引用 qa 命名空間中(namespace) 所有的service account

subjects:

- kind: Group

name: system:serviceaccounts:qa

apiGroup: rbac.authorization.k8s.io

引用所有命名空間中的所有 service account

subjects:

- kind: Group

name: system:serviceaccounts

apiGroup: rbac.authorization.k8s.io

引用所有認(rèn)證過的用戶(user) 1.5 之后的版本適用

subjects:

- kind: Group

name: system:authenticated

apiGroup: rbac.authorization.k8s.io

引用所有未通過認(rèn)證的用戶 1.5之后的版本適用

subjects:

- kind: Group

name: system:unauthenticated

apiGroup: rbac.authorization.k8s.io

引用所有用戶

subjects:

- kind: Group

name: system:authenticated

apiGroup: rbac.authorization.k8s.io

- kind: Group

name: system:unauthenticated

apiGroup: rbac.authorization.k8s.io

默認(rèn)角色與角色綁定 （Default Roles and Role Bindings）

api server 創(chuàng)建了一系列的默認(rèn) ClusterRole 和 ClusterRoleBinding 對象， 其中許多對象以 system: 前綴開頭，代表其中綁定的資源是作為基礎(chǔ)設(shè)施適用和占有的。修改這些資源會導(dǎo)致整個(gè)集群不可用。一個(gè)例子是 system:node ClusterRole。這個(gè)角色擁有一系列的kubelet 權(quán)限，如果這個(gè)角色被修改了，可能會讓kubelet 出現(xiàn)異常。

所有默認(rèn)的集群角色 （ClusterRole） 和其角色綁定（role binding）都帶有如下標(biāo)記

kubernetes.io/bootstrapping=rbac-defaults

自動協(xié)調(diào) Auto-reconciliation

在每次啟動的時(shí)候， api server 會自動更新默認(rèn)的集群角色（default cluster roles）的信息，添加缺少的權(quán)限和對象(user , group, service account 等），這個(gè)機(jī)制可以讓集群自我修復(fù)，同時(shí)也可以讓集群在role， role binding ，subject 發(fā)生變化的時(shí)候，自動同步更新到最新狀態(tài)。

如果要退出自動協(xié)調(diào)，只需要在默認(rèn)的cluster role 或者 role binding 中設(shè)置 rbac.authorization.kubernetes.io/autoupdate 聲明 （annotation ）為 false 即可。注意，缺少默認(rèn)權(quán)限(permissions)或者對象(subjects) 會導(dǎo)致集群不可用

自動協(xié)調(diào)在 K8S 1.6+ 的版本中啟用RBAC 授權(quán)時(shí)被激活。

發(fā)現(xiàn)角色 (Discovery Roles)

面向用戶的角色 (User-facing Roles)

一些不帶 system: 前綴的默認(rèn)角色，是用來面向用戶使用的。他們包含超級用戶角色 (cluster-admin), 使用 ClusterRoleBinding 的集群范圍的角色 (cluster-status), 以及是用RoleBding 的具體某個(gè) namespace中的角色 (admin, edit, view)

核心組件角色 Core Component Roles

其他組件角色 (other Component Roles)

控制器角色 （Controller Roles）

Kubernetes控制器管理器運(yùn)行核心控制環(huán)路。當(dāng)使用 --use-service-account-credentials 參數(shù)調(diào)用時(shí)，每個(gè)控制循環(huán)都將使用單獨(dú)的服務(wù)帳戶(service account) 啟動。對于每個(gè)控制循環(huán)中的角色都以system: 前綴開頭。如果不是用 --use-service-account-credentials 參數(shù)，它將使用其自己的憑證運(yùn)行所有控制循環(huán)，這些憑證必須包含所有相關(guān)的角色的權(quán)限。這些角色包括：

• 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-controlle

防止非法提權(quán) （Privilege Escalation Prevention and Bootstrapping）

RBAC API 阻止用戶通過編輯角色(Role)或角色綁定(role binding)來升級權(quán)限。因?yàn)檫@是在API級強(qiáng)制限定的，所以即使RBAC授權(quán)模式未被使用也適用。

用戶只能創(chuàng)建自身所擁有的權(quán)限范圍內(nèi)的角色，即如果user1 沒有讀取集群范圍內(nèi)secret的權(quán)限，那么user1 就不能創(chuàng)建擁有這個(gè)權(quán)限的ClusterRole。要讓一個(gè)用戶創(chuàng)建/更新角色

1. 授予用戶一個(gè)角色，允許他們根據(jù)需要?jiǎng)?chuàng)建/更新Role或ClusterRole對象。

2. 授予用戶你希望他們在創(chuàng)建角色時(shí)，可以指定的權(quán)限。如果他們試圖創(chuàng)建擁有其自身沒有權(quán)限的角色（role）或者集群角色（cluster role），API 請求會自行阻止。

用戶只能對其角色擁有的權(quán)限創(chuàng)建 role binding（在和role binding 相同的范圍內(nèi)），或者在其被顯示授權(quán)(been given explicit permission)可以對某個(gè)角色進(jìn)行binding 時(shí)才能創(chuàng)建。例如，如果user1 沒有讀取集群范圍內(nèi)secret的權(quán)限，那么user1 就不能創(chuàng)建擁有讀取集群范圍內(nèi)secret 權(quán)限 的 role 的ClusterRoleBinding。要讓一個(gè)用戶創(chuàng)建/更新角色綁定

1. 授予他們一個(gè)角色允許根據(jù)需要?jiǎng)?chuàng)建 Rolebinding 或者ClusterRoleBinding 對象。

2. 授予他們必要的權(quán)限來綁定具體的角色（role）

2.1. 隱式地，他們用后自己相關(guān)角色的綁定權(quán)限

2.2. 顯示地，可以授予他們某個(gè)具體角色的綁定權(quán)限（自身不一定擁有目標(biāo)角色）

例如，下面這個(gè)例子允許 user1 在user-1-namespace 命名空間中授權(quán)其他用戶（user） admin edit 和view 角色

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

當(dāng)創(chuàng)建(bootstrap)第一個(gè)角色和角色綁定時(shí)，初始用戶必須授予他們尚未擁有的權(quán)限

創(chuàng)建初始角色和角色綁定

• 使用和system:masters 組中的賬戶，比如包含 cluster-admin super-user 等管理角色的賬戶

• 如果api server 沒有使用安全端口（--insecure-port),你仍然能通過安全端口使用api（沒有強(qiáng)制要求認(rèn)證與授權(quán)）。

命令行工具 Command-line Utilities

兩個(gè)kubectl 命令可以用來在命名空間范圍或集群范圍授權(quán)角色。

kubectl create rolebinding

在一個(gè)命名空間（namespace）中授權(quán)一個(gè)角色（Role）或者集群角色（ClusterRole），例子

• 在acme 命名空間中，授權(quán)用戶 bob admin 集群角色 (ClusterRole)

kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

• 在acme 命名空間中授權(quán) 名為 myapp的 service account view 集群角色

kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme

kubectl create clusterrolebinding

授權(quán)集群范圍內(nèi)的ClusterRole，包含namespace 權(quán)限。

授權(quán) root 用戶為 cluster-admin 的集群角色(ClusterRole)

kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

授權(quán)kubelet 用戶 system:node 角色

kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

授權(quán)名為 myapp 的service account， view 角色

kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myap

Service Account 權(quán)限 （Service Account Permissions）

默認(rèn)RBAC策略向控制平面(controll plane)，節(jié)點(diǎn)和控制器授予擁有范圍限制的權(quán)限，但不向“kube-system”命名空間之外的服務(wù)帳戶(service account)授予權(quán)限（超出所有已驗(yàn)證用戶的發(fā)現(xiàn)權(quán)限）

這允許您根據(jù)需要向特定服務(wù)帳戶授予特定角色。細(xì)粒度角色綁定提供更大的安全性，但需要更多的精力來管理。寬泛的授權(quán)可能給服務(wù)帳戶提供不必要的（隱性提權(quán)）API訪問權(quán)限，但是更容易管理。

從最安全到最不安全的方法是：

2. 為應(yīng)用程序特定的服務(wù)帳戶授予角色 （最佳實(shí)踐）

這要求應(yīng)用程序在其pod規(guī)范中指定serviceAccountName，并且要在之前創(chuàng)建好服務(wù)帳戶（通過API，應(yīng)用程序清單【application manifest】，kubectl 等方式創(chuàng)建）。

例如，將“my-namespace”中的只讀權(quán)限授予“my-sa”服務(wù)帳戶：

kubectl create rolebinding my-sa-view \

--clusterrole=view \

--serviceaccount=my-namespace:my-sa \

--namespace=my-namespace

2. 在命名空間中為“默認(rèn)”服務(wù)帳戶（service account）授予角色

如果應(yīng)用程序沒有指定serviceAccountName，它將使用“默認(rèn)”服務(wù)帳戶。

注意：授予“默認(rèn)”服務(wù)帳戶的權(quán)限可用于和任何命名空間內(nèi)，未指定服務(wù)賬戶(service account） 的POD。

例如，將“my-namespace”中的只讀權(quán)限授予“默認(rèn)”服務(wù)帳戶：

shell kubectl create rolebinding default-view \ --          clusterrole=view \ --serviceaccount=my-namespace:default    \ --namespace=my-namespace

許多插件(add-on)使用“kube-system”命名空間中的“默認(rèn)”服務(wù)帳戶運(yùn)行。要允許這些加載項(xiàng)使用超級用戶訪問權(quán)限，請將cluster-admin權(quán)限授予“kube-system”命名空間中的“默認(rèn)”服務(wù)帳戶

注意：如果在kube-system命名空間內(nèi)授予默認(rèn)服務(wù)賬戶cluster-admin 權(quán)限，這意味著kube-system 擁有了super user的特權(quán)

kubectl create clusterrolebinding add-on-cluster-admin \

--clusterrole=cluster-admin \

--serviceaccount=kube-system:default

3. 為命名空間中的所有服務(wù)帳戶授予角色

如果希望命名空間中的所有應(yīng)用程序都具有角色，無論使用什么服務(wù)帳戶，您可以將角色授予該名稱空間的服務(wù)帳戶組。

例如，將“my-namespace”中的只讀權(quán)限授予該命名空間中的所有服務(wù)帳戶

kubectl create rolebinding serviceaccounts-view \

--clusterrole=view \

--group=system:serviceaccounts:my-namespace \

--namespace=my-namespace

4. 對集群范圍內(nèi)的所有服務(wù)帳戶（不鼓勵(lì)）授予權(quán)限（role）

如果您不想為每個(gè)命名空間管理權(quán)限，可以將群集范圍的角色(ClusterRole)授予所有服務(wù)帳戶。

例如，將所有命名空間中的只讀權(quán)限授予群集中的所有服務(wù)帳戶：

kubectl create clusterrolebinding serviceaccounts-view \

--clusterrole=view \

--group=system:serviceaccounts

5. 將超級用戶權(quán)限授予集群內(nèi)的所有服務(wù)帳戶（強(qiáng)烈反對）

如果您根本不關(guān)心權(quán)限問題，可以向所有服務(wù)帳戶授予超級用戶權(quán)限。

警告：這允許任何具有讀取權(quán)限的用戶訪問 secret或創(chuàng)建一個(gè)pod以訪問超級用戶憑據(jù)。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \

--clusterrole=cluster-admin \

--group=system:serviceaccounts

從1.5升級 (Upgrading from 1.5)

在Kubernetes 1.6之前，許多部署(deployment)使用非常寬泛的ABAC策略，包括授予所有服務(wù)帳戶完全的API訪問權(quán)限。

默認(rèn)RBAC策略向控制平面組件(controll plane component)，節(jié)點(diǎn)(node)和控制器(controller)授予d帶范圍限制的權(quán)限，但不向“kube-system”命名空間之外的服務(wù)帳戶授予權(quán)限（超出已驗(yàn)證用戶的發(fā)現(xiàn)權(quán)限）。

雖然安全性更高，但這可能會影響到期望自動接收API權(quán)限的現(xiàn)有工作負(fù)載。以下是做此轉(zhuǎn)換的兩種方法

并行授權(quán)者

同時(shí)運(yùn)行RBAC和ABAC授權(quán)器，并包括舊版ABAC策略：

--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json

RBAC授權(quán)者將嘗試首先授權(quán)請求。如果它拒絕API請求，則ABAC授權(quán)器接過請求的授權(quán)任務(wù)。這意味著RBAC或ABAC其中之一允許請求即可。

當(dāng)日志級別為2或更高（-v = 2）運(yùn)行時(shí)，您可以在apiserver日志中看到RBAC的拒絕日志（以RBAC DENY : 為前綴）。您可以使用該信息來確定哪些角色需要授予哪些用戶(user)，組(group)或服務(wù)帳戶(service account)。一旦向服務(wù)帳戶授予角色，并且在服務(wù)器日志中沒有RBAC拒絕消息的工作負(fù)載正在運(yùn)行，則可以刪除ABAC授權(quán)器

靈活的RBAC權(quán)限（Permissive RBAC Permissions）

您可以使用RBAC角色綁定來復(fù)制一個(gè)允許的策略。

警告：以下策略允許所有服務(wù)帳戶充當(dāng)集群管理員。運(yùn)行在容器中的任何應(yīng)用程序都會自動接收服務(wù)帳戶憑據(jù)，并且可以針對API執(zhí)行任何操作，包括查看secret和修改權(quán)限。這是不推薦的策略。

kubectl create clusterrolebinding permissive-binding \

--clusterrole=cluster-admin \

--user=admin \

--user=kubelet \

--group=system:serviceaccounts

英文連接:https://kubernetes.io/docs/admin/authorization/rbac/#referring-to-subjects