正文

Kubernetes 主要通過(guò) API Server 對(duì)外提供服務(wù)，對(duì)于這樣的系統(tǒng)來(lái)說(shuō)，如果不加以安全限制，那么可能導(dǎo)致請(qǐng)求被濫用，甚至導(dǎo)致整個(gè)集群崩塌。

鑒于此，Kubernetes 對(duì)于訪問(wèn) API 的用戶提供了相應(yīng)的安全控制：認(rèn)證和授權(quán)。認(rèn)證解決用戶是誰(shuí)的問(wèn)題，授權(quán)解決用戶能做什么的問(wèn)題。只有通過(guò)合理的權(quán)限控制，才能夠保證整個(gè)集群系統(tǒng)的安全可靠。

下圖是 API 訪問(wèn)需要經(jīng)過(guò)的三個(gè)步驟，它們分別是：認(rèn)證、授權(quán)和準(zhǔn)入，準(zhǔn)入不在這章節(jié)討論，它更多專(zhuān)注的是資源的管理。

認(rèn)證

認(rèn)證（Authentication）是指用戶是否可以登錄 Kubernetes，即是否可以向 API Server 發(fā)送請(qǐng)求。

在 Kubernetes 中，有兩類(lèi)用戶：

• Normal Users：外部用戶
• Service Accounts：內(nèi)部用戶

認(rèn)證用戶

Normal Users

Normal Users 獨(dú)立于 Kubernetes，不歸其管理，這類(lèi)用戶可以是：

• 可以分發(fā) private keys 的管理員（真人）
• 提供用戶服務(wù)的第三方廠商，比如 Google Accounts
• 保存用戶名和密碼的列表文件

如果用戶都不在 Kubernetes 中，都不歸它管，那它是如何進(jìn)行認(rèn)證的呢？

對(duì)于一般的應(yīng)用系統(tǒng)來(lái)說(shuō)，用戶提供用戶名和密碼，服務(wù)端收到過(guò)后會(huì)在數(shù)據(jù)庫(kù)中進(jìn)行檢查是否存在并有效，如果有就表示鑒權(quán)成功，反之失敗。

那對(duì)于 Kubernetes 來(lái)說(shuō)，是如何實(shí)現(xiàn)的呢？

盡管無(wú)法通過(guò) API 調(diào)用來(lái)添加普通用戶，Kubernetes 巧妙的通過(guò)證書(shū)來(lái)進(jìn)行用戶認(rèn)證。也就是說(shuō)，不管任何用戶，只要能提供有效的證書(shū)就能通過(guò) Kubernetes 用戶認(rèn)證。

通過(guò)用戶認(rèn)證過(guò)后，Kubernetes 會(huì)把證書(shū)中的 CN 作為用戶名（比如證書(shū)中”/CN=joker“，則用戶名就是 Joker），把 Organization 作為用戶組，然后由用戶名和用戶組綁定的 Role 來(lái)決定用戶的權(quán)限。

Service Accounts

Service Accounts 由 Kubernetes 管理，它們被綁定到特定的 namespace，其可以通過(guò) API Server 自己創(chuàng)建，也可以通過(guò)調(diào)用 API 來(lái)創(chuàng)建，比如使用 kubectl 客戶端工具。

與 Normal Users 不同，Service Accounts 存在對(duì)應(yīng)的 Kubernetes 對(duì)象，當(dāng)創(chuàng)建 Service Accounts，會(huì)創(chuàng)建相應(yīng)的 Secret，里面保存對(duì)應(yīng)的密碼信息（在 1.24.x 版本中，不會(huì)創(chuàng)建對(duì)應(yīng)的 secret）。當(dāng)創(chuàng)建的 Pod 指定了一個(gè) Service Account，其 Secret 會(huì)被 Mount 到 Pod 中，Pod 中的進(jìn)程就可以訪問(wèn) Kubernetes API 了。

認(rèn)證策略

Kubernetes 有以下幾種鑒權(quán)方法：

• 客戶端證書(shū)
• 不記名令牌
• 身份認(rèn)證代理
• 通過(guò)鑒權(quán)插件的 HTTP 基本認(rèn)證機(jī)制

當(dāng) HTTP 請(qǐng)求發(fā)送到 API Server 時(shí)，Kubernetes 會(huì)從 Request 中關(guān)聯(lián)以下信息：

• Username：用戶名，用來(lái)辨識(shí)最終用戶的字符串，比如 kube-admin 或jane@example.com
• UID：用戶 ID，代表用戶的唯一 ID
• Groups：用戶組，代表邏輯相關(guān)的一組用戶，
• Extra Fields，擴(kuò)展字段，鑒權(quán)可能需要的其他信息

需要注意的是，當(dāng)多種鑒權(quán)方法同時(shí)啟用時(shí)，第一個(gè)鑒權(quán)方法鑒權(quán)成功即通過(guò)驗(yàn)證，其它方法不再鑒權(quán)，同時(shí) api-server 也不保證鑒權(quán)方法的順序。所有鑒權(quán)成功的用戶都會(huì)加到 group “system:authenticated”中。

客戶端證書(shū)

當(dāng)我們使用客戶端證書(shū)進(jìn)進(jìn)行認(rèn)證時(shí)，需要向 Kubernetes 提供有效的證書(shū)，這個(gè)證書(shū)可以是外部證書(shū)，也可以是 Kubernetes 自己審批的證書(shū)。

如果是外部證書(shū)，就需要在 API Server 啟動(dòng)的時(shí)候用--client-ca-file=SOMEFILE參數(shù)引入外部證書(shū)的 CA 等信息，用來(lái)驗(yàn)證客戶端證書(shū)的有效性。

當(dāng)認(rèn)證通過(guò)后，Kubernetes 會(huì)把證書(shū)的 Subject CN 作為用戶名，Organization 作為用戶組（Group）。

不記名令牌

當(dāng)使用不記名令牌（Bearer token）來(lái)對(duì)某 HTTP 客戶端執(zhí)行身份認(rèn)證時(shí)，API 服務(wù)器希望看到一個(gè)名為 Authorization 的 HTTP 頭，其值格式為 Bearer。不記名令牌（Bearer token）必須是一個(gè)可以放入 HTTP 頭部值字段的字符序列，至多可使用 HTTP 的編碼和引用機(jī)制。例如：如果持有者令牌為 31ada4fd-adec-460c-809a-9e56ceb75269，則其出現(xiàn)在 HTTP 頭部時(shí)如下所示：

Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269

在 Kubernetes 中，主要有以下幾種使用不記名令牌（Bearer token）的方法：

• Static Token File（靜態(tài)令牌）
• Service Account Tokens（服務(wù)賬號(hào)令牌）
• OpenID Connect Tokens（OIDC 令牌）

Static Token File

當(dāng)使用靜態(tài)令牌的時(shí)候，API Server 會(huì)通過(guò)--token-auth-file=SOMEFILE從外部引入一個(gè) CSV 文件，API Server 會(huì)從這個(gè)文件中讀取對(duì)應(yīng)的用戶名和用戶組。

當(dāng)客戶端進(jìn)行請(qǐng)求時(shí)，API Server 把請(qǐng)求 Header 中的 Bearer tokens 和文件中的 token 進(jìn)行比較，然后判斷 Token 是否有效。

Service Account Tokens

當(dāng)手動(dòng)或者自動(dòng)創(chuàng)建 Service Account 的時(shí)候，Kubernetes 會(huì)自動(dòng)創(chuàng)建一個(gè) Service Account Token，在 v1.24 版本之前，會(huì)對(duì)應(yīng)創(chuàng)建一個(gè) secret 保存到對(duì)應(yīng)的 namespace 中，在 v1.24 版本之后不會(huì)再單獨(dú)創(chuàng)建 secret，而是在啟動(dòng) Pod 的時(shí)候，由 kubelet 通過(guò) TokenRequest API 生成一個(gè) Token 掛載到 Pod 中。

上文提到，Service Account 主要是為 Pods 提供訪問(wèn) API Server 的功能，當(dāng) Pod 創(chuàng)建過(guò)后，Service Account Token 就會(huì)被 Mount 到 Pod 中，此時(shí) Pod 就擁有訪問(wèn) API Server 的能力。

當(dāng)然，Service Account Token 除了用在 Pod 上，在外部也可以使用，在《Kubernetes 集群管理》中的集群安裝章節(jié)，有介紹使用 Token 訪問(wèn) Kubernetes Dashboard，這時(shí)候使用的也是 Service Account Token。

OpenID Connect Tokens

OpenID Connect 是一種 OAuth3 認(rèn)證方式，Kubernetes 可以利用 OAuth3 Token Response 中的 ID Token 作為 Bearer Token 進(jìn)行認(rèn)證訪問(wèn)。

其流程如下：

• 登錄到你的身份服務(wù)（Identity Provider）
• 你的身份服務(wù)將為你提供 access_token、id_token 和 refresh_token
• 在使用 kubectl 時(shí)，將 id_token 設(shè)置為 --token 標(biāo)志值，或者將其直接添加到 kubeconfig 中
• kubectl 將你的 id_token 放到一個(gè)稱(chēng)作 Authorization 的頭部，發(fā)送給 API 服務(wù)器
• API 服務(wù)器將負(fù)責(zé)通過(guò)檢查配置中引用的證書(shū)來(lái)確認(rèn) JWT 的簽名是合法的
• 檢查確認(rèn) id_token 尚未過(guò)期
• 確認(rèn)用戶有權(quán)限執(zhí)行操作
• 鑒權(quán)成功之后，API 服務(wù)器向 kubectl 返回響應(yīng)
• kubectl 向用戶提供反饋信息

不管用戶通過(guò)哪種方式進(jìn)行認(rèn)證，認(rèn)證通過(guò)并不代表就有操作權(quán)限，僅僅只是通過(guò)第一條防線而已，下一步就要進(jìn)行鑒權(quán)，用來(lái)決定用戶是否有具體的操作權(quán)限。

鑒權(quán)

鑒權(quán)流程

當(dāng)請(qǐng)求通過(guò)認(rèn)證（Authentication）過(guò)后，就會(huì)進(jìn)入鑒權(quán)（Authorization）階段。在這個(gè)階段 Kubernetes 會(huì)檢查請(qǐng)求是否有權(quán)限訪問(wèn)需要的資源，如果有權(quán)限則開(kāi)始處理請(qǐng)求，反之則返回權(quán)限不足。

API Server 會(huì)檢查所有 Policy 來(lái)檢查是否存在 Policy 允許請(qǐng)求中的動(dòng)作，存在則允許請(qǐng)求執(zhí)行，否則會(huì)拒絕執(zhí)行并返回 403 錯(cuò)誤。當(dāng)配置了多個(gè)授權(quán)模塊的時(shí)候，請(qǐng)求會(huì)按順序校驗(yàn)每一個(gè)模板，如果其中任一模塊校驗(yàn)不通過(guò)，則請(qǐng)求會(huì)被拒絕，不再進(jìn)行后續(xù)的校驗(yàn)。

Kubernetes 在做鑒權(quán)時(shí)，主要檢查以下信息：

• user：同鑒權(quán)中檢查的信息相同
• group：同鑒權(quán)中檢查的信息相同
• extra：同鑒權(quán)中檢查的信息相同
• API：是否為 Api 資源
• Request path：非資源（API 資源）endpoint，比如/healthz
• API request verb：API 動(dòng)作，比如 get, list, create, update, patch，對(duì)某個(gè)資源的具體動(dòng)作，比如，列出所有的 pod
• HTTP request verb：用于非資源的請(qǐng)求中的 HTTP 動(dòng)作，比如 get, post, put
• Resource：請(qǐng)求訪問(wèn)的資源名字或 ID
• Subresource：請(qǐng)求訪問(wèn)的子資源名字或 ID
• Namespace：資源所在的名字空間
• API group：請(qǐng)求訪問(wèn)的 API group，API group 指控制相關(guān)資源的一組 Api，如果未指定則代表 core API group

鑒權(quán)模塊

Kubernetes 提供了以下 4 種鑒權(quán)模式：

• Node：一種特殊的授權(quán)模塊，基于 Node 上運(yùn)行的 Pod 為 Kubelet 授權(quán)
• ABAC：基于屬性的訪問(wèn)控制
• RBAC：基于角色的訪問(wèn)控制
• Webhook：HTTP 請(qǐng)求回調(diào)，通過(guò)一個(gè) WEB 應(yīng)用鑒定是否有權(quán)限進(jìn)行某項(xiàng)操作

這里只會(huì)介紹 RBAC——基于角色的訪問(wèn)控制。在實(shí)際中，這種模式使用的場(chǎng)景比較多。

RBAC

RBAC 是 Kubernetes 中常用的鑒權(quán)模式，其基本概念如下：

• Rule：規(guī)則，一組屬于不同 API Group 的操作集合；
• Role：角色，用于定義一組對(duì) Kubernetes API 對(duì)象操作的一組規(guī)則，作用于當(dāng)個(gè) namespace；
• ClusterRole：集群角色，該角色不受 namespace 的限制；
• Subject：被作用者，也就是規(guī)則作用的對(duì)象；
• RoleBinding：將角色和被作用者進(jìn)行綁定，作用于當(dāng)個(gè) namespace；
• ClusterRoleBinding：將集群角色和作用者進(jìn)行綁定，不受 namespace 限制；

Role 和 ClusterRole

Role 和 ClusterRole 中定義一組相關(guān)權(quán)限的規(guī)則，這些權(quán)限是累加的（不存在拒絕某操作的規(guī)則）。其中 Role 是 Namespace 級(jí)別的，而 ClusterRole 是集群級(jí)別的。

Role 的定義如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
- apiGroups: [""]
  resources: ["pods", "deployment"]
  verbs: ["creat", "delete", "watch", "list", "get"]

其含義是：它允許被作用者在 devops 的 namespace 中對(duì) pod 和 deployment 有 creat，delete，watch，list，get 操作。由于 Role 是 Namespace 級(jí)別，所以上面的規(guī)則只對(duì) devops 的 namespace 有效。

ClusterRole 的定義如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-role-demo
rules:
- apiGroups: [""]
  resources: [""]
  verbs: ["watch", "list", "get"]

其含義是對(duì)所有資源都有 watch、list、get 的操作權(quán)限。

如果要定義所有權(quán)限，可以將 verbs 字段定義如下：

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

RoleBinding 和 ClusterRoleBinding

角色綁定將一個(gè)角色中定義的各種權(quán)限授予一個(gè)或者一組用戶。角色綁定包含了一組相關(guān)主體（即 subject, 包括用戶——User、用戶組——Group、或者服務(wù)賬戶——Service Account）以及對(duì)被授予角色的引用。在命名空間中可以通過(guò) RoleBinding 對(duì)象授予權(quán)限，而集群范圍的權(quán)限授予則通過(guò) ClusterRoleBinding 對(duì)象完成。

RoleBinding 可以引用在同一命名空間內(nèi)定義的 Role 對(duì)象。如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: joker-rolebinding
  namespace: devops
subjects:
  - kind: User
    name: joker
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io

這就給 joker 用戶和 role-demo 的 Role 建立了綁定關(guān)系，其中 joker 這個(gè) User 只是一個(gè)授權(quán)系統(tǒng)中的邏輯概念，它需要通過(guò)外部認(rèn)證服務(wù)，比如 Keystone，或者直接給 API Server 指定一個(gè)用戶名，密碼文件。

上面的 YAML 文件中其中一個(gè)重要的字段是 Subjects 字段，它定義"被作用者"，其中的 kind 表示被作用者的類(lèi)型，其有以下三種類(lèi)型：

• User：用戶，這是由外部獨(dú)立服務(wù)進(jìn)行管理的，管理員進(jìn)行私鑰的分配，用戶可以使用 KeyStone 或者 Goolge 帳號(hào)，甚至一個(gè)用戶名和密碼的文件列表，對(duì)于用戶的管理集群內(nèi)部沒(méi)有一個(gè)關(guān)聯(lián)的資源對(duì)象，所以用戶不能通過(guò)集群內(nèi)部的 API 來(lái)進(jìn)行管理。
• Group：組，這是用來(lái)關(guān)聯(lián)多個(gè)賬戶，集群中有一個(gè)默認(rèn)的組，比如 cluster-admin。
• ServiceAccount：服務(wù)帳號(hào)，通過(guò) Kubernetes API 來(lái)管理的一些用戶帳號(hào)，和 namespace 進(jìn)行關(guān)聯(lián)的，適用于集群內(nèi)部運(yùn)行的應(yīng)用程序，需要通過(guò) API 來(lái)完成權(quán)限認(rèn)證，所以在集群內(nèi)部進(jìn)行權(quán)限操作，我們都需要使用到 ServiceAccount。

另外一個(gè)重要字段是 roleRef，它定義 RoleBing 對(duì)象可以直接通過(guò) Role 的名字來(lái)引用我們定義的 Role 對(duì)象，從而定義被作業(yè)者和角色之間的綁定關(guān)系。

RoleBinding 是 namespace 級(jí)別的，如果是集群級(jí)別則用 ClusterRoleBinding，如下：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: joker-clusterrolebinding
subjects:
  - kind: User
    name: joker
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-role-demo
  apiGroup: rbac.authorization.k8s.io

上面定義的就是 joker 這個(gè)用戶對(duì)所有 namespace 里的資源都有 watch，list，get 的操作權(quán)限。

Service Account

Service Account 也是一種賬號(hào)，但它并不是給 Kubernetes 集群的用戶（系統(tǒng)管理員、運(yùn)維人員、租戶用戶等）用的，而是給運(yùn)行在 Pod 里的進(jìn)程用的，它為 Pod 里的進(jìn)程提供了必要的身份證明。

我們通過(guò)一個(gè)例子來(lái)了解 ServiceAccount 的授權(quán)過(guò)程。

1、首先定義一個(gè) ServiceAccount：

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: devops
  name: sa-demo

一個(gè)簡(jiǎn)單的 ServiceAccount 只需要簡(jiǎn)單的 namespace 和 name 即可。

2、編寫(xiě) RoleBinding 的 YAML 文件來(lái)為這個(gè) ServiceAccount 分配權(quán)限：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: role-demo
  namespace: devops
rules:
  - apiGroups: [""]
    resources: ["pods", "deployment"]
    verbs: ["creat", "delete", "watch", "list", "get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: sa-rolebinding
  namespace: devops
subjects:
  - kind: ServiceAccount
    name: sa-demo
    namespace: devops
roleRef:
  kind: Role
  name: role-demo
  apiGroup: rbac.authorization.k8s.io

然后我們創(chuàng)建上面定義的 YAML 文件，查看創(chuàng)建完成后的信息：

$ kubectl get sa -n devops
NAME      SECRETS   AGE
default   0         6m25s
sa-demo   0         6m25s
$ kubectl get role -n devops
NAME        CREATED AT
role-demo   2022-07-06T04:27:02Z
$ kubectl get rolebinding -n devops
NAME             ROLE             AGE
sa-rolebinding   Role/role-demo   6m50s

現(xiàn)在創(chuàng)建一個(gè) Pod 并使用 sa-demo Service Account。

apiVersion: v1
kind: Pod
metadata:
  name: pod-sa-demo
  namespace: devops
spec:
  serviceAccountName: sa-demo
  containers:
  - name: pod-sa-demo
    image: nginx
    imagePullPolicy: IfNotPresent

查看 Pod 信息如下：

$ kubectl get po -n devops pod-sa-demo -oyaml
apiVersion: v1
kind: Pod
metadata:
  annotations:
    cni.projectcalico.org/containerID: c0820de4319bb6915602c84132ff83a63f62abaa1e9c706bad04e64661455d30
    cni.projectcalico.org/podIP: 172.16.51.225/32
    cni.projectcalico.org/podIPs: 172.16.51.225/32
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"v1","kind":"Pod","metadata":{"annotations":{},"name":"pod-sa-demo","namespace":"devops"},"spec":{"containers":[{"image":"nginx","imagePullPolicy":"IfNotPresent","name":"pod-sa-demo"}],"serviceAccountName":"sa-demo"}}
  creationTimestamp: "2022-07-06T04:30:13Z"
  name: pod-sa-demo
  namespace: devops
  resourceVersion: "192831"
  uid: 4f4c7c5a-53ca-45f7-94ad-63e546cfcc62
spec:
  containers:
  - image: nginx
    imagePullPolicy: IfNotPresent
    name: pod-sa-demo
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-vxrcd
      readOnly: true
  dnsPolicy: ClusterFirst
  enableServiceLinks: true
  nodeName: kk-node01
  preemptionPolicy: PreemptLowerPriority
  priority: 0
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: sa-demo
  serviceAccountName: sa-demo
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
  - name: kube-api-access-vxrcd
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace

從上面可以看到 Service Account Token 被掛載到 Pod 中了。

$ kubectl exec -it -n devops pod-sa-demo -- /bin/sh
# ls /var/run/secrets/kubernetes.io/serviceaccount
ca.crt  namespace  token

其中 ca,crt 就是用來(lái)訪問(wèn) API Server 的。

如果一個(gè) Pod 在定義時(shí)沒(méi)有指定 spec.serviceAccountName 屬性，則系統(tǒng)會(huì)自動(dòng)為其賦值為 default，即大家都使用同一個(gè) Namespace 下的默認(rèn) Service Account。

Subjects 的 kind 類(lèi)型除了 User，ServiceAccount 之外，還有一個(gè) Group，就是一組用戶的意思。如果你為 Kubernetes 配置了外部認(rèn)證服務(wù)的話，這個(gè)用戶組就由外部認(rèn)證服務(wù)提供。而對(duì)于 Kubernetes 內(nèi)置用戶 ServiceAccount 來(lái)說(shuō)，其也有用戶和用戶組的概念，其中對(duì)于一個(gè) ServiceAccount，其在 Kubernetes 中對(duì)應(yīng)的用戶是：

system:serviceaccount:<ServiceAccount名字>

而對(duì)于其用戶組是：

system:serviceaccounts:<Namespace名字>

比如我們定義下面這個(gè) RoleBinding:

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

這就意味著 Role 這個(gè)角色的權(quán)限規(guī)則作用與 devops 的 namespace 中的所有 ServiceAccount。

再比如：

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

這就意味著 Role 這個(gè)角色規(guī)則作用與整個(gè)集群的所有 ServiceAccount。

kubernetes 已經(jīng)內(nèi)置了許多 ClusterRole，以 system:開(kāi)頭，可以用 kubectl get clusterrole 查看。

另外，Kubernetes 還提供了四個(gè)預(yù)先定義好的 ClusterRole 來(lái)供用戶直接使用，它們是：

• cluster-admin：超管
• admin：普通管理權(quán)限
• edit：修改權(quán)限
• view：只讀權(quán)限

我們?cè)诙x RoleBinding 或 ClusterRolebinding 的時(shí)候可以直接使用。

最后

Kubernetes 的權(quán)限管理就介紹到這里，本章節(jié)主要介紹了認(rèn)證、授權(quán)的大概流程以及在 Kubernetes 中是如何實(shí)現(xiàn)認(rèn)證、授權(quán)的。學(xué)完本章，你可以掌握認(rèn)證用戶有哪些，有哪些認(rèn)證策略，以及如何使用 RBAC 實(shí)現(xiàn)鑒權(quán)。

以上就是Kubernetes 權(quán)限管理認(rèn)證鑒權(quán)詳解的詳細(xì)內(nèi)容，更多關(guān)于Kubernetes 權(quán)限管理的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論