隨著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個步驟。

1. 身份認證

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

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

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

https://kubernetes.io/docs/reference/access-authn-authz/authentication/

請注意，Kubernetes是沒有用於驗證使用者身份的典型使用者資料庫或者配置檔案。但是它使用從X.509證書以及令牌中提取的字串，將它們傳遞到身份認證模組。OpenID，Github甚至LDAP提供的外部認證機制可以通過其中一個認證模組與Kubernetes整合。

2. 授權

一旦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/reference/access-authn-authz/authorization/#authorization-modules

當您使用預設配置的kubectl時，所有的請求都會通過，因此此時您被認為時叢集管理員。但當我們新增新的使用者，預設狀態下他們會限制訪問許可權。

3. 准入控制

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

但與前兩個步驟不同的是，最後的階段可以修改目標物件。准入控制模組作用於物件的建立、刪除、更新和連線（proxy）階段，但不包括物件的讀取。舉個例子，例如，准入控制模組可用於修改建立持久卷宣告（PVC）的請求以使用特定儲存類。模組可以實施的另一個策略是每次建立容器時提取映象。更多關於准入控制模組的詳情，請參閱：

https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/

在這一過程中，如果任一準入控制模組拒絕，那麼請求立刻被拒絕。一旦請求通過所有的准入控制器，將使用對應API物件的驗證流程對其進行驗證，然後寫入物件儲存。

在下一部分的文章中，我們將更進一步瞭解建立使用者以及為其配置身份認