欧美一区二区三区老妇人-欧美做爰猛烈大尺度电-99久久夜色精品国产亚洲a-亚洲福利视频一区二区

kubernetesAPIServer權(quán)限管理的示例分析

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

公司主營業(yè)務(wù)：網(wǎng)站制作、成都做網(wǎng)站、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳，提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化，感謝他們對(duì)我們的高要求，感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn)，讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出欒城免費(fèi)做網(wǎng)站回饋大家。

API Server 權(quán)限管理應(yīng)用                                 

API Server權(quán)限控制方式介紹

API Server權(quán)限控制分為三種：Authentication（身份認(rèn)證）、Authorization(授權(quán))、AdmissionControl(準(zhǔn)入控制)。

身份認(rèn)證：

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

  • 證書認(rèn)證

       設(shè)置apiserver的啟動(dòng)參數(shù)：--client_ca_file=SOMEFILE ，這個(gè)被引用的文件中包含的驗(yàn)證client的證書，如果被驗(yàn)證通過，那么這個(gè)驗(yàn)證記錄中的主體對(duì)象將會(huì)作為請(qǐng)求的username。

  • Token認(rèn)證

       設(shè)置apiserver的啟動(dòng)參數(shù)：--token_auth_file=SOMEFILE。 token file的格式包含三列：token，username，userid。當(dāng)使用token作為驗(yàn)證方式時(shí)，在對(duì)apiserver的http請(qǐng)求中，增加 一個(gè)Header字段：Authorization ，將它的值設(shè)置為：Bearer SOMETOKEN。

  • 基本信息認(rèn)證

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

授權(quán)：

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

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

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

--authorization_mode=AlwaysDeny

--authorization_mode=AlwaysAllow

--authorization_mode=ABAC

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

  • ABAC模式：

一個(gè)API請(qǐng)求中有4個(gè)屬性被用于用戶授權(quán)過程：

      UserName：String類型，用于標(biāo)識(shí)發(fā)起請(qǐng)求的用戶。如果不進(jìn)行認(rèn)證、授權(quán)操作，則該字符串為空。

      ReadOnly：bool類型，標(biāo)識(shí)該請(qǐng)求是否僅進(jìn)行只讀操作（GET就是只讀操作）。

      Kind：String類型，用于標(biāo)識(shí)要訪問的Kubernetes資源對(duì)象的類型。當(dāng)訪問例如/api/v1beta1/pods等API endpoint時(shí)，Kind屬性才非空，但訪問其他endpoint時(shí)，例如/version，/healthz等，Kind屬性為空。

      Namespace：String類型，用于標(biāo)識(shí)要訪問的Kubernetes資源對(duì)象所在的namespace。

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

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

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

      kind：Kubernetes內(nèi)置資源對(duì)象類型，例如pods、events等。

      namespace：也可以縮寫成ns。

一個(gè)簡單的訪問控制規(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等）等價(jià)。

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

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

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

       第三行表明，kubelet有權(quán)限讀任何一個(gè)pod的信息。

       第四行表明，kubelet有權(quán)限讀寫任何一個(gè)event。

       第五行表明，Bob有權(quán)限讀取在namespace "projectCaribou"中所有pod的信息。

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

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

  • 如果訪問控制規(guī)則的某個(gè)字段為空值，則規(guī)定該字段與API請(qǐng)求的對(duì)應(yīng)屬性匹配。

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

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

準(zhǔn)入控制：

       準(zhǔn)入控制admission controller本質(zhì)上為一段準(zhǔn)入代碼，在對(duì)kubernetes api的請(qǐng)求過程中，順序?yàn)?先經(jīng)過 認(rèn)證 & 授權(quán)，然后執(zhí)行準(zhǔn)入操作，再對(duì)目標(biāo)對(duì)象進(jìn)行操作。這個(gè)準(zhǔn)入代碼在apiserver中，而且必須被編譯到二進(jìn)制文件中才能被執(zhí)行。

       在對(duì)集群進(jìn)行請(qǐng)求時(shí)，每個(gè)準(zhǔn)入控制代碼都按照一定順序執(zhí)行。如果有一個(gè)準(zhǔn)入控制拒絕了此次請(qǐng)求，那么整個(gè)請(qǐng)求的結(jié)果將會(huì)立即返回，并提示用戶相應(yīng)的error信息。

       在某些情況下，為了適用于應(yīng)用系統(tǒng)的配置，準(zhǔn)入邏輯可能會(huì)改變目標(biāo)對(duì)象。此外，準(zhǔn)入邏輯也會(huì)改變請(qǐng)求操作的一部分相關(guān)資源。

  • 作用

       在kubernetes中，一些高級(jí)特性正常運(yùn)行的前提條件為，將一些準(zhǔn)入模塊處于enable狀態(tài)。總結(jié)下，對(duì)于kubernetes apiserver，如果不適當(dāng)?shù)呐渲脺?zhǔn)入控制模塊，它就不能稱作是一個(gè)完整的server，某些功能也不會(huì)正常的生效。

  • 開啟方式

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

  • 模塊功能

      AlwaysAdmit：允許所有請(qǐng)求

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

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

      ServiceAccount：這個(gè)plug-in將 serviceAccounts實(shí)現(xiàn)了自動(dòng)化，如果想要使用ServiceAccount 對(duì)象，那么強(qiáng)烈推薦使用它。

關(guān)于serviceAccount的描述如下： 一個(gè)serviceAccount為運(yùn)行在pod內(nèi)的進(jìn)程添加了相應(yīng)的認(rèn)證信息。當(dāng)準(zhǔn)入模塊中開啟了此插件（默認(rèn)開啟），那么當(dāng)pod創(chuàng)建或修改時(shí)他會(huì)做一下事情：

  1.       如果pod沒有serviceAccount屬性，將這個(gè)pod的serviceAccount屬性設(shè)為“default”；

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

  3.       如果LimitSecretReferences 設(shè)置為true，當(dāng)這個(gè)pod引用了Secret對(duì)象卻沒引用ServiceAccount對(duì)象，棄置這個(gè)pod；

  4.       如果這個(gè)pod沒有包含任何ImagePullSecrets，則serviceAccount的ImagePullSecrets被添加給這個(gè)pod；

  5.       如果MountServiceAccountToken為true，則將pod中的container添加一個(gè)VolumeMount 。

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

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

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

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

  • 推薦插件順序

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

驗(yàn)證流程

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

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

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

  • 授權(quán)模式：           AuthorizationMode:   "AlwaysAllow",

  • 準(zhǔn)入控制插件：    AdmissionControl:     "AlwaysAdmit"

2.API Server啟動(dòng)時(shí)可以設(shè)置與權(quán)限認(rèn)證相關(guān)的參數(shù)：

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

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

--tls_cert_file                                   設(shè)置安全證書文件

--tls_private_key_file                      設(shè)置私鑰文件

--cert_dir                                         安全證書文件和私鑰文件被設(shè)置時(shí)，此屬性忽略。安全證書文件和私鑰文件未設(shè)置時(shí)，apiserver會(huì)自動(dòng)為該

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

--service_account_key_file             服務(wù)賬號(hào)文件，包含x509 公私鑰

--client_ca_file                                 client證書文件

--token_auth_file                             token文件

--basic_auth_file                             基本信息認(rèn)證文件

--authorization_mode                     授權(quán)模式

--ahtuorization_policy_file              授權(quán)文件

--admission_control                       準(zhǔn)入控制模塊列表

--admission_control_config_file     準(zhǔn)入控制配置文件

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

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

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

  • 授 權(quán)信息提取：讀取設(shè)置的授權(quán)文件，解析字符串，返回授權(quán)信息數(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ǔn)入控制插件：獲取所有插件名，返回準(zhǔn)入控制接口（執(zhí)行所有插件）

4.將身份認(rèn)證信息、授權(quán)信息、準(zhǔn)入控制插件作為Master的配置，New Master。

5.請(qǐng)求認(rèn)證：

  • 調(diào)apiserver的NewRequestAttributeGetter方法，從請(qǐng)求中提取授權(quán)信息，調(diào)用WithAuthorizationCheck方法（授權(quán)驗(yàn)證）。

  • 調(diào) 用handler的NewRequestAuthenticator方法，Request中提取authencate信息,調(diào)用 AuthenticateRequest方法（對(duì)client certificates，token,basic auth分別有不同的驗(yàn)證方法）。

補(bǔ)充

   身份認(rèn)證：

       token認(rèn)證，請(qǐng)求時(shí)，在請(qǐng)求頭中加入 Authorization:bearer token字符串。CSV文件中，三列分別為 token,username,userid。當(dāng)CSV中有與請(qǐng)求的Authorization匹配行時(shí)，認(rèn)證成功。

      basic auth認(rèn)證，請(qǐng)求時(shí)，在請(qǐng)求頭中加入 Authorization:basic base64編碼的user:password字符串。CSV文件中，三列分別為 password,username,userid。當(dāng)CSV文件中有與請(qǐng)求的Ahtuorization匹配行時(shí)，認(rèn)證成功。

證書校驗(yàn)：

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

API Server權(quán)限控制操作（暫時(shí)未加入namespace）測(cè)試：

啟動(dòng)server：指定token驗(yàn)證文件、授權(quán)方式、授權(quán)文件

./_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文件內(nèi)容：

abcdef,hankai,123456

abcdefg,hk,123457

abcd,admin,1234

abc,hhh,111

授權(quán)文件內(nèi)容：

{“user”:”admin”}

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

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

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

驗(yàn)證：admin（有讀寫所有resource的權(quán)限）

         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

驗(yàn)證 hankai (只有讀權(quán)限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

驗(yàn)證 hk (只有對(duì)namespaces的GET權(quán))

      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

驗(yàn)證hhh（擁有對(duì)apps的讀寫權(quán)）

       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，就可以實(shí)現(xiàn)user對(duì)指定namespace的操作權(quán)限。

新增：TSL 客戶端證書認(rèn)證

    使用自生成證書測(cè)試：使用openssl生成server.crt,server.key,ca.key,ca.crt。Server啟動(dòng)時(shí)，傳入 --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

     請(qǐng)求時(shí)，通過-cacert 指定客戶端證書 （可以通過修改opnessl的配置文件指定客戶端證書的路徑，或者瀏覽器中導(dǎo)入客戶端證書） 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 即可實(shí)現(xiàn)認(rèn)證。

以上是“kubernetes API Server權(quán)限管理的示例分析”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對(duì)大家有幫助，更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)站標(biāo)題：kubernetesAPIServer權(quán)限管理的示例分析
新聞來源：http://www.chinadenli.net/article44/iieihe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供商城網(wǎng)站、建站公司、網(wǎng)站內(nèi)鏈、做網(wǎng)站、品牌網(wǎng)站建設(shè)、定制網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)

成都seo排名網(wǎng)站優(yōu)化