kubernetes RBAC【1】相遇--介紹、正常用法、叢集預設

文章目錄

1. 簡介
2. API 對象

2.1 角色（Role）
2.2 叢集角色（ClusterRole）
2.3 角色綁定（RoleBinding）和叢集角色綁定（ClusterRoleBinding）

3. 對資源的引用
4. 聚合的 ClusterRole
5. Role 示例
6. 對主體的引用
7. RoleBinding 示例
8. 預設 Roles 和 Role Bindings
9. 面向使用者的角色
10. 核心元件角色
11. 其他元件角色
12. 内置控制器的角色
13. 對角色綁定建立或更新的限制
14. 指令行工具

14.1 kubectl create role
14.2 kubectl create clusterrole
14.3 kubectl create rolebinding
14.4 kubectl create clusterrolebinding
14.5 kubectl auth reconcile

15. 服務賬号權限
16. 寬松的 RBAC 權限
17. 示例

容器網絡接口（CNI）weavework

1. 簡介

RBAC（Role-Based Access Control，基于角色的通路控制）在Kubernetes的

1.5

版本中引入，在

1.6

版本時更新為

Beta

版本，在1.8版本時更新為

GA

。作為kubeadm安裝方式的預設選項，足見其重要程度。相對于其他通路控制方式，新的RBAC具有如下優勢。

◎ 對叢集中的資源和非資源權限均有完整的覆寫。
◎ 整個RBAC完全由幾個API對象完成，同其他API對象一樣，可以用kubectl或API進行操作。
◎ 可以在運作時進行調整，無須重新啟動API Server。要使用RBAC授權模式，需要在API Server的啟動參數中加上 --authorization-mode=RBAC 。

=Example,RBAC --<其他選項> --<其他選項>

下面對RBAC的原理和用法進行說明。

2. API 對象

RBAC API 聲明了四種 Kubernetes 對象：

Role

、

ClusterRole

、

RoleBinding

和

ClusterRoleBinding

。你可以像使用其他 Kubernetes 對象一樣，通過類似 kubectl 這類工具描述對象, 或修補對象。

2.1 角色（Role）

一個角色就是一組權限的集合，這裡的權限都是許可形式的，不存在拒絕的規則。在一個命名空間中，可以用角色來定義一個角色，如果是叢集級别的，就需要使用ClusterRole了。角色隻能對命名空間内的資源進行授權，在下面例子中定義的角色具備讀取Pod的權限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 組
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

rules中的參數說明如下。

◎

apiGroups

：支援的API組清單，例如“

apiVersion:batch/v1

”“

apiVersion: extensions:v1beta1

”“

apiVersion: apps/v1beta1

”等，

詳細的API組說明參見第9章的說明。

◎

resources

：支援的資源對象清單，例如pods、deployments、

jobs等。

◎

verbs

：對資源對象的操作方法清單，例如get、watch、list、delete、replace、patch等，詳細的操作方法說明參見第9章的說明。

2.2 叢集角色（ClusterRole）

叢集角色除了具有和角色一緻的命名空間内資源的管理能力，因其叢集級别的範圍，還可以用于以下特殊元素的授權。

◎ 叢集範圍的資源，例如Node。

◎ 非資源型的路徑，例如“/healthz”。

◎ 包含全部命名空間的資源，例如pods（用于kubectl get pods –

all-namespaces這樣的操作授權）。

下面的叢集角色可以讓使用者有權通路任意一個或所有命名空間的secrets（視其綁定方式而定）：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，因為 ClusterRoles 不受名字空間限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 層面，用來通路 Secret 對象的資源的名稱為 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

2.3 角色綁定（RoleBinding）和叢集角色綁定（ClusterRoleBinding）

角色綁定或叢集角色綁定用來把一個角色綁定到一個目标上，綁定目标可以是

User

（使用者）、

Group

（組）或者

Service Account

。使用

RoleBinding

為某個命名空間授權，使用

ClusterRoleBinding

為叢集範圍内授權。

RoleBinding可以引用Role進行授權。下面的例子中的RoleBinding将在default命名空間中把pod-reader角色授予使用者jane，這一操作可以讓jane讀取default命名空間中的Pod：

apiVersion: rbac.authorization.k8s.io/v1
# 此角色綁定允許 "jane" 讀取 "default" 名字空間中的 Pods
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你可以指定不止一個“subject（主體）”
- kind: User
  name: jane # "name" 是不區分大小寫的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" 指定與某 Role 或 ClusterRole 的綁定關系
  kind: Role # 此字段必須是 Role 或 ClusterRole
  name: pod-reader     # 此字段必須與你要綁定的 Role 或 ClusterRole 的名稱比對

RoleBinding

也可以引用

ClusterRole

，對屬于同一命名空間内ClusterRole定義的資源主體進行授權。一種常見的做法是叢集管理者為叢集範圍預先定義好一組ClusterRole，然後在多個命名空間中重複使用這些ClusterRole。例如，在下面的例子中，雖然

secret-reader

是一個叢集角色，但是因為使用了RoleBinding，是以dave隻能讀取development命名空間中的secret：

apiVersion: rbac.authorization.k8s.io/v1
# 此角色綁定使得使用者 "dave" 能夠讀取 "default" 名字空間中的 Secrets
# 你需要一個名為 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名字空間決定了通路權限的授予範圍。
  # 這裡僅授權在 "development" 名字空間内的通路權限。
  namespace: development
subjects:
- kind: User
  name: dave # 'name' 是不區分大小寫的

叢集角色綁定中的角色隻能是叢集角色，用于進行叢集級别或者對所有命名空間都生效的授權。下面的例子允許manager組的使用者讀取任意Namespace中的secret：

apiVersion: rbac.authorization.k8s.io/v1
# 此叢集角色綁定允許 “manager” 組中的任何人通路任何名字空間中的 secrets
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # 'name' 是不區分大小寫的

建立了綁定之後，你不能再修改綁定對象所引用的 Role 或 ClusterRole。試圖改變綁定對象的 roleRef 将導緻合法性檢查錯誤。如果你想要改變現有綁定對象中 roleRef 字段的内容，必須删除重新建立綁定對象。

這種限制有兩個主要原因：

針對不同角色的綁定是完全不一樣的綁定。要求通過删除/重建綁定來更改 roleRef,

這樣可以確定要賦予綁定的所有主體會被授予新的角色（而不是在允許修改 roleRef的情況下導緻所有現有主體胃鏡驗證即被授予新角色對應的權限）。
将 roleRef 設定為不可以改變，這使得可以為使用者授予對現有綁定對象的 update 權限，這樣可以讓他們管理主體清單，同時不能更改被授予這些主體的角色。

指令

kubectl auth reconcile

可以建立或者更新包含 RBAC 對象的清單檔案，并且在必要的情況下删除和重新建立綁定對象，以改變所引用的角色。更多相關資訊請參照指令用法和示例

3. 對資源的引用

多數資源可以用其名稱的字元串來表達，也就是Endpoint中的URL相對路徑，例如pods。然而，某些Kubernetes API包含下級資源，例如Pod的日志（logs）。Pod日志的Endpoint是

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

。

在這個例子中，Pod是一個命名空間内的資源，log就是一個下級資源。要在一個RBAC角色中展現，就需要用斜線“/”來分隔資源和下級資源。若想授權讓某個主體同時能夠讀取Pod和Pod log，則可以配置resources為一個數組：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

對于某些請求，也可以通過 resourceNames 清單按名稱引用資源。在指定時，可以将請求限定為資源的單個執行個體。下面的例子中限制可以 “get” 和 “update” 一個名為 my-configmap 的 ConfigMap：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  # 在 HTTP 層面，用來通路 ConfigMap 的資源的名稱為 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

可想而知，resourceName這種用法對list、watch、create或deletecollection操作是無效的，這是因為必須要通過URL進行鑒權，而資源名稱在list、watch、create deletecollection請求中隻是請求Body資料的一部分。

4. 聚合的 ClusterRole

你可以将若幹 ClusterRole 聚合（Aggregate）起來，形成一個複合的 ClusterRole。某個控制器作為叢集控制面的一部分會監視帶有 aggregationRule 的 ClusterRole 對象集合。

aggregationRule

為控制器定義一個标簽選擇算符供後者比對應該組合到目前 ClusterRole 的 roles 字段中的 ClusterRole 對象。

下面是一個聚合 ClusterRole 的示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自動填充這裡的規則

如果你建立一個與某現有聚合 ClusterRole 的标簽選擇算符比對的 ClusterRole，這一變化會觸發新的規則被添加到聚合 ClusterRole 的操作。下面的例子中，通過建立一個标簽同樣為

rbac.example.com/aggregate-to-monitoring: true

的 ClusterRole，新的規則可被添加到 “monitoring” ClusterRole 中。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# 當你建立 "monitoring-endpoints" ClusterRole 時，
# 下面的規則會被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
  resources: ["services", "endpoints", "pods"]
  verbs: ["get", "list", "watch"]

預設的面向使用者的角色使用 ClusterRole 聚合。這使得作為叢集管理者的你可以為擴充預設規則，包括為定制資源設定規則，比如通過

CustomResourceDefinitions

或聚合 API 伺服器提供的定制資源。

例如，下面的 ClusterRoles 讓預設角色 “admin” 和 “edit” 擁有管理自定義資源 “CronTabs” 的權限， “view” 角色對 CronTab 資源擁有讀操作權限。你可以假定 CronTab 對象在 API 伺服器所看到的 URL 中被命名為 “crontabs”。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregate-cron-tabs-edit
  labels:
    # 添加以下權限到預設角色 "admin" 和 "edit" 中
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: aggregate-cron-tabs-view
  labels:
    # 添加以下權限到 "view" 預設角色中
    rbac.authorization.k8s.io/aggregate-to-view: "true"
rules:
- apiGroups: ["stable.example.com"]
  resources: ["crontabs"]
  verbs: ["get", "list", "watch"]

5. Role 示例

以下示例均為從 Role 或 CLusterRole 對象中截取出來，我們僅展示其 rules 部分。

允許讀取在核心 API 組下的 “Pods”：

rules:
- apiGroups: [""]
  # 在 HTTP 層面，用來通路 Pod 的資源的名稱為 "pods"
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

允許讀/寫在 “extensions” 和 “apps” API 組中的 Deployment（在 HTTP 層面，對應 URL 中資源部分為 “deployments”）：

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

允許讀取核心 API 組中的 “pods” 和讀/寫 “batch” 或 “extensions” API 組中的 “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（需要通過 RoleBinding 綁定以限制為某名字空間中特定的 ConfigMap）：

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

允許讀取在核心組中的 “nodes” 資源（因為 Node 是叢集作用域的，是以需要 ClusterRole 綁定到 ClusterRoleBinding 才生效）：

rules:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

允許針對非資源端點

/healthz

和其子路徑上發起 GET 和 POST 請求（必須在 ClusterRole 綁定 ClusterRoleBinding 才生效）：

rules:
  - nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一個全局通配符
    verbs: ["get", "post"]

6. 對主體的引用

RoleBinding

或者

ClusterRoleBinding

可綁定角色到某 *主體（Subject）*上。主體可以是組，使用者或者服務賬号。

Kubernetes 用字元串來表示使用者名。使用者名可以是普通的使用者名，像 “alice”；或者是郵件風格的名稱，如 “[email protected]”，或者是以字元串形式表達的數字 ID。你作為 Kubernetes 管理者負責配置身份認證子產品以便後者能夠生成你所期望的格式的使用者名。

注意：字首 system: 是 Kubernetes 系統保留的，是以你要確定所配置的使用者名或者組名不能出現上述 system: 字首。

除了對字首的限制之外，RBAC 鑒權系統不對使用者名格式作任何要求。

7. RoleBinding 示例

下面示例是 RoleBinding 中的片段，僅展示其 subjects 的部分。

對于名稱為 [email protected] 的使用者：

subjects:
- kind: User
  name: "[email protected]"

對于名稱為 frontend-admins 的使用者組：

subjects:
- kind: Group
  name: "frontend-admins"

對于 kube-system 名字空間中的預設服務賬号：

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

對于 “qa” 名字空間中所有的服務賬号：

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroup: rbac.authorization.k8s.io

對于在任何名字空間中的服務賬号：

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

對于所有已經過認證的使用者：

subjects:
- kind: Group
  name: system:authenticated
  apiGroup: rbac.authorization.k8s.io

對于所有未通過認證的使用者：

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

8. 預設 Roles 和 Role Bindings

API 伺服器建立一組預設的 ClusterRole 和 ClusterRoleBinding 對象。這其中許多是以

system:

為字首的，用以辨別對應資源是直接由叢集控制面管理的。所有的預設 ClusterRole 和 ClusterRoleBinding 都有

kubernetes.io/bootstrapping=rbac-defaults

标簽。

注意：在修改名稱包含 system: 字首的 ClusterRole 和 ClusterRoleBinding 時要格外小心。

對這些資源的更改可能導緻叢集無法繼續工作。

預設 ClusterRole	預設 ClusterRoleBinding	描述
system:basic-user	system:authenticated 組	允許使用者以隻讀的方式去通路他們自己的基本資訊。在 1.14 版本之前，這個角色在預設情況下也綁定在 system:unauthenticated 上。
system:discovery	system:authenticated 組	允許以隻讀方式通路 API 發現端點，這些端點用來發現和協商 API 級别。在 1.14 版本之前，這個角色在預設情況下綁定在 system:unauthenticated 上。
system:public-info-viewer	system:authenticated 和 system:unauthenticated 組	允許對叢集的非敏感資訊進行隻讀通路，它是在 1.14 版本中引入的。

9. 面向使用者的角色

一些預設的 ClusterRole 不是以字首 system: 開頭的。這些是面向使用者的角色。它們包括超級使用者（

Super-User

）角色（

cluster-admin

）、使用 ClusterRoleBinding 在叢集範圍内完成授權的角色（

cluster-status

）、以及使用 RoleBinding 在特定名字空間中授予的角色（admin、edit、view）。

面向使用者的 ClusterRole 使用 ClusterRole 聚合以允許管理者在這些 ClusterRole 上添加用于定制資源的規則。如果想要添加規則到 admin、edit 或者 view，可以建立帶有以下一個或多個标簽的 ClusterRole：

metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"

10. 核心元件角色

預設 ClusterRole	預設 ClusterRoleBinding	描述
cluster-admin	system:masters 組	允許超級使用者在平台上的任何資源上執行所有操作。當在 ClusterRoleBinding 中使用時，可以授權對叢集中以及所有名字空間中的全部資源進行完全控制。當在 RoleBinding 中使用時，可以授權控制 RoleBinding 所在名字空間中的所有資源，包括名字空間本身。
admin	無	允許管理者通路權限，旨在使用 RoleBinding 在名字空間内執行授權。如果在 RoleBinding 中使用，則可授予對名字空間中的大多數資源的讀/寫權限，包括建立角色和角色綁定的能力。但是它不允許對資源配額或者名字空間本身進行寫操作。
edit	無	允許對名字空間的大多數對象進行讀/寫操作。它不允許檢視或者修改角色或者角色綁定。不過，此角色可以通路 Secret，以名字空間中任何 ServiceAccount 的身份運作 Pods，是以可以用來了解名字空間内所有服務賬号的 API 通路級别。
view	無
system:kube-scheduler	system:kube-scheduler user	允許通路 scheduler 元件所需要的資源。
system:volume-scheduler	system:kube-scheduler user	允許通路 kube-scheduler 元件所需要的卷資源。
system:kube-controller-manager	system:kube-controller-manager user	允許通路控制器管理器元件所需要的資源。各個控制回路所需要的權限在控制器角色詳述。
system:node	無	允許通路 kubelet 所需要的資源，包括對所有 Secret 的讀操作和對所有 Pod 狀态對象的寫操作。
你應該使用 Node 鑒權元件和 NodeRestriction 準入插件而不是 system:node 角色。同時基于 kubelet 上排程執行的 Pod 來授權 kubelet 對 API 的通路。 system:node 角色的意義僅是為了與從 v1.8 之前版本更新而來的叢集相容。
system:node-proxier	system:kube-proxy user	允許通路 kube-proxy 元件所需要的資源

11. 其他元件角色

預設 ClusterRole	預設 ClusterRoleBinding	描述
system:auth-delegator	無	允許将身份認證和鑒權檢查操作外包出去。這種角色通常用在插件式 API 伺服器上，以實作統一的身份認證和鑒權。
system:heapster	無	為 Heapster 元件（已棄用）定義的角色。
system:kube-aggregator	無	為 kube-aggregator 元件定義的角色。
system:kube-dns	在 kube-system 名字空間中的 kube-dns 服務賬号	為 kube-dns 元件定義的角色。
system:kubelet-api-admin	無	允許 kubelet API 的完全通路權限。
system:node-bootstrapper	無	允許通路執行 kubelet TLS 啟動引導所需要的資源。
system:node-problem-detector	無	為 node-problem-detector 元件定義的角色。
system:persistent-volume-provisioner	無	允許通路大部分動态卷驅動所需要的資源

12. 内置控制器的角色

Kubernetes 控制器管理器運作内建于 Kubernetes 控制面的控制器。當使用 --use-service-account-credentials 參數啟動時, kube-controller-manager 使用單獨的服務賬号來啟動每個控制器。每個内置控制器都有相應的、字首為 system:controller: 的角色。如果控制管理器啟動時未設定 --use-service-account-credentials，它使用自己的身份憑據來運作所有的控制器，該身份必須被授予所有相關的角色。這些角色包括:

system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:clusterrole-aggregation-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:expand-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:pv-protection-controller
system:controller:pvc-protection-controller
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:resourcequota-controller
system:controller:root-ca-cert-publisher
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller

13. 對角色綁定建立或更新的限制

例如，下面的 ClusterRole 和 RoleBinding 将允許使用者 user-1 把名字空間 user-1-namespace 中的 admin、edit 和 view 角色賦予其他使用者：

apiVersion: rbac.authorization.k8s.io/v1
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 意味着允許綁定任何 ClusterRole
  resourceNames: ["admin","edit","view"]

當啟動引導第一個角色和角色綁定時，需要為初始使用者授予他們尚未擁有的權限。對初始角色和角色綁定進行初始化時需要：

使用使用者組為 system:masters 的憑據，該使用者組由預設綁定關聯到 cluster-admin 這個超級使用者角色。

如果你的 API 伺服器啟動時啟用了不安全端口（使用 --insecure-port）, 你也可以通過該端口調用 API ，這樣的操作會繞過身份驗證或鑒權

14. 指令行工具

14.1 kubectl create role

建立 Role 對象，定義在某一名字空間中的權限。例如:

建立名稱為 “pod-reader” 的 Role 對象，允許使用者對 Pods 執行 get、watch 和 list 操作：

kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods

建立名稱為 “pod-reader” 的 Role 對象并指定 resourceNames：

kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

建立名為 “foo” 的 Role 對象并指定 apiGroups：

kubectl create role foo --verb=get,list,watch --resource=replicasets.apps

建立名為 “foo” 的 Role 對象并指定子資源權限:

kubectl create role foo --verb=get,list,watch --resource=pods,pods/status

建立名為 “my-component-lease-holder” 的 Role 對象，使其具有對特定名稱的資源執行 get/update 的權限：

kubectl create role my-component-lease-holder --verb=get,list,watch,update --resource=lease --resource-name=my-component

14.2 kubectl create clusterrole

建立 ClusterRole 對象。例如：

建立名稱為 “pod-reader” 的 ClusterRole對象，允許使用者對 Pods 對象執行 get、watch和list` 操作：

kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods

建立名為 “pod-reader” 的 ClusterRole 對象并指定 resourceNames：

kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod

建立名為 “foo” 的 ClusterRole 對象并指定 apiGroups：

kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps

建立名為 “foo” 的 ClusterRole 對象并指定子資源:

kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status

建立名為 “foo” 的 ClusterRole 對象并指定 nonResourceURL：

kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*

建立名為 “monitoring” 的 ClusterRole 對象并指定 aggregationRule：

kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true"

14.3 kubectl create rolebinding

在特定的名字空間中對 Role 或 ClusterRole 授權。例如：

在名字空間 “acme” 中，将名為 admin 的 ClusterRole 中的權限授予名稱 “bob” 的使用者:

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

在名字空間 “acme” 中，将名為 view 的 ClusterRole 中的權限授予名字空間 “acme” 中名為 myapp 的服務賬号：

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

在名字空間 “acme” 中，将名為 view 的 ClusterRole 對象中的權限授予名字空間 “myappnamespace” 中名稱為 myapp 的服務賬号：

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

14.4 kubectl create clusterrolebinding

在整個叢集（所有名字空間）中用 ClusterRole 授權。例如：

在整個叢集範圍，将名為 cluster-admin 的 ClusterRole 中定義的權限授予名為 “root” 使用者：

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

在整個叢集範圍内，将名為 system:node-proxier 的 ClusterRole 的權限授予名為 “system:kube-proxy” 的使用者：

kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy

在整個叢集範圍内，将名為 view 的 ClusterRole 中定義的權限授予 “acme” 名字空間中名為 “myapp” 的服務賬号：

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

14.5 kubectl auth reconcile

使用清單檔案來建立或者更新 rbac.authorization.k8s.io/v1 API 對象。

尚不存在的對象會被建立，如果對應的名字空間也不存在，必要的話也會被建立。已經存在的角色會被更新，使之包含輸入對象中所給的權限。如果指定了 --remove-extra-permissions，可以删除額外的權限。

已經存在的綁定也會被更新，使之包含輸入對象中所給的主體。如果指定了 --remove-extra-permissions，則可以删除多餘的主體。

例如:

測試應用 RBAC 對象的清單檔案，顯示将要進行的更改：

kubectl auth reconcile -f my-rbac-rules.yaml --dry-run

應用 RBAC 對象的清單檔案，保留角色中的額外權限和綁定中的其他主體：

kubectl auth reconcile -f my-rbac-rules.yaml

應用 RBAC 對象的清單檔案, 删除角色中的額外權限和綁定中的其他主體：

kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions

15. 服務賬号權限

為特定應用的服務賬戶授予角色（最佳實踐）

這要求應用在其 Pod 規約中指定 serviceAccountName，并額外建立服務賬号（包括通過 API、應用程式清單、kubectl create serviceaccount 等）。

例如，在名字空間 “my-namespace” 中授予服務賬号 “my-sa” 隻讀權限：

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

将角色授予某名字空間中的 “default” 服務賬号

如果某應用沒有指定 serviceAccountName，那麼它将使用 “default” 服務賬号。

說明： “default” 服務賬号所具有的權限會被授予給名字空間中所有未指定 serviceAccountName 的 Pod。

例如，在名字空間 “my-namespace” 中授予服務賬号 “default” 隻讀權限：

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

許多插件元件在 kube-system 名字空間以 “default” 服務賬号運作。要允許這些插件元件以超級使用者權限運作，需要将叢集的 cluster-admin 權限授予 kube-system 名字空間中的 “default” 服務賬号。

說明：啟用這一配置意味着在 kube-system 名字空間中包含以超級使用者賬号來通路 API 的 Secrets。

kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

将角色授予名字空間中所有服務賬号

如果你想要名字空間中所有應用都具有某角色，無論它們使用的什麼服務賬号，可以将角色授予該名字空間的服務賬号組。

例如，在名字空間 “my-namespace” 中的隻讀權限授予該名字空間中的所有服務賬号：

kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

在叢集範圍内為所有服務賬戶授予一個受限角色（不鼓勵）

如果你不想管理每一個名字空間的權限，你可以向所有的服務賬号授予叢集範圍的角色。

例如，為叢集範圍的所有服務賬号授予跨所有名字空間的隻讀權限：

kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts

授予超級使用者通路權限給叢集範圍内的所有服務帳戶（強烈不鼓勵）

如果你不關心如何區分權限，你可以将超級使用者通路權限授予所有服務賬号。

警告：這樣做會允許所有應用都對你的叢集擁有完全的通路權限，并将允許所有能夠讀取 Secret（或建立 Pod）的使用者對你的叢集有完全的通路權限。

kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

16. 寬松的 RBAC 權限

kubectl create clusterrolebinding permissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts

17. 示例

容器網絡接口（CNI）weavework

controlplane $ cat /opt/weave-kube.yaml
apiVersion: v1
kind: List
items:
  - apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
      namespace: kube-system
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
    rules:
      - apiGroups:
          - ''
        resources:
          - pods
          - namespaces
          - nodes
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - networking.k8s.io
        resources:
          - networkpolicies
        verbs:
          - get
          - list
          - watch
      - apiGroups:
          - ''
        resources:
          - nodes/status
        verbs:
          - patch
          - update
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRoleBinding
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
    roleRef:
      kind: ClusterRole
      name: weave-net
      apiGroup: rbac.authorization.k8s.io
    subjects:
      - kind: ServiceAccount
        name: weave-net
        namespace: kube-system
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: Role
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
      namespace: kube-system
    rules:
      - apiGroups:
          - ''
        resourceNames:
          - weave-net
        resources:
          - configmaps
        verbs:
          - get
          - update
      - apiGroups:
          - ''
        resources:
          - configmaps
        verbs:
          - create
  - apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
      namespace: kube-system
    roleRef:
      kind: Role
      name: weave-net
      apiGroup: rbac.authorization.k8s.io
    subjects:
      - kind: ServiceAccount
        name: weave-net
        namespace: kube-system
  - apiVersion: apps/v1
    kind: DaemonSet
    metadata:
      name: weave-net
      annotations:
        cloud.weave.works/launcher-info: |-
          {
            "original-request": {
              "url": "/k8s/v1.10/net.yaml?k8s-version=v1.16.0",
              "date": "Mon Oct 28 2019 18:38:09 GMT+0000 (UTC)"
            },
            "email-address": "[email protected]"
          }
      labels:
        name: weave-net
      namespace: kube-system
    spec:
      minReadySeconds: 5
      selector:
        matchLabels:
          name: weave-net
      template:
        metadata:
          labels:
            name: weave-net
        spec:
          containers:
            - name: weave
              command:
                - /home/weave/launch.sh
              env:
                - name: IPALLOC_RANGE
                  value: 10.32.0.0/24
                - name: HOSTNAME
                  valueFrom:
                    fieldRef:
                      apiVersion: v1
                      fieldPath: spec.nodeName
              image: 'docker.io/weaveworks/weave-kube:2.6.0'
              readinessProbe:
                httpGet:
                  host: 127.0.0.1
                  path: /status
                  port: 6784
              resources:
                requests:
                  cpu: 10m
              securityContext:
                privileged: true
              volumeMounts:
                - name: weavedb
                  mountPath: /weavedb
                - name: cni-bin
                  mountPath: /host/opt
                - name: cni-bin2
                  mountPath: /host/home
                - name: cni-conf
                  mountPath: /host/etc
                - name: dbus
                  mountPath: /host/var/lib/dbus
                - name: lib-modules
                  mountPath: /lib/modules
                - name: xtables-lock
                  mountPath: /run/xtables.lock
            - name: weave-npc
              env:
                - name: HOSTNAME
                  valueFrom:
                    fieldRef:
                      apiVersion: v1
                      fieldPath: spec.nodeName
              image: 'docker.io/weaveworks/weave-npc:2.6.0'
              resources:
                requests:
                  cpu: 10m
              securityContext:
                privileged: true
              volumeMounts:
                - name: xtables-lock
                  mountPath: /run/xtables.lock
          hostNetwork: true
          hostPID: true
          restartPolicy: Always
          securityContext:
            seLinuxOptions: {}