Kubernetes CKA課程筆記 39

Authorization with Role Based Access Control(RBAC)概論與其它authorization模型

ZONGRU Li

11 min readNov 6, 2021

該篇大綱:

K8s中的認證(Authentication) & 授權(Authorization)如何運作?
如何設定users,groups及他們的許可(permission)
Authorization with Role Based Access Control(RBAC)
K8s元件中哪些定義了cluster的許可(permission)

簡單概念在面對一座K8s Cluster時會有許多不同使用者

有些可能是該座K8s Cluster的Administer

有些可能只是一般開發者

不同使用者該授予使用上的權限許可(permission)理應不同

最直觀的方式是 →Least Privilege Rule(最小特權規則)

首先來談談開發者的權限:

簡單考慮如下切分不同使用者群體給予不同nameSpace權限:

這樣的分法就可稱為Role Based Access Control(RBAC)
這邊要達成上述目標就需要K8s的元件 →Role Component

Role Component:

1.可以定義nameSpace內的許可
2.並且該Role元件是綁定特定nameSpace
3.Role元件定義了在該nameSpace內哪些元件可以進入,例如:
Pod,Deployment,Service,…etc
4.並且定義針對上述元件可執行的操作,例如:
list,get,update,delete,…etc

也就是Role Component定義了Resource及其進入的權限
但Role Component內沒有定義是"誰"拿了這個權限許可,這邊要特別注意!
至於如何連結個人使用者(開發者)
乃或一個team可以持有該Role Component的則是:RoleBinding元件

RoleBinding Component:

該Component簡單地定義了
哪個Role Component賦予給"誰",或給"團隊"
亦即連結"個人"或"團隊"到Role Component

再來談談Administrators的權限:

Admins司掌整個K8s Cluster
通常也掌控全部的nameSpace
並且也管理設置Cluster範圍的空間給予開發者
亦即Admins司掌K8s Cluster範圍的運作!
所以還需要如何控管權限呢?
如Role等Component限制在特定nameSpace已經不夠用了
在前面開發者講述的元件及Role Based Access Control(RBAC)概念下
則還有以下元件來做管理:
1. ClusterRole Component
2. ClusterRoleBinding Component

與前面的Role與RoleBinding很類似,但不是針對nameSpace
而是針對Cluster如下概念圖:

我個人覺得未來混和雲大概就是這樣
有些Admin人員熟AWS並負責上面的K8s Cluster
有些Admin人員熟地端所以掌管地端的K8s Cluster
針對不同Cluster要拆分權限管理

至於Kubernetes如何定義User與Groups來分配其Role或ClusterRole?

→答案是:Kubernetes其實不負責管理User與Groups

但是Kubernetes有提供介面來彈性地提供串接各種作法
亦即Kubernetes其實不存在User與Groups概念或資源
但是Kubernetes依賴外部來源來定義User與Groups概念或資源

外部來源可能為:

1.Static token file:

**Static token file範例(隨便打的token,user,uid)**

2. 憑證(Certificates):

可能是由Kubernetes簽發

3.第三方身分identity服務像是LDAP

所以通常K8s Admins會在K8s Cluster設定上述這些外部來源
好讓K8s可以順利取的User與Groups的資訊
接著最初架構有提到的API Server會透過上述的外部來源
API Server管理準備拋給K8s Cluster的請求
並認證(Authentication)請求發動者的權限
傳遞這類請求連帶著身分資訊的語法
1.以Static token file指令option如下:

--token-auth-file=/user.csv

kube-apiserver --token-auth-file=/users.csv [other options]

所以API server知道去哪裡驗證該資訊
更進階地若要定義Group的話,Static token file可以如下:

2. 以憑證(Certificates)來驗證
通常都是Admin建立發配憑證供Users使用
3. Admin設置LDAP當作authentication(認證)源供API server使用
由上述說明可以再次清楚知道
K8s允許透過外部資源來做authentication(認證)
但是K8s本身不管理這類資源

經以上解說,人員部分不管是個人還是團隊

亦或開發者或Admins都透過上述機制與K8s元件管理authentication(認證)

但是對於Application或說Application Users而言呢?

Application也需要權限進入操作K8s Cluster資源:

Application可以是Cluster內部的App或是Cluster外部的App

常見的Cluster內部App:

例如Monitoring App : Prometheus
Prometheus需要進入其他Cluster中的其他App去蒐集Metrics資訊
其他也可能是Cluster內微服務App,需進入特定nameSpace的Resource

常見的Cluster外部App:

如CI/CD工具的Jenkins,在佈署App到Cluster也會需要認證
又或像Terraform App提供工具來設置Cluster本身

一樣在Least Privilege Rule(最小特權規則)下,僅提供必要的權限給上述App

而對於上述的App User,K8s提供了ServiceAccount Component

來做定義App User

ServiceAccount Component:

kubectl create serviceaccount {名稱如sa1}
於K8s Cluster內部建立ServiceAccount來定義內部或外部App
並且ServiceAccount透過前面提過的元件來連結Role/ClusterRole如:
ServiceAccount透過RoleBinding連結到Role Component 亦可
ServiceAccount透過ClusterRoleBinding連結到ClusterRole Component

**Link ServiceAccount to Role with RoleBinding**

**Link ServiceAccount to ClusterRole with ClusterRoleBinding**

以下實際上述元件的實際範例Configuration File逐一介紹:

"Role" Configuration File:

定義什麼資源(Resources)對應可以有什麼樣權限

上圖中的namespace若沒填,預設就是default nameSpace
當然也能指向其他特定nameSpace
API group解說

另一種寫法:

“RoleBinding” Configuration File:

“ClusterRole” Configuration File:

定義到cluster範圍內的namespace權限(因為namespace是cluster範圍的resource)

定義Cluster範圍的resources(pods,services,deployments)權限,或是
定義到nameSpace範圍的resources權限(但不再限定哪一個nameSpace)

定義到nameSpace範圍內的權限,但此處是指整個cluster內”**全部nameSpace**”裡的resource

“ClusterRoleBinding” Configuration File:

建立/查看上述RBAC resources:

簡單方法如下指令,透過如上述Configuration File建立:

kubectl apply -f {上述各種yaml檔}

而查看到的指令範例如下(roles可以換成別的元件種類):

kubectl get roles

kubectl describe role developer

確認API(Access)執行權限:

K8s提供快速確認的subcommand來查看有無執行reources操作權限:
"auth can-i" 如下範例:

kubectl auth can-i create deployments --namespace dev

若身為Admin也能透過如上指令查看別人的權限:

Layers of Security:

如下範例,Jenkins發動請求給Cluster的API server運作過程:

第一步:

API Server確認Jenkins User是”認證Authentication”的系統使用者
並確認該Jenkins允許連接到該Cluster
可以同時建立多種認證(Authentication),像是
User name/password,或憑證等等方式

第二步:

透過各種”授權(Authorization)”模型例如前述RBAC
用RBAC:Role,ClusterRole,及各式Binding並確認

以上就是Kubernetes使用RBAC模型及其元件來管理各種使用者權限

其它Kubernetes Authorization Model

Kubernete支援Authorization的Model:

Node
ABAC
RBAC
Webhook

可在Kubernetes官網中看到解說:

並支援同時使用不同的Model
但至於該去哪邊啟用? 詳下API Server設定!

在路徑:/etc/kubernetes/manifests/kube-apiserver.yaml

如上看起來預設啟動的是Node,RBAC model

當然當遇到某個K8s Cluster沒有啟用RBAC,現在就知道該去哪邊啟用了!

參考課程(reference)