Kubernetes 權限控制概覽

伴隨着Kubernetes的迅猛發展，depolying、scaling和managing containeried applications等概念在開發、運維管理等相關工做人員間普遍流傳。不管技術概念多麼的新穎，一項工程技術在大規模應用實踐生產環境前，首先須要考量安全問題。所以生產環境安所有署的相關問題也是kubernetes最重要的內容之一。Kubernetes對用戶和應用請求認證和受權管理的底層邏輯也是相關工做人員最應該掌握的硬核知識。

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

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

下面的示例都是運行在最新版的Kubernetes集羣中，固然你也可使用運行在本地的Minikube做爲實驗環境

API Server - Kubernetes的網關

Kubernetes一切資源(Nodes,Labels,Pods,Deployments,Services,Secrets,Configmaps,Ingress等)都是對象，Kubernetes經過API Service控制着這些資源的訪問權限。經過使用暴露給外部用戶REST API接口執行對Kubernetes資源的CRUD操做。

API Server是Kubernetes內部的核心模塊之一，扮演者集羣網關的角色。Kubernetes內部模塊(諸如：Kubelet, Scheduler, Controller) 都是經過API Service進行調度和調諧。分佈式鍵值對數據庫（etcd）也只能經過API Server訪問。

Kubectl素有集羣管理的瑞士軍刀之稱，它操做Kubernetes的全部請求最終都會發送到Api Server。其它相似的工具或者模塊也是經過API Server操做Kubernetes的資源對象。

在Kubernetes對象被操做前，Kubernetes集羣使用API Server驗證請求的合法性。發送請求的客戶端使用X.509認證對發出的請求進行加密，加密使用X.509認證的CA certificate和client certificate都是Kubectl從本地獲取的。

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: DATA+OMITTED
    server: https://35.203.146.149:6443
  name: kubernetes-the-hard-way
contexts:
- context:
    cluster: kubernetes-the-hard-way
    user: admin
  name: kubernetes-the-hard-way
current-context: kubernetes-the-hard-way
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate: /Volumes/BOOTCAMP/dev/gcp/gcloud-k8s-config/script/admin.pem
    client-key: /Volumes/BOOTCAMP/dev/gcp/gcloud-k8s-config/script/admin-key.pem
複製代碼

ca.pem(介於安全考量，我並未配置在Kubectl Config中)本地認證中心須要一個CA證書。 顯而易見，Kubectl正是經過上下文配置中的certificates和keys加密請求。

咱們可否經過curl命令向API Server發送請求嗎？固然能夠了！

除了須要相關的CA加密文件，咱們也要將token按照base64編碼後嵌入到請求體的header中。

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

export CLUSTER_NAME="kubernetes-the-hard-way"
複製代碼

APISERVER=$(kubectl config view -o jsonpath="{.clusters[?(@.name==\"$CLUSTER_NAME\")].cluster.server}")
複製代碼

下面的命令將獲取default service account中的token：

TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-account\.name']=='default')].data.token}"|base64 -D)
複製代碼

如今咱們可使用curl命令請求api server：

curl -X GET \
	--cacert /Volumes/BOOTCAMP/dev/gcp/gcloud-k8s-config/script/ca.pem \
	--header "Authorization: Bearer $TOKEN" \
	$APISERVER/version
複製代碼

Kubernetes權限控制的三層模型

像上面所說的那樣，全部的外部用戶或者pods在操做Kubernetes內部對象前都須要對API Server進行認證。

當一個合法的請求到達API Server後，系統將會經過三層認證驗證對請求的資源是否有操做權限。

1. Authentication

在請求被TLS認證後，API Server將使用Kubernetes中已經開啓的一個或多個認證模塊對它進行相關的認證操做。相關的認證模塊在集羣建立時就已經指定，多個認證模塊會被放在隊列中，只有上一個認證模塊成功認證後，纔會被下一個模塊進行認證。

Kubernetes中的認證模塊主要有client certificates、password、plain tokens、bootstrap tookens和JWT tokens。Clinet certifiactes是集羣中默認也是最多見的認證模塊。關於認證模塊的更多內容，你能夠參照相關模塊文檔。

Kubernetes並未維護專門的用戶表或者認證用戶的畫像，而是經過認證X.509認證文件或者傳遞給認證模塊的token。理解這一點後就能夠很容易明白Kubernetes經過將OpenID,Github甚至LDAP協議集成到Kubernetes認證體系的原理。

2.Authorization

一旦API請求被認證後，下一步將會驗證請求是否被受權操做Kubernetes內部資源，這一行爲發生在請求驗證流程中的第二步。

在受權驗證時，Kubernetes將主要考查請求的用戶名、請求的行爲和請求將會影響的對象。用戶名是從請求的header中提取的，請求行爲是對應CRUD操做中的Http行爲（GET，PUT，DELETE等），請求將會影響的對象是Kubernetes內部的Pods，Service等。

Kubernetes對資源對象的受權策略遵循由關到開的哲學，這就意味着若是想要訪問資源必須配置相關的受權策略。

像認證同樣，受權的行爲也能夠經過一個或多個受權模塊配置權限，諸如ABAC，RBAC和Webhook中。在管理員建立集羣時就已經將相應的受權模塊集成到Kubernetes API Server中了。若是Kubernetes集羣啓用了多個受權模塊，API Server會逐一使用受權模塊對請求進行驗證。只有全部的模塊驗證經過後，請求才能經過受權的驗證，不然請求將會被拒絕（Http的status code是403）。關於受權模塊的更多內容，你能夠參照相關模塊文檔。

3.Admission Control

請求經過認證和受權後最後來到准入控制，像認證和受權同樣，准入控制器也是插件式模塊。

與認證和受權不一樣的是准入控制可能會修改請求資源對象。除了讀取資源對象，准入控制能夠對建立、刪除、更新和代理資源對象的請求發生了做用。例如准入控制攔截建立存儲數據卷（PVC）請求，指定PVC資源的存儲類型。還能夠在建立Pod時強制從新拉取鏡像。關於更多准入控制模塊，參照Kubernetes文檔。

在准入控制器處理的過程當中，請求一旦被任何一個控制器拒絕，請求馬上就會被Kubernetes拒絕。只有請求順利經過全部的准入控制器後，請求才具有操做相應資源對象的權限。

在下一篇文章中，我將會進一步講解如何建立用戶和認證用戶，加油吧小夥伴！

文章翻譯自A Primer on Kubernetes Access Control，行文時略有刪減