部署在k8s叢集中的應用，有些需要擁有通路k8s API伺服器的權限，比如說擷取目前命名空間下的pod，svc等資源。k8s通過RBAC規則來賦予使用者、pod、組相應的權限。其中pod使用一種稱為service accounts的機制，下面我們來實踐如何為pod中的應用添權重限。
首先需要在命名空間中建立serviceaccount資
yaml詳細内容如下：
接着建立role（角色），role中包含角色所具有的功能，yaml内容如下：
yaml中定義了角色有擷取default命名空間中pods的權限。
然後定義rolebinding（角色綁定），将角色綁定到上面建立的serviceaccount，
yaml檔案内容如下：
建立一個pod進行測試，yaml檔案如下
檔案中serviceaccountname的值為上述綁定了角色的serviceaccount。
serviceaccount關聯了一個configmap，綁定到pod之後，configmap被挂載到pod中，/var/run/secrets/kubernetes.io/serviceaccount/目錄下包含三個檔案，分别是
pod可以通過使用ca.crt和token來通路API伺服器。
進入容器中，使用curl指令來擷取default命名空間下pod，在get請求中帶上ca.crt和token，如下
傳回結果的部分如下：
API伺服器傳回了pod的詳細資訊。
除了pod,svc等屬于某個命名空間的資源外，還可以擷取非命名空間級别的k8s叢集，包括pv等，需要使用到clusterrole（叢集角色）資源，采用clusterrolebinding（叢集角色綁定）将叢集角色綁定到serviceaccount上。
serviceaccount，role和rolebinding必須屬于某個命名空間下。假如A命名空間下的應用想要通路到B命名空間下的資源，可以将A命名空間下的serviceaccount綁定到B命名空間下的role。也可以将A命名空間下的serviceaccount綁定到clusterrole，讓其可以擷取所有命名空間下的資源。
clusterrole還可以允許通路非資源型的URL，如下圖所示：
為了友善使用，k8s提供了一些clusterrole，部分如下圖所示：
使用者可以直接使用k8s提供的叢集角色，從命名中可以看出，這些叢集角色包括pod,pv,pvc,job,namespace等k8s本身提供的資源，可以根據不同的需求選擇不同的叢集角色，還可以将多個角色綁定到一個serviceaccount上。