RBAC是什么？

RBAC模型（Role-Based Access Control：基于角色的訪問控制）模型是比較早期提出的權(quán)限實現(xiàn)模型，在多用戶計算機時期該思想即被提出，其中以美國George Mason大學(xué)信息安全技術(shù)實驗室（LIST）提出的RBAC96模型最具有代表，并得到了普遍的公認(rèn)。

RBAC認(rèn)為權(quán)限授權(quán)的過程可以抽象地概括為：Who是否可以對What進行How的訪問操作，并對這個邏輯表達式進行判斷是否為True的求解過程，也即是將權(quán)限問題轉(zhuǎn)換為Who、What、How的問題，Who、What、How構(gòu)成了訪問權(quán)限三元組，具體的理論可以參考RBAC96。

在RBAC模型里面，有3個基礎(chǔ)組成部分，分別是：用戶、角色和權(quán)限，它們之間的關(guān)系如下圖所示：

User（用戶）：每個用戶都有唯一的UID識別，并被授予不同的角色

Role（角色）：不同角色具有不同的權(quán)限

Permission（權(quán)限）：訪問權(quán)限

用戶-角色映射：用戶和角色之間的映射關(guān)系

角色-權(quán)限映射：角色和權(quán)限之間的映射

例如下圖，管理員和普通用戶被授予不同的權(quán)限，普通用戶只能去修改和查看個人信息，而不能創(chuàng)建用戶和凍結(jié)用戶，而管理員由于被授予所有權(quán)限，所以可以做所有操作。

Kubernates集群中的所有資源的訪問和變更都是通過Kubernates API Server的 REST API來實現(xiàn)的，所以集群安全的關(guān)鍵點就在于如何識別并認(rèn)證客戶端身份，以及隨后訪問權(quán)限的授權(quán)這兩個關(guān)鍵問題。Kubernates安全機制里面設(shè)計了三道關(guān)卡，得通過三關(guān)客戶端的調(diào)用請求才能夠得到API Server的真正響應(yīng)：

1. 認(rèn)證

2. 鑒權(quán)

3. 準(zhǔn)入控制（Admission Control）

API Server認(rèn)證方式有三種：

1. HTTPS證書認(rèn)證：基于CA根證書簽名的雙向數(shù)字證書認(rèn)證方式

2. HTTP Token認(rèn)證：通過一個Token來識別合法用戶

3. HTTP Base認(rèn)證：通過用戶名+密碼的方式認(rèn)證

API Server目前支持以下6種授權(quán)策略：

1. AlwaysDeny

2. AlwaysAllow

3. ABAC: 基于屬性的訪問控制

4. Webhook:通過調(diào)用外部REST服務(wù)對用戶進行授權(quán)

5. RBAC:基于角色的訪問控制

6. Node: 是一種專用模式，用于對kubelet發(fā)出的請求進行訪問控制

RBAC工作原因HOW？

RBAC作為kubeadm安裝方式的默認(rèn)選項，足見其重要程度。

1. RBAC的資源對象

????1. 1Role?

? 一個角色就是一組權(quán)限的集合。角色（Role）只能對命名空間內(nèi)的資源進行授權(quán)，例如：

? apiGroups:支持的API組列表

? resources: 支持的資源對象列表，例如pods、deployments、jobs等

? verbs：對資源對象的操作方法列表，例如get、watch、list、delete、replace、patch等

2. ClusterRole

? 集群角色除了具有和角色一致的命名空間內(nèi)資源的管理能力，因其集群級別的范圍，還可以用于這些特殊元素的授權(quán)：

? 集群范圍的資源，例如Node

? 非資源型的路徑，/healthz

? 包含全部命名空間的資源，例如pods, --all-namespace

3. RoleBinding & ClusterRoleBinding

? 角色綁定或集群角色綁定用來把一個角色綁定到一個目標(biāo)上，綁定目標(biāo)可以是User,Group,或者Service Account。使用RoleBinding 為某個命名空間授權(quán)，使用ClusterRoleBinding為集群范圍內(nèi)授權(quán).

2. 對資源的引用方式

有兩種resources和ResourceNames. 可以像以上例子一樣配置resources為一個數(shù)組, 以此來授權(quán)讓某個主體同時能夠讀取pod和pod log：

在指定resourceNames以后，使用get,delete等操作請求，就會被限制在這個資源實例范圍內(nèi)。例如，下面的聲明讓一個主體只能對一個configmap進行g(shù)et和update操作：

API Server在接受到請求以后，會讀取該請求的數(shù)據(jù)，生成一個訪問策略對象。然后將這個訪問策略對象和授權(quán)策略文件中的所有訪問策略對象逐條匹配，如果至少有一個策略對象被匹配，則該請求被鑒權(quán)通過，否則終止API調(diào)用流程，并返回客戶端的錯誤調(diào)用碼。

示例

1. 使用RBAC授權(quán)模式，需要在API Server的啟動參數(shù)中加上 --authorization-mode = RBAC

2. 常見的角色綁定示例

首先聲明角色pod-reader：

聲明RoleBinding:

通過kubectl apply -f 上面的yaml文件，可以完成jane is pod-reader的角色綁定，pod-reader只能對該命名空間范圍內(nèi)的pods做操作get, watch, list.

總結(jié)：

本文首先介紹了RBAC的基本概念，RBAC的工作原理，最后演示了如何進行角色綁定。

reference:

(1)https://segmentfault.com/a/1190000023179921

(2)https://blog.51cto.com/billy98/2380061?