Kubernetes中的RBAC

Kubernetes中，受權有ABAC（基於屬性的訪問控制）、RBAC（基於角色的訪問控制）、Webhook、Node、AlwaysDeny（一直拒絕）和AlwaysAllow（一直容許）這6種模式。須要在kube-apiserver設置–authorization-mode=RBAC參數，啓用RABC模式，下面的操做版本爲v1.10.1；
　　當應用沒有指定serviceAccountName，它將使用default服務賬戶。

　　在RABC API中，經過以下的步驟進行受權：
　　1）定義角色：定義角色時會指定此角色對於資源的訪問控制的規則；
　　2）定義主體：用戶、組和服務賬戶
　　3）綁定角色：將主體與角色進行綁定，對主體進行訪問受權。

　　　　　　　　　　　　　　　　　　　　RBAC API中的對象關係圖

　　Kubernetes中角色包含表明權限集合的規則，權限只有被授予，沒有被拒絕的設置。
　　在Kubernetes中有兩類角色：普通角色和集羣角色。
能夠經過Role定義在一個命名空間中的角色，或是使用ClusterRole定義集羣範圍的角色。

普通角色只能被授予訪問單一命令空間中的資源。
集羣角色(ClusterRole)可以被授予資源權限有：集羣範圍資源（Node、NameSpace）、非資源端點（/healthz）、集羣全部命名空間資源（跨名稱空間）；

角色綁定和集羣角色綁定
　　角色綁定用於將角色與一個主體進行綁定，從而實現將對主體受權的目的，主體分爲用戶、組和服務賬戶。
角色綁定分爲：普通角色綁定和集羣角色綁定

角色綁定中不一樣主體定義有：
名稱爲 demo 用戶：

subjects:
 - kind:User
   name:"demo"
   apiGroup:rbac.authorization.k8s.io

名稱爲 demo 組：

subjects:
 - kind:Group
   name:"demo-group"
   apiGroup:rbac.authorization.k8s.io

kube-system命名空間中，名稱爲default的服務賬戶

subjects:
 - kind:ServiceAccount
   name:default
   namespace:kube-system

so命名空間中，全部的服務賬戶：

subjects:
 - kind:Group
   name:system:serviceaccounts:so
   apiGroup:rbac.authorization.k8s.io

全部的服務賬戶：

subjects:
 - kind:Group
   name:system:serviceaccounts
   apiGroup:rbac.authorization.k8s.io

全部用戶:

subjects:
 - kind:Group
   name:system:authenticated    #受權用戶
   apiGroup:rbac.authorization.k8s.io
 - kind:Group
   name:system:unauthenticated  #未受權用戶
   apiGroup:rbac.authorization.k8s.io

授予cluster-admin集羣角色給admin用戶：

kubectl create clusterrolebinding admin-cluster-admin-binding --clusterrole=cluster-admin --user=admin

授予cluster-admin集羣角色給so名稱空間中的app服務賬戶：

kubectl create clusterrolebinding app-admin-binding --clusterrole=cluster-admin --serviceaccount=so:app

　　RBAC實例demo下面建立solinx-service-account.yml文件包含如下內容：

# 服務帳號
 apiVersion: v1
 kind: ServiceAccount   
 metadata:
   name: solinx
 # 角色
 ---
 kind: Role
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
   name: solinx
 rules:                #規則
 - apiGroups: [""]       # 全部核心api
   resources: ["pods"]   # 資源
   verbs: ["create","delete","get","list","patch","update","watch"]  #操做
 - apiGroups: [""]
   resources: ["namespaces"]
   verbs: ["create","delete","get","list","patch","update","watch"]
 # 角色綁定
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: RoleBinding
 metadata:
   name: solinx
 roleRef:     # 上面定義的角色
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: solinx
 subjects:   # 上面定義的服務帳戶
 - kind: ServiceAccount
   name: solinx
   namespace: default

　　上面定義了一個服務帳戶solinx、普通角色solinx，並將該服務帳戶與角色進行綁定，該角色定義了對了pod的增刪查改等操做，因此該服務帳戶也具有了該權限；
　　這裏使用solinx服務帳戶對資源進行操做：

kubectl get po --as system:serviceaccount:default:solinx

因爲只授予了pod的操做權限，當訪問service資源時被拒絕：

kubectl get svc --as system:serviceaccount:default:solinx

 Error from server (Forbidden): services is forbidden: User "system:serviceaccount:default:solinx" cannot list services in the namespace "default"

該角色爲普通角色Role，當訪問集羣資源NameSpace時一樣被拒絕：

kubectl get ns --as system:serviceaccount:default:solinx

 Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount:default:solinx" cannot list namespaces at the cluster scope

　　此時把角色改成集羣角色：ClusterRole，並從新綁定服務帳戶：

　　此時該服務帳戶已經具有集羣角色權限，訪問集羣資源：NameSpace

kubectl get ns --as system:serviceaccount:default:solinx

參考資料：
https://kubernetes.io/docs/reference/access-authn-authz/rbac/

文章首發地址：Solinx
http://www.solinx.co/archives/1233