新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

使用RBAC限制對Kubernetes資源的訪問

使用 RBAC 限制對 Kubernetes 資源的訪問

作者：祝祥翻譯 2022-06-21 08:03:49

云計算

云原生通過本文，我們將學習如何從頭開始重新創(chuàng)建 Kubernetes RBAC 授權(quán)模型，并了解Roles、ClusterRoles、ServiceAccounts、RoleBindings 和 ClusterRoleBindings 之間的關(guān)系。

站在用戶的角度思考問題，與客戶深入溝通，找到沿河網(wǎng)站設(shè)計與沿河網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：做網(wǎng)站、網(wǎng)站設(shè)計、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名與空間、雅安服務(wù)器托管、企業(yè)郵箱。業(yè)務(wù)覆蓋沿河地區(qū)。

通過本文，我們將學習如何從頭開始重新創(chuàng)建 Kubernetes RBAC 授權(quán)模型，并了解Roles、ClusterRoles、ServiceAccounts、RoleBindings 和 ClusterRoleBindings 之間的關(guān)系。

隨著集群中應用程序和資源數(shù)量的增加，我們可能需要查看并限制他們相關(guān)的權(quán)限，從而避免一些危險操作。這些危險操作往往會嚴重影響生產(chǎn)環(huán)境，有時候，甚至會引起長時間的停機，比如過大的權(quán)限導致正常運行的服務(wù)被刪除。

正常情況下，我們可能希望限制生產(chǎn)系統(tǒng)僅僅允許少部分人管理以及訪問。

或者，我們可能希望向部署在集群中的維護人員授予一組有限的權(quán)限。

我們可以通過Kubernetes 中的基于角色的訪問控制 (RBAC) 來實現(xiàn)上述的需求。

Kubernetes API

在討論RBAC之前，讓我們看看授權(quán)模型在圖中的位置。

假設(shè)我們希望將以下 Pod 部署到 Kubernetes 集群：

apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: sise
  image: learnk8s/app:1.0.0
  ports:
  - containerPort: 8080

我們可以使用以下命令將 Pod 部署到集群：

$ kubectl apply -f pod.yaml

當我們輸入時kubectl apply，會觸發(fā)以下的操作。

kubectl 會：

1、從KUBECONFIG讀取配置。

2、從 API 中發(fā)現(xiàn) API 和對象。

3、驗證資源客戶端（是否有明顯的錯誤？）。

4、將帶有有效負載的請求發(fā)送到kube-apiserver。

當kube-apiserver收到請求時，它不會立即將其存儲在 etcd 中。

首先，它必須驗證請求者是否合法。

換句話說，它必須對請求進行身份驗證。(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)。

一旦通過身份驗證，請求者是否有權(quán)創(chuàng)建資源？

身份和權(quán)限不是一回事。

僅僅因為我們可以訪問集群并不意味著我們可以創(chuàng)建或讀取所有資源。

授權(quán)通常使用基于角色的訪問控制 (RBAC)(https://kubernetes.io/docs/reference/access-authn-authz/rbac/)來完成。

借助基于角色的訪問控制 (RBAC)，我們可以分配精細的權(quán)限并限制用戶或應用程序可以執(zhí)行的操作。

在更實際的情況下，API 服務(wù)器按順序執(zhí)行以下操作：

1、收到請求后，對用戶進行身份驗證。

a. 當驗證失敗時，通過返回來拒絕請求401 Unauthorized。
b, 否則，進入下一階段。

2、用戶已通過身份驗證，但他們是否有權(quán)訪問資源

a. 如果他們沒有權(quán)限，請通過返回來拒絕請求403 Forbidden。
b. 否則，繼續(xù)。

在本文中，我們將重點關(guān)注授權(quán)部分。

將用戶和權(quán)限與 RBAC 角色解耦

RBAC（Role-Based Access Control）即：基于角色的權(quán)限控制。通過角色關(guān)聯(lián)用戶，角色關(guān)聯(lián)權(quán)限的方式間接賦予用戶權(quán)限。如下圖：

有人會問為什么不直接給用戶分配權(quán)限，還多此一舉的增加角色這一環(huán)節(jié)呢？

其實是可以直接給用戶分配權(quán)限，只是直接給用戶分配權(quán)限，少了一層關(guān)系，擴展性弱了許多，適合那些用戶數(shù)量、角色類型少的平臺。

對于通常的系統(tǒng)，比如：存在多個用戶擁有相同的權(quán)限，在分配的時候就要分別為這幾個用戶指定相同的權(quán)限，修改時也要為這幾個用戶的權(quán)限進行一一修改。有了角色后，我們只需要為該角色制定好權(quán)限后，將相同權(quán)限的用戶都指定為同一個角色即可，便于權(quán)限管理。

對于批量的用戶權(quán)限調(diào)整，只需調(diào)整用戶關(guān)聯(lián)的角色權(quán)限，無需對每一個用戶都進行權(quán)限調(diào)整，既大幅提升權(quán)限調(diào)整的效率，又降低了漏調(diào)權(quán)限的概率。

要了解它是如何工作的，讓我們想象一下，我們必須從頭開始設(shè)計一個授權(quán)系統(tǒng)。我們該如何確保用戶對特定資源具有寫入權(quán)限？

一個簡單的實現(xiàn)可能涉及編寫一個如下所示的列表：

| User | Permission | Resource |
| ----- | ---------- | -------- |
| Bob   | read+write |   app1   |
| Alice |   read   |   app2   |
| Mo   |   read   |   app2   |

在這個例子中：

· Bob 有讀寫權(quán)限，可以訪問app1但無權(quán)訪問app2。
· Mo 和 Alice對app2有只讀權(quán)限，但是無權(quán)訪問app1。

上表適用于少數(shù)用戶和資源，但一旦開始擴展它就會顯示一些限制。

讓我們假設(shè)Mo和Alice在同一個Team中，并且他們被授予對app1的讀取權(quán)限。

我們必須將以下條目添加到表中：

| User     | Permission | Resource |
| --------- | ---------- | -------- |
| Bob       | read+write |   app1   |
| Alice     |   read   |   app2   |
| Mo       |   read   |   app2   |
| Alice     |   read   |   app1   |
| Mo       |   read   |   app1   |

這很好，但Alice和Mo是否有相同的訪問權(quán)限并不明顯，因為他們是同一Team的成員。

在典型的授權(quán)系統(tǒng)中我們有用戶訪問資源。

我們可以直接向用戶分配權(quán)限，并定義他們可以使用的資源。

這些權(quán)限直接映射資源。注意它們是如何作用于用戶的。
如果我們決定讓第二個用戶具有相同的權(quán)限，則必須關(guān)聯(lián)相同的權(quán)限。

我們可以通過在表中添加“Team”列來解決這個問題，但更好的替代方法是分解關(guān)系：

1、我們可以為權(quán)限定義一個通用屬性：角色。
2、我們可以為定義的組織“Team”進行授權(quán)，而不是直接將權(quán)限分配給用戶。
3、最后，我們可以用戶加入到定義組織”Team“。

讓我們看看這有什么不同?，F(xiàn)在你有兩個權(quán)限映射關(guān)系表：

· 在第一個表中，權(quán)限映射到角色
· 在第二個表中，角色與身份相關(guān)聯(lián)

| Role     | Permission | Resource |
| -------- | ---------- | -------- |
| admin1   | read+write |   app1   |
| reviewer |   read   |   app2   |

| User |   Roles |
| ----- | -------- |
| Bob   | admin1 |
| Alice | reviewer |
| Mo   | reviewer |

當我們希望 Mo 成為 app1 的管理員時那又該如何做了？

我們可以像這樣將角色添加到用戶：

| User |       Roles       |
| ----- | ------------------- |
| Bob   |       admin1       |
| Alice |       reviewer     |
| M

我們已經(jīng)可以想象，將用戶與權(quán)限與角色分離可以促進擁有大量用戶和權(quán)限的大型組織中的安全管理。

使用 RBAC 時，我們擁有用戶、資源和角色。

權(quán)限不會直接分配給用戶。相反，他們被包括在這個角色中。

用戶通過綁定關(guān)聯(lián)到角色。

由于角色是通用的，當新用戶需要訪問相同資源時，您可以使用現(xiàn)有角色并將其新綁定關(guān)聯(lián)。

Kubernetes 中的 RBAC

Kubernetes 實現(xiàn)了一個 RBAC 模型（以及其他幾個模型）(https://kubernetes.io/docs/reference/access-authn-authz/authorization/#authorization-modules) 來保護集群中的資源。

基于角色（Role）的訪問控制（RBAC）是一種基于組織中用戶的角色來調(diào)節(jié)控制對計算機或網(wǎng)絡(luò)資源的訪問的方法。

RBAC 鑒權(quán)機制使用 rbac.authorization.k8s.io API 組來驅(qū)動鑒權(quán)決定，允許你通過 Kubernetes API 動態(tài)配置策略。

要啟用 RBAC，在啟動 API 服務(wù)器時將 --authorization-mode 參數(shù)設(shè)置為一個逗號分隔的列表并確保其中包含 RBAC。

kube-apiserver --authorization-mode=Example,RBAC --<其他選項> --<其他選項>

因此 Kubernetes 使用了前面解釋過的相同的三個概念：身份、角色和綁定。

它只是用稍微不同的名字來稱呼它們。

例如，讓我們檢查以下授予對 Pod、Service等資源的訪問權(quán)限所需的 YAML 定義：

apiVersion: v1
kind: ServiceAccount
metadata:
name: serviceaccount:app1
namespace: demo-namespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role:viewer
namespace: demo-namespace
rules:          # Authorization rules for this role
- apiGroups:  # 1st API group
    - ''      # An empty string designates the core API group.
  resources:
    - services
    - pods
  verbs:
    - get
    - list
- apiGroups: # 2nd API group
    - apiextensions.k8s.io
  resources:
    - customresourcedefinitions
  verbs:
    - list
- apiGroups: # 3rd API group
    - cilium.io
  resources:
    - ciliumnetworkpolicies
    - ciliumnetworkpolicies/status
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: rolebinding:app1-viewer
namespace: demo-namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: role:viewer
subjects:
- kind: ServiceAccount
  name: serviceaccount:app1
  namespace: demo-namespace

該文件分為三個部分：

1、ServiceAccount——這是訪問資源的用戶的身份。
2、Role——包含訪問資源的權(quán)限。
3、將身份（ServiceAccount）關(guān)聯(lián)到權(quán)限（Role）的 RoleBinding。

配置提交到集群后，允許使用服務(wù)帳戶的應用程序向以下端點發(fā)出請求：

# 1. Kubernetes builtin resources
/api/v1/namespaces/{namespace}/services
/api/v1/namespaces/{namespace}/pods
# 2. A specific API extention provided by cilium.io
/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies
/apis/cilium.io/v2/namespaces/{namespace}/ciliumnetworkpolicies/status

結(jié)果很成功，但是我們忽略了很多細節(jié)。

我們究竟授予了哪些資源訪問權(quán)限？

什么是服務(wù)帳戶？身份不只是集群中的“用戶”嗎？

為什么 Role 包含 Kubernetes 對象列表？

為了理解它們是如何工作的，讓我們拋開 Kubernetes RBAC 模型并嘗試從頭開始重建它。

我們將重點關(guān)注三個要素：

1、識別和分配身份。
2、’授予權(quán)限。
3、將身份與權(quán)限相關(guān)聯(lián)。

分配身份：用戶，組，robot賬戶

假設(shè)我們的新同事希望登錄 Kubernetes 界面。

在這種情況下，我們應該有一個“帳戶”或“用戶”的實體，每個實體都有一個唯一的名稱或 ID（例如電子郵件地址）。

我們應該如何將用戶存儲在集群中？

Kubernetes 沒有代表常規(guī)用戶帳戶的對象。

無法通過 API 調(diào)用將用戶添加到集群中。

相反，任何提供由集群的證書頒發(fā)機構(gòu) (CA) 簽名的有效證書的參與者都被視為已通過身份驗證。(https://kubernetes.io/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user)。

在這種情況下，Kubernetes 從證書的“subject”中的通用名稱字段中分配用戶名（例如，“/CN=bob”）。

創(chuàng)建一個臨時用戶信息對象并將其傳遞給授權(quán) (RBAC) 模塊。

深入研究代碼會發(fā)現(xiàn)一個結(jié)構(gòu)映射了從 Authentication 模塊收集的所有詳細信息。

type User struct {
   name string   // unique for each user
   ...           // other fields
}

請注意，User用于集群外的人員或應用。

如果要識別集群中的應用，則應改用服務(wù)帳戶。

該帳戶與普通用戶非常相似，但不同之處在于Kubernetes管理它。

服務(wù)帳戶通常分配給 pod 以授予權(quán)限。

例如，我們可以讓以下應用程序從集群內(nèi)部訪問資源：

· cilium-agent必須列出特定節(jié)點上的所有 pod 資源· ingress nginx控制器必須列出服務(wù)的所有后端端點。

對于這些應用，我們可以定義一個 ServiceAccount (SA)。

由于服務(wù)帳戶是在集群中管理的，因此我們可以使用 YAML 創(chuàng)建它們：

apiVersion: v1
kind: ServiceAccount
metadata:
name: sa:app1             # arbitrary but unique string
namespace: demo-namespace

為了方便 Kubernetes 管理，我們還可以定義一組User 或ServiceAccount。

通過這樣，我可以很方便的引用特定namespace中的所有 ServiceAccount。

現(xiàn)在我們已經(jīng)定義了如何訪問資源，是時候討論權(quán)限了。

此時，我們有一種機制來確定誰可以訪問資源。

它可能是一個人、一個robot賬戶或一群人。

但是他們在集群中訪問什么資源呢？

對資源的訪問進行建模

在Kubernetes中，我們感興趣的是控制對資源的訪問，比如Pod、Services、Endpoints等。

這些資源通常存儲在數(shù)據(jù)庫 (etcd) 中，并通過內(nèi)置 API 訪問，例如：

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

限制對這些資源的訪問的最佳方法是控制這些 API 端點的請求方式。

為此，我們將需要兩件事：

1、資源的 API 端點。
2、授予訪問資源的權(quán)限類型（例如只讀、讀寫等）。

對于權(quán)限，我們將使用verbs，例如get, list, create, patch, delete 等。

想象一下，你想要get, list 以及 watchPods、logs和Services等資源。

我們可以將這些資源和權(quán)限組合在一個列表中，如下所示：

resources:
- /api/v1/namespaces/{namespace}/pods/{name}
- /api/v1/namespaces/{namespace}/pods/{name}/log
- /api/v1/namespaces/{namespace}/serviceaccounts/{name}
verbs:
- get
- list
- watch

根據(jù)以下信息，我們可以更簡化定義上述信息：

· 基本 URL/api/v1/namespaces/對所有人都是通用的。也許我們可以省略它。
· 我們可以假設(shè)所有資源都在當前namespace中并刪除{namespace}路徑。

最終我們可以簡化為：

resources:
- pods
- pods/logs
- serviceaccounts
verbs:
- get
- list
- watch

該定義更人性化，我們可以很清晰的了解相關(guān)權(quán)限信息。

不過，權(quán)限配置不僅僅只有上面的內(nèi)容，還有更多的內(nèi)容。

除了 pod、endpoint、service等內(nèi)置對象的 API 外，Kubernetes 還支持 API 擴展。

例如，當使用安裝 Cilium CNI 時，腳本會創(chuàng)建一個CiliumEndpoint自定義資源 (CR)：

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
name: ciliumendpoints.cilium.io
spec:
group: cilium.io
names:
  kind: CiliumEndpoint
scope: Namespaced
# truncated...

這些對象存儲在集群中，可通過 kubectl 獲得：

$ kubectl get ciliumendpoints.cilium.io -n demo-namespace
NAME   ENDPOINT ID   IDENTITY ENDPOINT STATE   IPV4
IPV6
app1   2773         1628124 ready           10.6.7.54
app2   3568         1624494 ready           10.6.7.94
app3   3934         1575701 ready           10.6.4.24
$

可以通過 Kubernetes API 類似地訪問自定義資源：

/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints
/apis/cilium.io/v2/namespaces/{namespace}/ciliumendpoints/{name}

如果要將它們映射到 YAML 文件中，可以編寫以下內(nèi)容：

resources:
- ciliumnetworkpolicies  
- ciliumnetworkpolicies/status
verbs:
- get

但是，Kubernetes 怎么知道資源是自定義的呢？

它如何區(qū)分使用自定義資源和內(nèi)置的 API？

不幸的是，從 API endpoint刪除 URL 并不是一個好主意。

我們可以通過稍作更改來恢復它。

我們可以在頂部定義它并稍后使用它來擴展資源的 URL。

apiGroups:
- cilium.io     # APIGroup name
resources:
- ciliumnetworkpolicies  
- ciliumnetworkpolicies/status
verbs:
- get

對于沒有namespace API的POD之類的資源呢？

Kubernetes “”空API組是一個特殊的組，它引用內(nèi)置對象。因此，前面的定義應該擴展到：

apiGroups:
- '' # Built-in objects
resources:
- pods  
- pods/logs  
- serviceaccounts
verbs:
- get  
- list  
- watch

Kubernetes 讀取 API 組并自動將它們擴展為：

· 如果為空，則將“”轉(zhuǎn)換為/api/v1/xxx。
· 否則為/apis/{apigroup_name}/{apigroup_version}/xxx。

既然我們知道了如何映射資源和權(quán)限，現(xiàn)在終于到了將對多個資源的訪問組合在一起的時候了。在Kubernetes中，resources和verbs的集合稱為rules，您可以將規(guī)則分組到列表中：

rules:
- rule 1  
- rule 2

每條規(guī)則都包含我們上述所提到的apiGroups,resources和verbs：

rules: # Authorization rules
- apiGroups: # 1st API group
    - '' # An empty string designates the core API group.
  resources:
    - pods
    - pods/logs
    - serviceaccounts
  verbs:
    - get
    - list
    - watch
- apiGroups: # another API group
    - cilium.io # Custom APIGroup
  resources:
    - ciliumnetworkpolicies
    - ciliumnetworkpolicies/status
  verbs:
    - get

規(guī)則的集合在 Kubernetes 中具有特定的名稱，稱為角色。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: viewer
rules: # Authorization rules
- apiGroups: # 1st API group
    - '' # An empty string designates the core API group.
  resources:
    - pods
    - pods/logs
    - serviceaccounts
  verbs:
    - get
    - list
    - watch
- apiGroups: # another API group
    - cilium.io # Custom APIGroup
  resources:
    - ciliumnetworkpolicies
    - ciliumnetworkpolicies/status
  verbs:
    - get

到目前為止，我們定義了：

· 具有用戶、服務(wù)帳戶和組的身份。
· 對具有角色的資源的權(quán)限。

最后，缺少的部分是將兩者聯(lián)系起來。

向用戶授予權(quán)限

RoleBinding 將角色中定義的權(quán)限授予用戶、服務(wù)帳戶或組。讓我們看一個例子：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-binding-for-app1
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: viewer
subjects:
- kind: ServiceAccount
  name: sa-for-app1
  namespace: kube-system

該定義有兩個重要字段：

· 引用viewer角色的roleRef。
· 關(guān)聯(lián)到sa-for-app1服務(wù)帳戶的subjects。

將資源提交到集群后，使用服務(wù)帳戶的應用程序或用戶將有權(quán)訪問角色中列出的資源。

如果我們刪除綁定，應用程序或用戶將失去對這些資源的訪問權(quán)限（但該角色將隨時準備被其他綁定使用）。

請注意該subjects字段是一個包含kind，namespace和name的列表。

該kind屬性是從服務(wù)帳戶和組中識別用戶所必需的。

但是namespace了？

將集群拆分為namespace，并將對namespace資源的訪問限制為特定帳戶，這通常很有幫助。

在大多數(shù)情況下，Role和RoleBinding與namespace關(guān)聯(lián)，并授予對特定namespace的訪問權(quán)。

然而，這兩種資源是可以混合使用的——稍后我們將描述該如何混合。

在我們總結(jié)理論并從實踐開始之前，讓我們看一下subjects的幾個例子：

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io
   # when the namespace field is not specified, this targets all service accounts in all namespace

我們還可以將多個組、用戶或服務(wù)帳戶作為subjects：

subjects:
- kind: Group
  name: system:authenticated # for all authenticated users
  apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated # for all unauthenticated users
  apiGroup: rbac.authorization.k8s.io

回顧一下到目前為止所學的內(nèi)容，讓我們看看如何授予應用程序訪問某些自定義資源的權(quán)限。

首先，讓我們介紹一下場景：你有一個應用程序需要訪問Cilium暴露的資源。

想象一下，在集群中部署了一個需要通過 API 訪問自定義資源的應用程序。
如果不授予對這些API的訪問權(quán)限，請求將失敗，并顯示403禁止的錯誤消息。

如何授予訪問這些資源的權(quán)限？

使用服務(wù)帳戶、角色和角色綁定。

首先，我們應該為我們的工作負載創(chuàng)建一個身份。在 Kubernetes 中，這意味著創(chuàng)建一個服務(wù)帳戶。

然后，我們需要定義權(quán)限并將其包含到角色中。

最后，我們希望通過RoleBinding將身份（服務(wù)帳戶）關(guān)聯(lián)到權(quán)限（角色）。

下次應用程序向Kubernetes API發(fā)出請求時，它將被授予訪問Cilium資源的權(quán)限。

Namespaces和cluster-wide的資源

當我們討論資源時，您了解到endpoint的結(jié)構(gòu)如下面一樣：

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

但是沒有namespace的資源，比如持久卷和節(jié)點呢？

namespace資源只能在namespace內(nèi)創(chuàng)建，并且該namespace的名稱包含在 HTTP 路徑中。

如果資源是全局的，比如節(jié)點，namespace名稱就不會出現(xiàn)在 HTTP 路徑中。

/api/v1/nodes/{name}
/api/v1/persistentvolume/{name}

我們可以將它們添加到角色中嗎？

是的，我們可以添加。

畢竟，在引入 Roles 和 RoleBindings 時，我們沒有討論任何namespace的限制。

下面是一個例子：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: viewer
rules: # Authorization rules
- apiGroups: # 1st API group
    - '' # An empty string designates the core API group.
  resources:
    - persistentvolumes
    - nodes
  verbs:
    - get
    - list
    - watch

但是，如果我們嘗試提交該配置并將其關(guān)聯(lián)到服務(wù)帳戶，大家可能會意識到它不起作用。

持久卷和節(jié)點是集群范圍的資源。

但是，角色可以授予對namespace范圍內(nèi)資源的訪問權(quán)限。

如果我們想使用適用于整個集群的 Role，我們可以使用 ClusterRole（以及相應 ClusterRoleBinding的為它分配subject）。

之前的配置應改為：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: viewer
rules:          # Authorization rules
- apiGroups:  # 1st API group
    - ''      # An empty string designates the core API group.
  resources:
    - persistentvolumes
    - nodes
  verbs:
    - get
    - list
    - watch

請注意，唯一的變化是kind屬性，而其他一切都保持不變。

我們可以使用 ClusterRoles 授予對所有資源的權(quán)限——例如，集群中的所有 Pod。

此功能不限于集群范圍的資源。

Kubernetes 已經(jīng)附帶了一些角色和集群角色。

讓我們來看一下。

$ kubectl get roles -n kube-system | grep "^system:"
NAME
system::leader-locking-kube-controller-manager
system::leader-locking-kube-scheduler
system:controller:bootstrap-signer
system:controller:cloud-provider
system:controller:token-cleaner
# truncated output...

system:前綴表示資源由集群控制平面直接管理。

此外，所有默認的 ClusterRoles 和 ClusterRoleBindings 都標有kubernetes.io/bootstrapping=rbac-defaults。

讓我們也列出 ClusterRoles：

$ kubectl get clusterroles -n kube-system | grep "^system:"
NAME
system:aggregate-to-admin
system:aggregate-to-edit
system:aggregate-to-view
system:discovery
system:kube-apiserver
system:kube-controller-manager
system:kube-dns
system:kube-scheduler
# truncated output...

我們可以使用以下命令檢查每個 Role 和 ClusterRole 的詳細信息：

                                                

                                                當前題目：使用RBAC限制對Kubernetes資源的訪問                                                

                                                網(wǎng)站鏈接：http://www.fisionsoft.com.cn/article/cddiejd.html