• RBAC (Role-based access control) 在 wiki 中的定義為以角色為基礎的存取控制模型。簡單來說 RBAC 有三個重要的元素如下 :

1. Resource : 資源，可供角色操作的對象。
2. Role : 角色，定義可以存取哪些資源，並且針對該資源有哪些存取行為(ex: 讀寫執行)
3. User : 使用者，因為角色決定操控的資源，所以後面只需決定將使用者綁定到哪個腳色上即可

• K8s 支援使用 RBAC 的方式給予使用者權限，相關資料可以參考Limiting access to Kubernetes resources with RBAC。

• 所以簡單來說，我們必須先釐清這三者在 K8s 中實際存在的樣子，以及如何針對使用者去對角色作綁定。那我們就先以已經操作已久的 system:master 為起點，來看看它的綁定了那些權限。

# kubectl auth can-i [執行動作]
kubectl auth can-i create pods ;

# 列出目前帳號可以操作的資源列表及動作
kubectl auth can-i --list ;

• 透過 kubectl auth can-i --list 可以發現 system:master 的權限充滿著一堆 * ，看來權限應該是蠻大的。大概有個概念後，我們先從RBAC 最簡單的使用者開始建立起。

• 在 K8s 中的使用者分為兩種，一般使用者和服務帳號，這次主要會專注在服務帳號的利用上。服務帳號顧名思義就是給服務使用的。但是服務帳號的權限又該如何決定呢? 這個就是本章要介紹的重點。在 K8s 中服務帳號的類型就叫做 service account。建立方式很簡單如下所示 :

kubectl create serviceaccount aeifkz ;
kubectl get serviceaccount ;

• 但新建立的帳號能夠幹嘛呢? 這樣要先利用 kubectl auth 加入 --as=system:serviceaccount:[namespace]:[serviceaccountname] 參數暫時切換到某個身分去執行，指令如下 :

kubectl auth can-i create pods --as=system:serviceaccount:default:aeifkz -n default ;
kubectl auth can-i create pods --as=system:serviceaccount:default:aeifkz -n kube-system ;

kubectl auth can-i --list --as=system:serviceaccount:default:aeifkz -n default ;
kubectl auth can-i --list --as=system:serviceaccount:default:aeifkz -n kube-system ;

• 可以看的出來一些權限都只剩下 get 而已，然後連 pod 想建立都無法建立了。接著可以試著練習建立 Role 並予建立 Pod 的權限，然後綁定到使用者身上，參考如下 :

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  namespace: default
  name: role-simple
rules:
  - apiGroups: [""]
    # at the HTTP level, the name of the resource for accessing Secret
    # objects is "secrets"
    resources: ["pods"]
    verbs: [ "get", "watch", "list", "create", "delete" ]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: cluster-role-binding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: role-simple
subjects:
  - kind: ServiceAccount
    name: aeifkz
    namespace: default

• 先來看看有哪些資源以及行為可以被使用，可以參考資料 Resource types、Determine the Request Verb。

• 針對 pod 可以進行的動作類型有 "create", "get", "watch", "list", "update", "patch", "delete"，意思分別如下 :

  • create : 建立 pod
  • get : 抓取單一 pod 的內容，但無法列舉所有資源清單
  • watch : 觀看單一 pod 被及時更新的內容
  • list : 列出該資源的所有清單內容，但無法針對單一 pod 做內容讀取
  • update : 就是更新
  • patch : 更新線上 pod 的狀態
  • delete : 刪除 pod

# 參數 -o wide 代表顯示詳細資訊，會顯示資源以及該資源可以操作的動作
kubectl api-resources -o wide ;

• 這時候會看到一大堆資源以及該資源可以進行的動作，先從熟悉的 pod 開始切入，看看它有哪些可以執行的動作。

kubectl api-resources -o wide | grep pods ;

• 重新測試一下目前帳號的權限，指令如下 :

kubectl auth can-i create pods --as=system:serviceaccount:default:aeifkz -n default ;
kubectl auth can-i create pods --as=system:serviceaccount:default:aeifkz -n kube-system ;

kubectl auth can-i --list --as=system:serviceaccount:default:aeifkz -n default ;
kubectl auth can-i --list --as=system:serviceaccount:default:aeifkz -n kube-system ;

• 那有了 service account 要怎麼使用呢? 這時候可以把它掛載到某個 Pod 底下，如下所示。然後進到 Pod 中下載 kubectl，它就會自行套用相關的設定進來。

apiVersion: v1
kind: Pod
metadata:
  name: target-pod
spec:
  containers:
  - name: target-pod
    image: aeifkz/my-ubuntu:v1.0
  serviceAccount: aeifkz

kubectl exec -it target-pod -- bash ;
curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl" && chmod +x kubectl ;

#看一下目前的權限有多少
./kubectl auth can-i --list ;

#測試是否具有建立 Pod 的權限
./kubectl auth can-i create pods ;

#直接建立一個 new-pod
./kubectl run new-pod --image aeifkz/my-ubuntu:v1.0 ; 
./kubectl delete pods new-pod ;

• 今日總結 :

  • 本日回顧 :

    • 今天的重點在於介紹了 K8s 的 RBAC授權機制，介紹了 role、user、binding 三個腳色以及做法。並且透過新的指令 kubectl auth 結合不同參數進行一些觀察，像是 can-i 判斷是否可以執行、 --list 列出可使用的資源跟執行權限、 --as 切換成不同身分。最後建立了一個 pod 掛載 service account token，並且示範了該如何利用這個 token 做事情。

  • 次日預告 :

    • 快速帶過 RBAC 基本知識之下明天就要開始濫用 RBAC 的機制，這部分會分為兩類，第一類是給予過大的權限導致可以執行，第二類則是給予特殊的權限導致可以提權。原則上搞懂之後就不會太難。