RBAC
===
###### tags: `RoleBinding` `ClusterRoleBinding`
# 簡介
* 是資訊安全領域中，一種較新且廣為使用的存取控制機制，其不同於強制存取控制以及自由選定存取控制直接賦予使用者權限，而是將權限賦予角色。
* RBAC基於角色的權限訪問控制（Role-Based Access Control）是商業系統中最常見的權限管理技術之一。RBAC是一種思想，任何編程語言都可以實現，其成熟簡單的控制思想越來越受廣大開發人員喜歡。在RBAC中，權限與角色相關聯，用戶通過成為適當角色的成員而得到這些角色的權限。這就極大地簡化了權限的管理。在一個組織中，角色是為了完成各種工作而創造，用戶則依據它的責任和資格來被指派相應的角色，用戶可以很容易地從一個角色被指派到另一個角色。角色可依新的需求和系統的合併而賦予新的權限，而權限也可根據需要而從某角色中回收。
* 以角色為基礎的存取控制模型是一套較強制存取控制以及自由選定存取控制更為中性且更具靈活性的存取控制技術。
# 定義
* 在一個組織中，會因為不同的作業功能產生不同的角色，執行某項操作的權限會被賦予特定的角色。組織成員或者工作人員（抑或其它系統用戶）則被賦予不同的角色，這些用戶通過被賦予角色來取得執行某項計算機系統功能的權限。
* S = 主體 = 一名使用者或自動代理人
* R = 角色 = 被定義為一個授權等級的工作職位或職稱
* P = 權限 = 一種存取資源的方式
* SE = 會期 = S，R或P之間的映射關係
* SA = 主體指派
* PA = 權限指派
* RH = 角色階層。能被表示為：≥（x ≥ y 代表 x 繼承 y 的權限）
* 一個主體可對應多個角色。
* 一個角色可對應多個主體。
* 一個角色可擁有多個權限。
* 一種權限可被分配給許多個角色。
* 一個角色可以有專屬於自己的權限。
# 理解kubernetes的角色控制
* kubernetes容器內部通訊都需要通過api-server進行通訊。通過外部kubectl訪問管理集群，本質上也是訪問api-server，api-server就是整個集群的指揮中樞。
* 但是人在江湖漂，哪能不挨刀呢？要怎麼防止集群內外瞎搞事的破壞分子呢？RBAC（基於角色的訪問控制）順勢而生。
* 一句話總結<b>ServiceAccount</b>，<b>Role</b>，<b>RoleBinding</b>，<b>ClusterRole</b>，<b>ClusterRoleBinding</b>的關係就是:
* <b>ClusterRoleBinding</b>，<b>RoleBinding</b>是一種任命，認命被授權的對象（用戶，組或服務帳戶）能夠有什麼樣的權限（<b>Role</b>，<b>ClusterRole</b>）
## ServiceAccount
```yaml=
apiVersion: v1
kind: ServiceAccount
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"flannel","namespace":"kube-system"}}
creationTimestamp: 2018-07-24T06:44:45Z
name: flannel
namespace: kube-system
resourceVersion: "382"
selfLink: /api/v1/namespaces/kube-system/serviceaccounts/flannel
uid: 0d4064e6-8f0d-11e8-b4b4-00163e08cd06
secrets:
- name: flannel-token-f7d4d
```
* 上面說了，ServiceAccount只是一個虛名，本身沒有任何的權限說明。
## 服務帳戶令牌
* service-account-token的API類型是<b>kubernetes.io/service-account-token</b>
* 變動<b>ServiceAccount</b>時，令牌控制器（控制器的管理器的一部分）會自動維護<b>service-account-token</b>，根據實際情況增加/修改/刪除，<b>service-account-token</b>的本質類型是<b>secret</b>。所以<b>service-account-token</b>是1對1跟<b>ServiceAccount</b>隨生隨死的。
* 而定義的資源如果指定了<b>ServiceAccount</b>，<b>Admission Controllers</b>（api-server的一部分）就會把這個<b>ServiceAccount</b>相應的<b>service-account-token</b>以文件的形式掛載到容器內部的<b>/var/run/secrets/kubernetes.io/serviceaccount</b>目錄下。
* 該目錄一般會有3個文件
* ca.crt
* 命名空間
* 代幣
* 參考鏈接：
* [管理服務帳戶](https://kubernetes.io/zh/docs/admin/service-accounts-admin/)
* [配置Pod的服務帳戶](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
## 角色
```yaml=
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
```
* 角色只能用於授予對單個命名空間中的資源訪問權限
* 定義了具體的網址
## RoleBinding
```yaml=
# This role binding allows "jane" to read pods in the "default" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
```
* RoleBinding適用於某個命名空間內授權，RoloBinding可以將角色中定義的權限授予用戶或用戶組
# ClusterRole
```yaml=
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
```
* 集群級別的資源控制（例如節點訪問權限）
* 非資源型endpoints（例如/ healthz訪問）
* 所有命名空間資源控制（例如pods）
# ClusterRoleBinding
```yaml=
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
```
```yaml=
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: prometheus-operator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: prometheus-operator
subjects:
- kind: ServiceAccount
name: prometheus-operator
namespace: monitoring
```
* ClusterRoleBinding適用於集群範圍內的授權。
* 最後用一個表格整理一下
|資源類型 | 說明 |
| ------------- |:-------------|
| ServiceAccount|一個虛名 |
| 服務帳戶令牌 | ServiceAccount的身份象徵|
| 角色 | 授予對單個命名空間中的資源訪問權限|
|RoleBinding|將賦予被授權對象和角色|
|ClusterRole|可視為角色的超集，是從集群角度做的一種授權|
|ClusterRoleBinding|將賦予被授權對象和ClusterRole|
* 理解kubernetesRBAC的最簡單辦法，就是進入KUBE系統內部，看看各類集群資源是怎麼定義的。
## reference
* [Kubernetes TLS bootstrapping 那点事](https://mritd.me/2018/01/07/kubernetes-tls-bootstrapping-note/)
* [使用 RBAC 控制 kubectl 权限](https://mritd.me/2018/03/20/use-rbac-to-control-kubectl-permissions/)
* [Kubernetes RBAC](https://mritd.me/2017/07/17/kubernetes-rbac-chinese-translation/)
*