使用 RBAC 限制對(duì) Kubernetes 資源的訪問(wèn)

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

云計(jì)算

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

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

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

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

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

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

我們可以通過(guò)Kubernetes 中的基于角色的訪問(wèn)控制 (RBAC) 來(lái)實(shí)現(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

當(dāng)我們輸入時(shí)kubectl apply，會(huì)觸發(fā)以下的操作。

kubectl 會(huì)：

1、從KUBECONFIG讀取配置。

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

3、驗(yàn)證資源客戶端（是否有明顯的錯(cuò)誤？）。

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

當(dāng)kube-apiserver收到請(qǐng)求時(shí)，它不會(huì)立即將其存儲(chǔ)在 etcd 中。

首先，它必須驗(yàn)證請(qǐng)求者是否合法。

換句話說(shuō)，它必須對(duì)請(qǐng)求進(jìn)行身份驗(yàn)證。(https://kubernetes.io/docs/reference/access-authn-authz/authentication/)。

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

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

僅僅因?yàn)槲覀兛梢栽L問(wèn)集群并不意味著我們可以創(chuàng)建或讀取所有資源。

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

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

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

1、收到請(qǐng)求后，對(duì)用戶進(jìn)行身份驗(yàn)證。

a. 當(dāng)驗(yàn)證失敗時(shí)，通過(guò)返回來(lái)拒絕請(qǐng)求401 Unauthorized。

b, 否則，進(jìn)入下一階段。

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

a. 如果他們沒(méi)有權(quán)限，請(qǐng)通過(guò)返回來(lái)拒絕請(qǐng)求403 Forbidden。

b. 否則，繼續(xù)。

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

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

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

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

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

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

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

要了解它是如何工作的，讓我們想象一下，我們必須從頭開(kāi)始設(shè)計(jì)一個(gè)授權(quán)系統(tǒng)。我們?cè)撊绾未_保用戶對(duì)特定資源具有寫入權(quán)限？

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

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

在這個(gè)例子中：

· Bob 有讀寫權(quán)限，可以訪問(wèn)app1但無(wú)權(quán)訪問(wèn)app2。

· Mo 和 Alice對(duì)app2有只讀權(quán)限，但是無(wú)權(quán)訪問(wèn)app1。

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

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

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

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

這很好，但Alice和Mo是否有相同的訪問(wèn)權(quán)限并不明顯，因?yàn)樗麄兪峭籘eam的成員。

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

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

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

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

1、我們可以為權(quán)限定義一個(gè)通用屬性：角色。

2、我們可以為定義的組織“Team”進(jìn)行授權(quán)，而不是直接將權(quán)限分配給用戶。

3、最后，我們可以用戶加入到定義組織”Team“。

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

· 在第一個(gè)表中，權(quán)限映射到角色

· 在第二個(gè)表中，角色與身份相關(guān)聯(lián)

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

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

當(dāng)我們希望 Mo 成為 app1 的管理員時(shí)那又該如何做了？

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

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

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

• 使用 RBAC 時(shí)，我們擁有用戶、資源和角色。

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

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

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

Kubernetes 中的 RBAC

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

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

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

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

kube-apiserver --authorization-mode=Example,RBAC --<其他選項(xiàng)> --<其他選項(xiàng)>

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

它只是用稍微不同的名字來(lái)稱呼它們。

例如，讓我們檢查以下授予對(duì) Pod、Service等資源的訪問(wèn)權(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

該文件分為三個(gè)部分：

1、ServiceAccount——這是訪問(wèn)資源的用戶的身份。

2、Role——包含訪問(wèn)資源的權(quán)限。

3、將身份（ServiceAccount）關(guān)聯(lián)到權(quán)限（Role）的 RoleBinding。

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

# 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é)果很成功，但是我們忽略了很多細(xì)節(jié)。

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

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

為什么 Role 包含 Kubernetes 對(duì)象列表？

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

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

1、識(shí)別和分配身份。

2、’授予權(quán)限。

3、將身份與權(quán)限相關(guān)聯(lián)。

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

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

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

我們應(yīng)該如何將用戶存儲(chǔ)在集群中？

Kubernetes 沒(méi)有代表常規(guī)用戶帳戶的對(duì)象。

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

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

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

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

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

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

請(qǐng)注意，User用于集群外的人員或應(yīng)用。

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

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

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

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

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

對(duì)于這些應(yīng)用，我們可以定義一個(gè) ServiceAccount (SA)。

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

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

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

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

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

此時(shí)，我們有一種機(jī)制來(lái)確定誰(shuí)可以訪問(wèn)資源。

它可能是一個(gè)人、一個(gè)robot賬戶或一群人。

但是他們?cè)诩褐性L問(wèn)什么資源呢？

對(duì)資源的訪問(wèn)進(jìn)行建模

在Kubernetes中，我們感興趣的是控制對(duì)資源的訪問(wèn)，比如Pod、Services、Endpoints等。

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

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

限制對(duì)這些資源的訪問(wèn)的最佳方法是控制這些 API 端點(diǎn)的請(qǐng)求方式。

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

1、資源的 API 端點(diǎn)。

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

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

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

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

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ù)以下信息，我們可以更簡(jiǎn)化定義上述信息：

· 基本 URL/api/v1/namespaces/對(duì)所有人都是通用的。也許我們可以省略它。

· 我們可以假設(shè)所有資源都在當(dāng)前namespace中并刪除{namespace}路徑。

最終我們可以簡(jiǎn)化為：

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

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

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

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

例如，當(dāng)使用安裝 Cilium CNI 時(shí)，腳本會(huì)創(chuàng)建一個(gè)CiliumEndpoint自定義資源 (CR)：

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

這些對(duì)象存儲(chǔ)在集群中，可通過(guò) 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
$

可以通過(guò) Kubernetes API 類似地訪問(wèn)自定義資源：

/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 并不是一個(gè)好主意。

我們可以通過(guò)稍作更改來(lái)恢復(fù)它。

我們可以在頂部定義它并稍后使用它來(lái)擴(kuò)展資源的 URL。

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

對(duì)于沒(méi)有namespace API的POD之類的資源呢？

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

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

Kubernetes 讀取 API 組并自動(dòng)將它們擴(kuò)展為：

· 如果為空，則將“”轉(zhuǎn)換為/api/v1/xxx。

· 否則為/apis/{apigroup_name}/{apigroup_version}/xxx。

既然我們知道了如何映射資源和權(quán)限，現(xiàn)在終于到了將對(duì)多個(gè)資源的訪問(wèn)組合在一起的時(shí)候了。在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ù)帳戶和組的身份。

· 對(duì)具有角色的資源的權(quán)限。

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

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

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

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

該定義有兩個(gè)重要字段：

· 引用viewer角色的roleRef。

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

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

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

請(qǐng)注意該subjects字段是一個(gè)包含kind，namespace和name的列表。

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

但是namespace了？

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

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

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

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

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

我們還可以將多個(gè)組、用戶或服務(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

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

首先，讓我們介紹一下場(chǎng)景：你有一個(gè)應(yīng)用程序需要訪問(wèn)Cilium暴露的資源。

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

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

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

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

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

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

• 下次應(yīng)用程序向Kubernetes API發(fā)出請(qǐng)求時(shí)，它將被授予訪問(wèn)Cilium資源的權(quán)限。

Namespaces和cluster-wide的資源

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

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

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

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

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

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

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

是的，我們可以添加。

畢竟，在引入 Roles 和 RoleBindings 時(shí)，我們沒(méi)有討論任何namespace的限制。

下面是一個(gè)例子：

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ù)帳戶，大家可能會(huì)意識(shí)到它不起作用。

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

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

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

之前的配置應(yīng)改為：

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

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

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

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

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

讓我們來(lái)看一下。

$ 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:前綴表示資源由集群控制平面直接管理。

此外，所有默認(rèn)的 ClusterRoles 和 ClusterRoleBindings 都標(biāo)有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...

我們可以使用以下命令檢查每個(gè) Role 和 ClusterRole 的詳細(xì)信息：

                                                

                                                本文標(biāo)題：使用RBAC限制對(duì)Kubernetes資源的訪問(wèn)                                                

                                                分享網(wǎng)址：http://m.5511xx.com/article/cddiejd.html