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個步驟。
1、 身份認證
一旦TLS連接建立，請求就進入到身份認證階段，在這一階段，請求有效負載由一個或多個認證器模塊檢查。
認證模塊時管理員在集群創建過程中配置的，一個集群可能有多個認證模塊配置，每個模塊會依次嘗試認證， 直到其中一個認證成功。
在主流的認證模塊中會包括客戶端證書、密碼、plain tokens、bootstrap tokens以及JWT tokens(用于service account)。客戶端證書的使用是默認的并且是最常見的方案。
請注意，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)。
當您使用默認配置的kubectl時，所有的請求都會通過，因此此時您被認為時集群管理員。但當我們添加新的用戶，默認狀態下他們會限制訪問權限。
3、 準入控制
通過準入控制是請求的最后一個步驟。與前兩個步驟類似，準入控制也有許多模塊。
但與前兩個步驟不同的是，最后的階段可以修改目標對象。準入控制模塊作用于對象的創建、刪除、更新和連接(proxy)階段，但不包括對象的讀取。舉個例子，例如，準入控制模塊可用于修改創建持久卷聲明(PVC)的請求以使用特定存儲類。模塊可以實施的另一個策略是每次創建容器時提取鏡像。
在這一過程中，如果任一準入控制模塊拒絕，那么請求立刻被拒絕。一旦請求通過所有的準入控制器，將使用對應API對象的驗證流程對其進行驗證，然后寫入對象存儲。
在下一部分的文章中，我們將更進一步了解創建用戶以及為其配置身份認證。保持關注喲~
