Kubernetes身份認證和受權操做全攻略：K8s 訪問控制入門

隨着Kubernetes被普遍使用，成爲業界公認的容器編排管理的標準框架，許多開發人員以及管理員對部署、彈性伸縮以及管理容器化應用程序等Kubernetes的關鍵概念都十分熟悉。而對於生產部署而言，Kubernetes的安全性相當重要。所以，瞭解平臺如何管理用戶和應用程序的身份認證和受權十分必要。

咱們將推出一系列文章，以一種實踐性的視角來了解平臺內部的Kubernetes和Pod外部用戶的身份認證和受權。我也會解釋如何使用角色以及角色綁定來容許或限制資源訪問。

API Server——Kubernetes網關

API爲Kubernetes各種資源對象（如節點、標籤、Pod、服務、部署、secrets、configmaps以及ingress等）提供訪問接口。這些資源對象經過簡單的REST API執行基本的CRUD（增刪改查）操做。

Kubernetes的核心構建塊之一是API Server，它做爲Kubernetes的網關，是訪問和管理資源對象的惟一入口。內部組件（如kubelet、調度程序和控制器）經過API Server訪問API以進行編排和協調。分佈式鍵/值數據庫、etcd只能經過API Server訪問。

一般咱們能夠經過命令行工具kubectl來與API Server進行交互。從kubectl發送的任何內容最終都會被API Server所接收。所以，多個工具和插件會直接或間接地使用相同的API。

即便在Kubernetes集羣中訪問或者操做對象以前，該請求也須要由API Server進行身份驗證。REST路徑使用基於X.509證書的TLS協議來保護和加密流量。Kubectl在編碼和發送請求以前查找文件〜/ .kube / config以檢索CA證書和客戶端證書。

apiVersion: v1
clusters:
- cluster:
    certificate-authority: /Users/janakiramm/.minikube/ca.crt
    server: https://192.168.99.100:8443
  name: minikube
contexts:
- context:
    cluster: minikube
    user: minikube
  name: minikube
current-context: minikube
kind: Config
preferences: {}
users:
- name: minikube
  user:
    client-certificate: /Users/janakiramm/.minikube/client.crt
    client-key: /Users/janakiramm/.minikube/client.key

文件ca.crt表示集羣使用的CA證書，文件client.crt和client.key映射到用戶minikube。Kubectl使用上下文中的這些證書和密鑰對請求進行編碼。

咱們能夠經過curl命令訪問API Server嗎？答案是確定的。

即便最多見的操做是經過運行kubectl proxy來使用tunnel協議，咱們依然能夠經過計算機上的可用證書來訪問路徑。除了CA證書以外，咱們還須要在頭部嵌入base64編碼的令牌（token）。

如何檢索令牌（token）以及從curl調用API的命令以下：

kubectl config view -o jsonpath='{"Cluster name\tServer\n"}{range .clusters[*]}{.name}{"\t"}{.clu

Cluster name  Server
minikube  https://192.168.99.100:8443

export CLUSTER_NAME="minikube"

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

接下來，一個重要的任務就是獲取與默認service account關聯的令牌。無需擔憂這一實體，咱們將在以後的文章中更好地理解它。

TOKEN=$(kubectl get secrets -o jsonpath="{.items[?(@.metadata.annotations['kubernetes\.io/service-a

如今咱們擁有調用curl的全部數據了：

curl -X GET \
  --cacert ~/.minikube/ca.crt \
  --header "Authorization: Bearer $TOKEN" \
  $APISERVER/version

Kubernetes訪問控制的三個層次

如上文所述，用戶和Pod在訪問或操做對象以前都要由API Server進行身份認證。

當一個有效的請求發送到API Server時，在它被容許或被拒絕以前將經歷3個步驟。

一、 身份認證

一旦TLS鏈接創建，請求就進入到身份認證階段，在這一階段，請求有效負載由一個或多個認證器模塊檢查。

認證模塊時管理員在集羣建立過程當中配置的，一個集羣可能有多個認證模塊配置，每一個模塊會依次嘗試認證， 直到其中一個認證成功。

在主流的認證模塊中會包括客戶端證書、密碼、plain tokens、bootstrap tokens以及JWT tokens（用於service account）。客戶端證書的使用是默認的而且是最多見的方案。有關認證模塊的詳細列表，請參閱：

https://kubernetes.io/docs/re...

請注意，Kubernetes是沒有用於驗證用戶身份的典型用戶數據庫或者配置文件。可是它使用從X.509證書以及令牌中提取的字符串，將它們傳遞到身份認證模塊。OpenID，Github甚至LDAP提供的外部認證機制能夠經過其中一個認證模塊與Kubernetes集成。

二、 受權

一旦API請求獲得認證，下一步就是確認這一操做是否被容許執行。這是訪問控制流程中的第二個步驟。

對於受權一個請求，Kubernetes主要關注三個方面——請求者的用戶名、請求動做以及該動做影響的對象。用戶名從嵌入token的頭部中提取，動做是映射到CRUD操做的HTTP動詞之一（如 GET、POST、PUT、DELETE），對象是其中一個有效的Kubernetes對象，如pod或者service。

Kubernetes基於一個存在策略來決定受權。默認狀況下，Kubernetes遵循封閉開放的理念，這意味着須要一個明確的容許策略才能夠訪問資源。

與身份認證相似，受權也是基於一個或多個模塊配置的，如ABAC模式、RBAC模式以及Webhook模式。當管理員建立集羣時，他們配置與API sever集成的受權模塊。若是多個模塊都在使用，Kubernetes會檢查每一個模塊而且若是其中任一模塊受權了請求，則請求受權經過。若是全部模塊所有拒絕請求，則請求被拒絕（HTTP狀態碼403）。若是想了解詳細的受支持的模塊列表，請參閱：

https://kubernetes.io/docs/re...

當您使用默認配置的kubectl時，全部的請求都會經過，所以此時您被認爲時集羣管理員。但當咱們添加新的用戶，默認狀態下他們會限制訪問權限。

三、 准入控制

經過准入控制是請求的最後一個步驟。與前兩個步驟相似，准入控制也有許多模塊。

但與前兩個步驟不一樣的是，最後的階段能夠修改目標對象。准入控制模塊做用於對象的建立、刪除、更新和鏈接（proxy）階段，但不包括對象的讀取。舉個例子，例如，准入控制模塊可用於修改建立持久卷聲明（PVC）的請求以使用特定存儲類。模塊能夠實施的另外一個策略是每次建立容器時提取鏡像。更多關於准入控制模塊的詳情，請參閱：

https://kubernetes.io/docs/re...

在這一過程當中，若是任一準入控制模塊拒絕，那麼請求馬上被拒絕。一旦請求經過全部的准入控制器，將使用對應API對象的驗證流程對其進行驗證，而後寫入對象存儲。

在下一部分的文章中，咱們將更進一步瞭解建立用戶以及爲其配置身份認證。保持關注喲~