kubernetes API Server權限管理的示例分析

173次閱讀

共計 10658 個字符，預計需要花費 27 分鐘才能閱讀完成。

這篇文章主要介紹 kubernetes API Server 權限管理的示例分析，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

API Server 權限管理應用
API Server 權限控制方式介紹

API Server 權限控制分為三種：Authentication（身份認證）、Authorization(授權)、AdmissionControl(準入控制)。

身份認證：

當客戶端向 Kubernetes 非只讀端口發(fā)起 API 請求時，Kubernetes 通過三種方式來認證用戶的合法性。kubernetes 中，驗證用戶是否有權限操作 api 的方式有三種：證書認證，token 認證，基本信息認證。

證書認證

設置 apiserver 的啟動參數(shù)：–client_ca_file=SOMEFILE，這個被引用的文件中包含的驗證 client 的證書，如果被驗證通過，那么這個驗證記錄中的主體對象將會作為請求的 username。

Token 認證

設置 apiserver 的啟動參數(shù)：–token_auth_file=SOMEFILE。token file 的格式包含三列：token，username，userid。當使用 token 作為驗證方式時，在對 apiserver 的 http 請求中，增加一個 Header 字段：Authorization，將它的值設置為：Bearer SOMETOKEN。

基本信息認證

設置 apiserver 的啟動參數(shù)：–basic_auth_file=SOMEFILE，如果更改了文件中的密碼，只有重新啟動 apiserver 使其重新生效。其文件的基本格式包含三列：passwork，username，userid。當使用此作為認證方式時，在對 apiserver 的 http 請求中，增加一個 Header 字段：Authorization，將它的值設置為：Basic BASE64ENCODEDUSER:PASSWORD。

授權：

在 Kubernetes 中，認證和授權是分開的，而且授權發(fā)生在認證完成之后，認證過程是檢驗發(fā)起 API 請求的用戶是不是他所聲稱的那個人。而授權過程則判斷此用戶是否有執(zhí)行該 API 請求的權限，因此授權是以認證的結果作為基礎的。Kubernetes 授權模塊應用于所有對 APIServer 的 HTTP 訪問請求（只讀端口除外），訪問只讀端口不需要認證和授權過程。APIServer 啟動時默認將 authorization_mode 設置為 AlwaysAllow 模式，即永遠允許。

Kubernetes 授權模塊檢查每個 HTTP 請求并提取請求上下文中的所需屬性（例如：user，resource kind，namespace）與訪問控制規(guī)則進行比較。任何一個 API 請求在被處理前都需要通過一個或多個訪問控制規(guī)則的驗證。

目前 Kubernetes 支持并實現(xiàn)了以下的授權模式（authorization_mode），這些授權模式可以通過在 apiserver 啟動時傳入?yún)?shù)進行選擇。

–authorization_mode=AlwaysDeny

–authorization_mode=AlwaysAllow

–authorization_mode=ABAC

AlwaysDeny 模式屏蔽所有的請求（一般用于測試）。AlwaysAllow 模式允許所有請求，默認 apiserver 啟動時采用的便是 AlwaysAllow 模式）。ABAC（Attribute-Based Access Control，即基于屬性的訪問控制）模式則允許用戶自定義授權訪問控制規(guī)則。

ABAC 模式：

一個 API 請求中有 4 個屬性被用于用戶授權過程：

UserName：String 類型，用于標識發(fā)起請求的用戶。如果不進行認證、授權操作，則該字符串為空。

ReadOnly：bool 類型，標識該請求是否僅進行只讀操作（GET 就是只讀操作）。

Kind：String 類型，用于標識要訪問的 Kubernetes 資源對象的類型。當訪問例如 /api/v1beta1/pods 等 API endpoint 時，Kind 屬性才非空，但訪問其他 endpoint 時，例如 /version，/healthz 等，Kind 屬性為空。

Namespace：String 類型，用于標識要訪問的 Kubernetes 資源對象所在的 namespace。

對 ABAC 模式，在 apiserver 啟動時除了需要傳入 –authorization_mode=ABAC 選項外，還需要指定 –authorization_policy_file=SOME_FILENAME。authorization_policy_file 文件的每一行都是一個 JSON 對象，該 JSON 對象是一個沒有嵌套的 map 數(shù)據(jù)結構，代表一個訪問控制規(guī)則對象。一個訪問控制規(guī)則對象是一個有以下字段的 map：

user：–token_auth_file 指定的 user 字符串。

readonly：true 或 false，如果是 true 則表明該規(guī)則只應用于 GET 請求。

kind：Kubernetes 內置資源對象類型，例如 pods、events 等。

namespace：也可以縮寫成 ns。

一個簡單的訪問控制規(guī)則文件如下所示，每一行定義一條規(guī)則。

{user : admin}

{user : alice , ns : projectCaribou}

{user : kubelet , readonly : true, kind : pods}

{user : kubelet , kind : events}

{user : bob , kind : pods , readonly : true, ns : projectCaribou}

注：缺省的字段與該字段類型的零值（空字符串，0，false 等）等價。

規(guī)則逐行說明如下。

第一行表明，admin 可以做任何事情，不受 namespace，資源類型，請求類型的限制。

第二行表明，alice 能夠在 namespace projectCaribou 中做任何事情，不受資源類型，請求類型的限制。

第三行表明，kubelet 有權限讀任何一個 pod 的信息。

第四行表明，kubelet 有權限讀寫任何一個 event。

第五行表明，Bob 有權限讀取在 namespace projectCaribou 中所有 pod 的信息。

一個授權過程就是一個比較 API 請求中各屬性與訪問控制規(guī)則文件中對應的各字段是否匹配的一個過程。當 apiserver 接收到一個 API 請求時，該請求的各屬性就已經(jīng)確定了，如果有一個屬性未被設置，則 apiserver 將其設為該類型的空值（空字符串，0，false 等）。匹配規(guī)則很簡單，如下所示。

如果 API 請求中的某個屬性為空值，則規(guī)定該屬性與訪問控制規(guī)則文件中對應的字段匹配。

如果訪問控制規(guī)則的某個字段為空值，則規(guī)定該字段與 API 請求的對應屬性匹配。

如果 API 請求中的屬性值非空且訪問控制規(guī)則的某個字段值也非空，則將這兩個值進行比較，如果相同則匹配，反之則不匹配。

API 請求的屬性元組（tuple）會與訪問控制規(guī)則文件中的所有規(guī)則逐條匹配，只要有一條匹配則表示匹配成功，如若不然，則授權失敗。

準入控制：

準入控制 admission controller 本質上為一段準入代碼，在對 kubernetes api 的請求過程中，順序為先經(jīng)過認證授權，然后執(zhí)行準入操作，再對目標對象進行操作。這個準入代碼在 apiserver 中，而且必須被編譯到二進制文件中才能被執(zhí)行。

在對集群進行請求時，每個準入控制代碼都按照一定順序執(zhí)行。如果有一個準入控制拒絕了此次請求，那么整個請求的結果將會立即返回，并提示用戶相應的 error 信息。

在某些情況下，為了適用于應用系統(tǒng)的配置，準入邏輯可能會改變目標對象。此外，準入邏輯也會改變請求操作的一部分相關資源。

作用

在 kubernetes 中，一些高級特性正常運行的前提條件為，將一些準入模塊處于 enable 狀態(tài)。總結下，對于 kubernetes apiserver，如果不適當?shù)呐渲脺嗜肟刂颇K，它就不能稱作是一個完整的 server，某些功能也不會正常的生效。

開啟方式

在 kubernetes apiserver 中有一個參數(shù)：admission_control，他的值為一串用逗號連接的有序的準入模塊列表，設置后，就可在對象被操作前執(zhí)行一定順序的準入模塊調用。

模塊功能

AlwaysAdmit：允許所有請求

AlwaysDeny：禁止所有請求，多用于測試環(huán)境。

DenyExecOnPrivileged：它會攔截所有想在 privileged container 上執(zhí)行命令的請求。如果自己的集群支持 privileged container，自己又希望限制用戶在這些 privileged container 上執(zhí)行命令，那么強烈推薦使用它。

ServiceAccount：這個 plug-in 將 serviceAccounts 實現(xiàn)了自動化，如果想要使用 ServiceAccount 對象，那么強烈推薦使用它。

關于 serviceAccount 的描述如下：一個 serviceAccount 為運行在 pod 內的進程添加了相應的認證信息。當準入模塊中開啟了此插件（默認開啟），那么當 pod 創(chuàng)建或修改時他會做一下事情：

如果 pod 沒有 serviceAccount 屬性，將這個 pod 的 serviceAccount 屬性設為“default”；

確保 pod 使用 de serviceAccount 始終存在；

如果 LimitSecretReferences 設置為 true，當這個 pod 引用了 Secret 對象卻沒引用 ServiceAccount 對象，棄置這個 pod；

如果這個 pod 沒有包含任何 ImagePullSecrets，則 serviceAccount 的 ImagePullSecrets 被添加給這個 pod；

如果 MountServiceAccountToken 為 true，則將 pod 中的 container 添加一個 VolumeMount。

SecurityContextDeny：這個插件將會將使用了 SecurityContext 的 pod 中定義的選項全部失效。SecurityContext 在 container 中定義了操作系統(tǒng)級別的安全設定（uid, gid, capabilities, SELinux 等等）。

ResourceQuota：它會觀察所有的請求，確保在 namespace 中 ResourceQuota 對象處列舉的 container 沒有任何異常。如果在 kubernetes 中使用了 ResourceQuota 對象，就必須使用這個插件來約束 container。推薦在 admission control 參數(shù)列表中，這個插件排最后一個。

LimitRanger：他會觀察所有的請求，確保沒有違反已經(jīng)定義好的約束條件，這些條件定義在 namespace 中 LimitRange 對象中。如果在 kubernetes 中使用 LimitRange 對象，則必須使用這個插件。

NamespaceExists：它會觀察所有的請求，如果請求嘗試創(chuàng)建一個不存在的 namespace，則這個請求被拒絕。

推薦插件順序

–admission_control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ServiceAccount, ResourceQuota

驗證流程

1. API Server 的初始化參數(shù)中設置了一些與權限認證相關的默認屬性：

安全監(jiān)聽端口： SecurePort: 8443 讀 / 寫權限，支持 x509 安全證書和 x509 私鑰認證

非安全監(jiān)聽端口：InsecurePort: 8080 沒有用戶身份認證和授權，有讀 / 寫權限

授權模式： AuthorizationMode: AlwaysAllow ,

準入控制插件： AdmissionControl: AlwaysAdmit

2. API Server 啟動時可以設置與權限認證相關的參數(shù)：

–insecure_port 自定義非安全監(jiān)聽端口

–secure_port 自定義安全監(jiān)聽端口

–tls_cert_file 設置安全證書文件

–tls_private_key_file 設置私鑰文件

–cert_dir 安全證書文件和私鑰文件被設置時，此屬性忽略。安全證書文件和私鑰文件未設置時，apiserver 會自動為該

端口綁定的公有 IP 地址分別生成一個自注冊的證書文件和密鑰并將它們存儲在 /var/run/kubernetes 下

–service_account_key_file 服務賬號文件，包含 x509 公私鑰

–client_ca_file client 證書文件

–token_auth_file token 文件

–basic_auth_file 基本信息認證文件

–authorization_mode 授權模式

–ahtuorization_policy_file 授權文件

–admission_control 準入控制模塊列表

–admission_control_config_file 準入控制配置文件

3. 解析入?yún)ⅲM行認證信息提取：

公私鑰文件設置：查看 ServerAccountKeyFile 是否已指定，如果未指定，并且 TLSPrivateKeyFile 被指定，則判斷 TLSPrivateKeyFile 中是否包含有效的 RSA key，包含時，將 TLSPrivateKeyFile 作為 ServerAccountKeyFile。

身份認證信息提取：從參數(shù)設置的 CSV 文件中取出 username，userID，password（或者 token）封裝成 map 結構，key 為 username,value 為三種屬性的 struct。從 basicAuthFile, clientCAFile, tokenFile, serviceAccountKeyFile（serviceAccountLookup）中取 user 信息, 得到一個驗證信息的 map 數(shù)組。

授權信息提取：讀取設置的授權文件，解析字符串，返回授權信息數(shù)組。（包含 username,group,resource,read only,namespace）Make the cluster Kinds be one API group (minions, bindings，events,endpoints)。The user Kinds are another (pods,services,replicationControllers,operations)。

準入控制插件：獲取所有插件名，返回準入控制接口（執(zhí)行所有插件）

4. 將身份認證信息、授權信息、準入控制插件作為 Master 的配置，New Master。

5. 請求認證：

調 apiserver 的 NewRequestAttributeGetter 方法，從請求中提取授權信息，調用 WithAuthorizationCheck 方法（授權驗證）。

調用 handler 的 NewRequestAuthenticator 方法，Request 中提取 authencate 信息, 調用 AuthenticateRequest 方法（對 client certificates，token,basic auth 分別有不同的驗證方法）。

補充

身份認證：

token 認證，請求時，在請求頭中加入 Authorization:bearer token 字符串。CSV 文件中，三列分別為 token,username,userid。當 CSV 中有與請求的 Authorization 匹配行時，認證成功。

basic auth 認證，請求時，在請求頭中加入 Authorization:basic base64 編碼的 user:password 字符串。CSV 文件中，三列分別為 password,username,userid。當 CSV 文件中有與請求的 Ahtuorization 匹配行時，認證成功。

證書校驗：

API Server 啟動時，指定服務端數(shù)字證書和密鑰（如果不指定，會在 server 啟動時自動生成），指定客戶端 ca 文件，server 啟動時，會解析 ca 文件，遍歷其中的 cert，加入 certpool。在 Server 的 TLSConfig 中指定認證模式：目前使用的是 RequestClientCert（不強制認證，無認證時不拒絕連接，允許其他認證），此外還有其他認證模式 requireAndVerifyClientCert(強制校驗)。使用 ListenAndServeTLS（將服務端數(shù)字證書和密鑰作為參數(shù)）監(jiān)聽在安全端口。

API Server 權限控制操作（暫時未加入 namespace）測試：

啟動 server：指定 token 驗證文件、授權方式、授權文件

./_output/local/bin/linux/amd64/canary-apiserver –logtostderr=true –log-dir=/tmp –v=4 –etcd_servers=http://127.0.0.1:4001 –insecure_bind_address=127.0.0.1 –insecure_port=8088 –secure_port=8442 –kubelet_port=10250 –service-cluster-ip-range=10.1.1.0/24 –allow_privileged=true –runtime-config= api/v1beta3=false –redis-addr=localhost:6379 –profiling=true –token_auth_file=token.csv –authorization_mode=ABAC –authorization_policy_file=abac.csv

Token 文件內容：

abcdef,hankai,123456

abcdefg,hk,123457

abcd,admin,1234

abc,hhh,111

授權文件內容：

{“user”:”admin”}

{“user”:”hankai”,”readonly”:true}

{“user”:”hhh”,”resource”:”apps”}

{“user”:”hk”,”readonly”:true,”resource”:”namespaces”}

驗證：admin（有讀寫所有 resource 的權限）

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcd -k https://10.57.104.59:8442/api/v1/apps

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcd -k https://10.57.104.59:8442/api/v1/namespaces

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcd -d@ n1.json -k https://10.57.104.59:8442/api/v1/namespaces

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcd -d@ app_demo1.json -k https://10.57.104.59:8442/api/v1/apps

驗證 hankai (只有讀權限 GET)

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcdef -d@ app_demo1.json -k https://10.57.104.59:8442/api/v1/apps forbidden

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcdef -d@ n1.json -k https://10.57.104.59:8442/api/v1/namespaces forbidden

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcdef -k https://10.57.104.59:8442/api/v1/namespaces

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcdef -k https://10.57.104.59:8442/api/v1/apps

驗證 hk (只有對 namespaces 的 GET 權)

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcdefg -k https://10.57.104.59:8442/api/v1/apps

forbidden

curl -X GET -H Content-Type: application/json -H Authorization: bearer abcdefg -k https://10.57.104.59:8442/api/v1/namespaces

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcdefg -d@ n1.json -k https://10.57.104.59:8442/api/v1/namespaces forbidden

curl -X POST -H Content-Type: application/json -H Authorization: bearer abcdefg -d@ app_demo1.json -k https://10.57.104.59:8442/api/v1/apps forbidden

驗證 hhh（擁有對 apps 的讀寫權）

curl -X POST -H Content-Type: application/json -H Authorization: bearer abc -d@ app_demo1.json -k https://10.57.104.59:8442/api/v1/apps

curl -X GET -H Content-Type: application/json -H Authorization: bearer abc -k https://10.57.104.59:8442/api/v1/apps

curl -X GET -H Content-Type: application/json -H Authorization: bearer abc -k https://10.57.104.59:8442/api/v1/namespaces

forbidden

curl -X POST -H Content-Type: application/json -H Authorization: bearer abc -d@ n1.json -k https://10.57.104.59:8442/api/v1/namespaces

forbidden

注：后續(xù)只需要在 abac.csv 文件的每列中，指定 namespace，就可以實現(xiàn) user 對指定 namespace 的操作權限。

新增：TSL 客戶端證書認證

使用自生成證書測試：使用 openssl 生成 server.crt,server.key,ca.key,ca.crt。Server 啟動時，傳入 –tls_cert_file=server.crt –tls_private_key_file=server.key –client_ca_file=ca.crt

./_output/local/bin/linux/amd64/canary-apiserver –logtostderr=true –log-dir=/tmp –v=4 –etcd_servers=http://127.0.0.1:4001 –insecure_bind_address=7.0.0.1 –insecure_port=8088 –secure_port=8442 –kubelet_port=10250 –service-cluster-ip-range=10.1.1.0/24 –allow_privileged=true –runtime-config= api/v1beta3=false –redis-addr=localhost:6379 –profiling=true –tls_cert_file=server.crt –tls_private_key_file=server.key –client_ca_file=ca.crt –token_auth_file=token.csv –authorization_mode=ABAC –authorization_policy_file=abac.csv

請求時，通過 -cacert 指定客戶端證書（可以通過修改 opnessl 的配置文件指定客戶端證書的路徑，或者瀏覽器中導入客戶端證書）curl -X GET –cacert ca.crt -H Content-Type: application/json -H Authorization: bearer abcd -k https://10.57.104.59:8442/api/v1/apps 即可實現(xiàn)認證。

以上是“kubernetes API Server 權限管理的示例分析”這篇文章的所有內容，感謝各位的閱讀！希望分享的內容對大家有幫助，更多相關知識，歡迎關注丸趣 TV 行業(yè)資訊頻道！

正文完