權限控制：探索Kubernetes的Service Accounts

這一系列文檔都是關於Kubernetes集羣內部pods等資源對外部請求的認證與受權的管以及如何使用roles和role binding控制Kubernetes內部資源的訪問權限。

• Kubernetes 權限控制概覽
• 權限控制-經過實例理解Kubernetes的認證
• 權限控制-經過實例理解Kubernetes的受權
• 權限控制-探索Kubernetes的Service Accounts

Kubernetes使用Users和Service Account進行權限控制的相關工做,User 經過密鑰和證書對Kuberntes API的訪問進行認證，任何來自集羣外的訪問都須要被Kubernetes認證。一般使用X.509生成的證書對請求進行認證，你能夠參照前面的文章經過實例理解Kubernetes的認證理解如何建立用戶以及對用戶進行相關認證。

首先咱們要再次重申Kubernetes沒有經過數據庫或者其餘介質存儲用戶名和密碼。相反，Kubenetes更但願對用戶的管理能夠由集羣的外的程序來管理。藉助Kubernetes的認證模塊，能夠將Kubernetes的認證我委託給第三方代理（如OpenID和Active Directory）。

X.509證書用於對Kubernetes外部請求的認證，Service accounts用於對集羣內部請求的認證。Service Accounts與Pods相關，主要用於對集羣內部API Server訪問請求的認證。

在Kubernetes集羣中，每個運行的Pods都有一個叫default的默認用戶。同時，爲了使Pods能夠訪問內部的API Server端點，集羣中有一個叫作Kubernetes的ClusterIP Server。

kubectl get serviceaccounts
複製代碼

kubectl get svc
複製代碼

爲了更好的闡釋相關內容，接下來我將經過Busybox鏡像啓動一個Pod，在Pod中使用curl命令作相關操做。

1. 使用Busybox鏡像啓動Pod

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl
複製代碼

在Busybox的shell命令行中，咱們嘗試使用curl命令鏈接API Server端點。

curl https://kubernetes:8443/api
複製代碼

因爲在請求中缺乏相關的token，所以上面的請求並無任何返回，接下來我將嘗試獲取token，並將token嵌入到請求的header中。

2. 獲取token

咱們已經已經講過，token是經過secret的形式嵌入到Pod中。進入文件夾 /var/run/secrets/kubernetes.io/serviceaccount 後便可發現token。

cd /var/run/secrets/kubernetes.io/serviceaccount
複製代碼

爲了更方便的curl命令，接下來我將設置一些環境變量：

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
複製代碼

獲取Kubectl API Service的url:

kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{end}'
複製代碼

下面的命令將會獲取default namespace下全部的serices，咱們一塊兒看看api service的返回結果。

curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://35.203.146.149:6443/api/v1/namespaces/$NAMESPACE/services/"
複製代碼

驚奇的發現default service account競然沒有獲取相同namespace下services的權限。

在這裏咱們還要重申下Kubernetes遵循由關到開的準則，這就意味着默認的user或者service account並不具有任何權限。

3. 對service account進行受權

爲了完成請求，咱們須要經過role binding將相關的role綁定到default service account。這個過程與經過role binding將具備list pod權限的role綁定到Bob上的例子很像。

退出pod，執行下面的命令建立role後並將role綁定到default service account上。

kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=default:default \
  --namespace=default
複製代碼

若是你對集羣中的cluster role好奇，執行下面的命令:

kubectl get clusterroles
複製代碼

4. 再次驗證

再次啓動運行BusyBox鏡像的Pod後請求API Server

kubectl run -i --tty --rm curl-tns --image=radial/busyboxplus:curl
複製代碼

爲了更方便的curl命令，接下來我將設置一些環境變量：

CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
複製代碼

獲取Kubectl API Service的url:

kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.cluster.server}{"\n"}{"end"}'
複製代碼

下面的命令將會獲取default namespace下全部的serices，咱們一塊兒看看api service的返回結果。

curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://35.203.146.149:6443/api/v1/namespaces/$NAMESPACE/services/"
複製代碼

你也能夠自定義一些role經過RBAC受權default service account更多的操做。

到此咱們這一關於Kubernetes權限控制的系列文章已經結束了，咱們前後討論如何認證，受權以及service accounts對控制用戶操做Kubernetes操做API Server的權限。

文章翻譯自Kubernetes Access Control: Exploring Service Accounts，行文時略有刪減