Kubernetes認證入門指南

Kubernetes用來執行安全訪問和權限的步驟有3個——認證（Authentication）、受權（Authorization）和准入（Admission）。在本文中，咱們先開始瞭解認證（Authentication）。

在認證中第一個須要考慮的是身份認證（Identity）。

身份認證簡介

Kubernetes假設「user」是在Kubernetes以外管理的。在生產環境中，能夠採用LDAP（輕量級目錄訪問協議）、SSO（單點登陸）、Kerberos或SAML（安全斷言置標語言）進行身份認證管理。在開發或測試環境中，其餘的認證策略也有可能會被使用到。

在Kubernetes中沒有表達普通用戶的對象，所以不能經過API將普通用戶添加到集羣中。

認證策略概覽

Kubernetes經過認證插件使用認證代理、bearer token、客戶端證書或HTTP基本受權來認證API請求。當向API server發出HTTP請求時，插件會嘗試將如下屬性與請求關聯起來：

• Username：識別最終用戶的字符串
• UID：識別最終用戶的字符串，並試圖比username格式更爲一致，同時每一個UID都是獨特的。
• Groups：一組字符串，將用戶與一組常見的分組用戶關聯起來
• Extra fields：字符串的映射，保存着受權者認爲可能有用的額外信息。

全部這些值對認證系統來講都是不透明的，只有在authorizer對其進行解釋時纔有意義。Kubernetes管理員一般會啓用多種認證方法。所需的兩種最基本的方法是——服務帳戶的service account token再加上至少一種其餘的用戶認證方法。

X509客戶端證書

• 從Kubernetes 1.4開始，客戶端證書能夠使用證書組織字段來代表用戶的組成員資格。
• 要讓一個用戶擁有多個組成員資格，須要在證書中包含多個組織字段。
• 經過向API server傳遞 --client-ca-file=<FILE>選項來啓用客戶端證書認證。
• 引用的文件必須包含一個或多個證書頒發機構，用於驗證提交給API server的客戶證書。
• 若是出示客戶端證書並進行驗證，則使用主體的通用名做爲請求的用戶名。

例如，使用openssl命令行工具來生成證書籤名請求：

openssl req -new -key <pem_file>.pem -out <out-csr-file>.pem -subj "/CN=admin/O=prod/O=dev/O=uat"

這將爲用戶名admin建立一個CSR（證書籤名請求），該用戶名屬於如下3個組：prod、dev和uat。

靜態Token文件

當在命令行中給出--token-auth-file=<FILENAME>選項時，API Server會從文件中讀取bearer token。現在，token無限期存在，若是不重啓API Server，就沒法更改token列表。Token文件是一個csv文件，至少有3列：token、用戶名、user uid，後面可能還會有組名（這是可選的）。

token, user, uid,"prod,dev,uat"

請注意：若是你有超過1個組，該列必須使用雙引號。

在請求中放入一個bearer token

當使用來自HTTP客戶端的bearer token認證時，API server指望受權請求頭的值爲Bearer <Token>。bearer token必須是一個字符序列，能夠只需使用HTTP的編碼和引用功能就能夠將其放在HTTP請求頭的值中。例如，若是Bearer Token是ad644f3f-bfch-295b-75bk-h9g8ngf36hb6，那麼它將出如今HTTP請求頭中，以下所示：

Authorization: Bearer ad644f3f-bfch-295b-75bk-h9g8ngf36hb6

靜態密碼文件

經過向API server傳遞--basic-auth-file=<FILENAME>選項來啓用基本認證。如今，基本的認證憑證將無限期地持續下去，並且若是不從新啓動 API server，就沒法更改密碼。

基本的 auth 文件是一個 csv 文件，至少有 3 列：密碼、用戶名、用戶 ID。在Kubernetes 1.6及之後的版本中，你能夠指定一個可選的第4列，包含逗號分隔的組名。若是你有多個組，你必須用雙引號(")括住第4列的值。

password,user,uid,"group1,group2,group3"

當使用來自HTTP客戶端的基本認證時，API server指望Authorizationheader的值爲：

Basic BASE64ENCODED(USER:PASSWORD)

服務帳戶Token

服務帳戶是一個自動啓用的身份認證器，它使用簽名的bearer token來驗證請求。該插件須要2個可選的標誌：

--service-account-key-file

一個包含PEM編碼密鑰的文件，用於簽署bearer token。若是沒有指定，將使用API server的TLS密鑰。

--service-account-lookip

若是啓用了，從API sever上刪除的token將被撤銷。

服務帳戶一般由API server自動建立，並經過ServiceAccount 准入控制器與集羣中運行的Pod相關聯。

Bearer Token會被掛載到衆所周知的位置的Pod中，並容許集羣內進程與API Server對話。帳戶能夠使用PodSpec的serviceAccountName字段與Pod顯式關聯。

注意，serviceAccountName一般會被省略，由於這是自動完成的。

練習實踐：使用ServiceAccount Token

使用如下命令能夠建立ServiceAccount：

kubectl create serviceaccount testuser

建立的密鑰包含API server的公共CA和簽名的JSON web Token（JWT）。如下命令能夠顯示出揭示相關密鑰的yaml：

kubectl get serviceaccount testuser -o yaml

如下命令能夠顯示可用Token：

kubectl get secrets

要得到編碼的token數據，請輸入：

kubectl get secret testuser-token-mgtnp -o yaml

你能夠將編碼後的token數據複製並粘貼到https://jwt.io/ 以查看有效載荷。使用你選擇的編輯器輸入如下yaml文件（test-pod.yaml），以運行一個pod：

apiVersion: v1 
kind: pod 
metadata:  
  name: test-pod 
spec:  
  serviceAccountName: testuser  
  container:  
  - name: alpine:3.7    
    command:    
    - "sh"    
    - "-c"    
    - "sleep 100"

而後使用如下命令啓動pod：

kubectl apply -f test-pod.yaml

使用describe能夠查看更詳細的內容：

kubectl describe test-pod

如今，咱們有一個正在運行的pod，名爲test-pod，讓咱們進入交互模式並運行一個shell：

kubectl exec -it test-pod -- sh

若是你想在docker容器內運行shell，所使用的命令與docker命令相似。這時，咱們將會收到一個提示，而後進入Alpine Linux系統，該系統是在pod中的一個容器內運行的。爲了打開被複制到容器中的token，你須要運行如下命令：

cat /var/run/sercrets/kubernetes.io/serviceaccount/token

複製輸出並將該token粘貼在https://jwt.io/上Encoded部分...

這幾乎以一種十分直觀的方式向你說明了Kubernetes如何在token中進行身份驗證有效載荷。

做者：
Sudip Sengupta
連接：
https://dzone.com/articles/ku...