騰訊云：一文讀懂TKE及Kubernetes訪問(wèn)權(quán)限控制

你有了解過(guò)Kubernetes的認(rèn)證授權(quán)鏈路嗎？是否對(duì)TKE的權(quán)限控制CAM策略、服務(wù)角色傻傻分不清楚？本文將會(huì)向你介紹騰訊云TKE平臺(tái)側(cè)的訪問(wèn)控制、Kubernetes訪問(wèn)控制鏈路，以及演示如何將平臺(tái)側(cè)賬號(hào)對(duì)接到Kubernetes內(nèi)。

當(dāng)你在使用騰訊云容器服務(wù)TKE（Tencent Kubernetes Engine）的時(shí)候，如果多人共用一個(gè)賬號(hào)的情況下，是否有遇到以下問(wèn)題呢？

·密鑰由多人共享，泄密風(fēng)險(xiǎn)高。

·無(wú)法限制其他人的訪問(wèn)權(quán)限，其他人誤操作易造成安全風(fēng)險(xiǎn)。

為了解決以上問(wèn)題，騰訊云CAM（Cloud Access Management）提供了主賬號(hào)和子賬號(hào)的認(rèn)證體系以及基于角色的權(quán)限控制。

而不同的子賬號(hào)對(duì)于TKE平臺(tái)側(cè)資源的控制粒度比較粗（cluster實(shí)例級(jí)別），又會(huì)遇到以下問(wèn)題：

·同一個(gè)集群由多子賬號(hào)可訪問(wèn)，無(wú)法保證集群資源級(jí)別、命名空間級(jí)別的讀寫控制。

·集群的高權(quán)限子賬戶無(wú)法對(duì)低權(quán)限子賬戶進(jìn)行授權(quán)管理。

為了解決以上兩個(gè)問(wèn)題，TKE針對(duì)平臺(tái)側(cè)資源、Kubernetes資源分別進(jìn)行相應(yīng)的訪問(wèn)控制管理。

平臺(tái)側(cè)訪問(wèn)控制

首先介紹下什么是平臺(tái)側(cè)資源，平臺(tái)側(cè)資源即Cluster資源、CVM資源、CLB資源、VPC資源等騰訊云資源，而訪問(wèn)的用戶主要分為用戶和服務(wù)角色載體。

1.用戶就是我們平時(shí)登錄控制臺(tái)的主賬號(hào)、子賬號(hào)或者協(xié)作者賬號(hào)

2.服務(wù)角色是一種定義好帶有某些權(quán)限的角色，可以將這個(gè)角色賦予某個(gè)載體，可以是某個(gè)其他賬戶，也可以是騰訊云下一個(gè)產(chǎn)品的服務(wù)提供者，CAM會(huì)默認(rèn)為產(chǎn)品提供一個(gè)預(yù)設(shè)的載體和默認(rèn)的角色，例如TKE的默認(rèn)角色就是TKE_QCSRole，而載體就是ccs.qcloud.com。

而這個(gè)角色有什么用處呢？舉個(gè)TKE的例子，比如TKE的service-controller會(huì)Watch集群內(nèi)的Service資源，如果需要?jiǎng)?chuàng)建LoadBalance類型的Service，會(huì)通過(guò)云API購(gòu)買并創(chuàng)建CLB資源，而service-controller是TKE平臺(tái)為用戶部署的，去訪問(wèn)云API需要有身份，這個(gè)身份就是ccs.qcloud.com載體，而權(quán)限則需要用戶給載體授予一個(gè)角色，即TKE_QCSRole。只有用戶在授權(quán)TKE載體之后，TKE才可以通過(guò)服務(wù)扮演的方式代替用戶購(gòu)買CLB。

下面我會(huì)簡(jiǎn)單為你介紹如何給用戶授權(quán)，以及如何給TKE平臺(tái)授予角色。

定制策略

TKE通過(guò)接入CAM，對(duì)集群的API接口級(jí)別進(jìn)行權(quán)限細(xì)分，需要您在CAM控制臺(tái)對(duì)子賬戶進(jìn)行不同的權(quán)限授予。同時(shí)TKE也在CAM側(cè)提供了預(yù)設(shè)的權(quán)限，提供您默認(rèn)選擇，例如：

也可以自定義策略，具體策略定制請(qǐng)參考CAM產(chǎn)品說(shuō)明文檔[1]

例如擁有只讀權(quán)限的子賬戶嘗試修改集群名稱，將會(huì)在API接口時(shí)校驗(yàn)CAM權(quán)限失敗。

劃分用戶組

可以依據(jù)團(tuán)隊(duì)的職責(zé)劃分好用戶組，將之前規(guī)劃好的自定義策略綁定到一個(gè)用戶組上，來(lái)方便的進(jìn)行權(quán)限管理。

例如：有新同學(xué)入職時(shí)可方便的加入指定用戶組（如運(yùn)維組），就可以獲取到該用戶組的權(quán)限，避免了繁瑣的權(quán)限配置操作。

授予TKE角色權(quán)限

使用TKE容器服務(wù)需要授予TKE平臺(tái)為您操作CVMCLBVPCCBS等權(quán)限，所以首次訪問(wèn)TKE控制臺(tái)需要確保同意授權(quán)，即創(chuàng)建預(yù)設(shè)角色TKE_QCSRole，此角色默認(rèn)授予TKE載體，該載體會(huì)通過(guò)CAM獲取操作您集群的臨時(shí)密鑰，來(lái)進(jìn)行相應(yīng)的云API操作。

更多

更多豐富的平臺(tái)側(cè)訪問(wèn)控制用法請(qǐng)?jiān)L問(wèn)CAM產(chǎn)品說(shuō)明文檔[1]

Kubernetes訪問(wèn)控制

介紹完平臺(tái)側(cè)資源的訪問(wèn)控制，我們?cè)賮?lái)看看TKE集群內(nèi)的資源如何進(jìn)行權(quán)限管理。

當(dāng)不同的子賬戶都擁有訪問(wèn)同一個(gè)TKE Kubernetes集群權(quán)限之后，如何保證不同的子賬戶，對(duì)于集群內(nèi)資源擁有不同的角色和權(quán)限呢？

讓我們首先從社區(qū)的Kubernetes訪問(wèn)鏈路來(lái)分析整個(gè)過(guò)程，從而向您介紹TKE是如何實(shí)現(xiàn)容器服務(wù)子賬戶對(duì)接Kubernetes認(rèn)證授權(quán)體系的。

Overview

首先從宏觀的角度看下Kubernetes的請(qǐng)求鏈路是如何進(jìn)行的。

圖片來(lái)源于K8s社區(qū)官網(wǎng)

可以大概了解到一個(gè)請(qǐng)求的鏈路是依次通過(guò)Authentication（認(rèn)證，簡(jiǎn)稱Authn）、Authorization（授權(quán)，簡(jiǎn)稱Authz）、AdmissionControl（準(zhǔn)入控制），從而獲取到后端持久化的數(shù)據(jù)。

從圖中可以看到Authn、Authz、AdmissionControl是由多個(gè)模塊組成的，每個(gè)步驟都有多種方式構(gòu)成的。

在進(jìn)入認(rèn)證模塊之前會(huì)將HTTP的Request進(jìn)行構(gòu)建context，而context中就包含了用戶的RequestInfo，userInfo、Verb、APIGroup、Version、Namespace、Resource、Path等。

帶著這些信息，下面我們來(lái)一次看下準(zhǔn)入過(guò)程中的每個(gè)步驟吧。

Kubernetes認(rèn)證

認(rèn)證的過(guò)程即是證明user身份的過(guò)程。

Kubernetes中有兩類用戶，一類是ServiceAccount，一類是集群真實(shí)的用戶：

·ServiceAccount賬戶是由Kubernetes提供API（資源）進(jìn)行創(chuàng)建和管理的，ServiceAccount可以認(rèn)為是特殊的Secret資源，可用戶集群內(nèi)資源訪問(wèn)APIServer的認(rèn)證所用。通過(guò)可以通過(guò)mount的方式掛載到Pod內(nèi)進(jìn)行使用。

·真實(shí)的用戶通常是從外部發(fā)起請(qǐng)求訪問(wèn)APIServer，由管理員進(jìn)行管理認(rèn)證憑證，而Kubernetes本身不管理任何的用戶和憑證信息的，即所有的用戶都是邏輯上的用戶，無(wú)法通過(guò)API調(diào)用Kubernetes API進(jìn)行創(chuàng)建真實(shí)用戶。

Kubernetes認(rèn)證的方式眾多，常見(jiàn)的有TLS客戶端證書(shū)雙向認(rèn)證、BearerToken認(rèn)證、BasicAuthorization或認(rèn)證代理（WebHook）。

所有的認(rèn)證方式都是以插件的形式串聯(lián)在認(rèn)證鏈路中，只要有一種認(rèn)證方式通過(guò)，即可通過(guò)認(rèn)證模塊，且后續(xù)的認(rèn)證方式不會(huì)被執(zhí)行。

在此處參考一點(diǎn)點(diǎn)Kubernetes APIServer Authentication模塊的代碼，可以發(fā)現(xiàn)，任何的認(rèn)證方式都是一下Interface的實(shí)現(xiàn)方式都是接收http Request請(qǐng)求，然后會(huì)返回一個(gè)user.Info的結(jié)構(gòu)體，一個(gè)bool，以及一個(gè)error。

//Request attempts to extract authentication information from a request and returns

//information about the current user and true if successful,false if not successful,

//or an error if the request could not be checked.

type Request interface{

AuthenticateRequest(req*http.Request)(user.Info,bool,error)

}

user.Info中包含了用戶的信息，包括UserName、UUID、Group、Extra。

bool返回了用戶是否通過(guò)認(rèn)證，false的話即返回?zé)o法通過(guò)認(rèn)證，即返回401錯(cuò)誤。

error則返回了當(dāng)Request無(wú)法被檢查的錯(cuò)誤，如果遇到錯(cuò)誤則會(huì)繼續(xù)進(jìn)行下一種注冊(cè)的方式進(jìn)行認(rèn)證。

如果認(rèn)證通過(guò)，則會(huì)把user.Info寫入到到請(qǐng)求的context中，后續(xù)請(qǐng)求過(guò)程可以隨時(shí)獲取用戶信息，比如授權(quán)時(shí)進(jìn)行鑒權(quán)。

下面我會(huì)以Kubernetes代碼中的認(rèn)證方式順序，挑選幾項(xiàng)認(rèn)證方式，并結(jié)合TKE開(kāi)啟的認(rèn)證方式來(lái)向你介紹TKE創(chuàng)建的Kubernetes集群默認(rèn)的認(rèn)證策略。

Basic Authentication

APIServer啟動(dòng)參數(shù)--basic-auth-file=SOMEFILE指定basic認(rèn)證的csv文件，在APIServer啟動(dòng)之后修改此文件都不會(huì)生效，需要重啟APIServer來(lái)更新basic authentication的token。csv文件格式為：token,user,uid,"group1,group2,group3"。

請(qǐng)求時(shí)，需要指定HTTP Header中Authentication為Basic，并跟上Base64Encode(user:passward)值。

x509客戶端證書(shū)

APIServer啟動(dòng)參數(shù)--client-ca-file=SOMEFILE指定CA證書(shū)，而在TKE的K8s集群創(chuàng)建過(guò)程中，會(huì)對(duì)集群進(jìn)行自簽名CA密鑰和證書(shū)用于管理，如果用戶下發(fā)的客戶端證書(shū)是由此CA證書(shū)的密鑰簽發(fā)的，那么就可以通過(guò)客戶端證書(shū)認(rèn)證，并使用客戶端證書(shū)中的CommonName、Group字段分別作為Kubernetes的UserInfo中Username和Group信息。

目前TKE對(duì)接子賬戶都是通過(guò)自簽名的CA憑證進(jìn)行簽發(fā)子賬戶Uin對(duì)應(yīng)CN的客戶端證書(shū)。

Bearer Token

Bearer Token的認(rèn)證方式包含很多，比如啟動(dòng)參數(shù)指定的、ServiceAccount（也是一種特殊的BeaerToken）、BootstrapToken、OIDCIssure、WebhookToken。

1.默認(rèn)指定Token csv文件

APIServer啟動(dòng)參數(shù)--token-auth-file=SOMEFILE指定Bearer Token認(rèn)證的csv文件。和Basic Authentication方式相似，只不過(guò)請(qǐng)求APIServer時(shí)，指定的HTTP認(rèn)證方式為Bearer方式。此Bearer后直接跟passward即可。csv文件格式為：password,user,uid,"group1,group2,group3"。

請(qǐng)求時(shí)，需要指定HTTP Header中Authentication為Bearer，并跟上Base64Encode(user:passward)值。

2.ServiceAccount

ServiceAccount也是一種特殊beaer token，ServiceAccount在Kubernetes中是一種資源，創(chuàng)建一個(gè)ServiceAccount資源之后默認(rèn)會(huì)創(chuàng)建一個(gè)Secret資源，而Secret資源中就包含了一個(gè)JWT格式的Token字段，以Bearer Token的方式請(qǐng)求到Kube-APIServer，Kube-APIServer解析token中的部分user信息，以及validate以下ServiceAccount是否存在即可進(jìn)行認(rèn)證檢查。

這種方式即之前提到的“兩種用戶”中常見(jiàn)的集群內(nèi)認(rèn)證方式，ServiceAccount，主要用于集群內(nèi)資源訪問(wèn)APIServer，但不限于集群內(nèi)。

3.BootstrapToken

此項(xiàng)開(kāi)關(guān)在Kubernetes v1.18版本中才為stable版本，此類Token是專門用來(lái)引導(dǎo)集群安裝使用的，需要配合controller-manager的TokenCleaner。

目前TKE默認(rèn)開(kāi)啟此配置。

4.OpenID Connect Tokens

OIDCToken的認(rèn)證方式是結(jié)合OAuth2向身份提供方獲取ID Token來(lái)訪問(wèn)APIServer。

如需要開(kāi)啟此項(xiàng)功能，需要在APIServer的啟動(dòng)參數(shù)中指定oidc的配置參數(shù)，例如--oidc-issuer-url指定oidc身份提供方的地址，--oidc-client-id指定身份提供方側(cè)的賬戶ID，--oidc-username-claim身份提供方的用戶名。

具體可參考Kubernetes官方文檔[2]，目前公有云TKE沒(méi)有使用此參數(shù)對(duì)接騰訊云賬戶，因?yàn)樯婕坝脩粜枰鲃?dòng)登錄授權(quán)后才可返回Id Token，和當(dāng)前官網(wǎng)交互沖突，可以在后續(xù)CLI工具中實(shí)現(xiàn)。

5.Webhook Token Server

Webhook Token是一種hook的方式來(lái)校驗(yàn)是否認(rèn)證通過(guò)。

APIServer啟動(dòng)參數(shù)--authentication-token-webhook-config-file及--authentication-token-webhook-cache-ttl來(lái)分別指定Webhook地址以及token的cache ttl。

若APiServer開(kāi)啟此方式進(jìn)行認(rèn)證校驗(yàn)，則在接受到用戶的Request之后，會(huì)包裝Bearer Token成一個(gè)TokenReview發(fā)送給WebHookServer，Server端接收到之后會(huì)進(jìn)行校驗(yàn)，并返回TokenReview接口，在status字段中進(jìn)行反饋是否通過(guò)校驗(yàn)通過(guò)和user.Info信息。

總結(jié)

以上即為Kubernetes APIServer認(rèn)證的幾種方式，TKE在每種認(rèn)證方式都有支持。供用戶靈活使用。

目前TKE正在推使用x509客戶端證書(shū)方式來(lái)進(jìn)行認(rèn)證管理，以方便進(jìn)行對(duì)接子賬戶的創(chuàng)建、授權(quán)管理、更新。

Kubernetes授權(quán)

Kubernetes的授權(quán)模式支持一下幾種，和認(rèn)證一樣，參考開(kāi)始說(shuō)的RequestInfo context，可知用戶Reqeust的context除了認(rèn)證需要的userInfo，還有一些其他的字段例如Verb、APIGroup、APIVersion、Resource、Namespaces、Path……

授權(quán)就是判斷user是否擁有操作資源的相應(yīng)權(quán)限。

Kubernetes支持AlwaysAllow、AlwaysDeny、Node、ABAC、RBAC、Webhook授權(quán)Mode，和認(rèn)證一樣，只要有一種鑒權(quán)模塊通過(guò)，即可返回資源。

在這里重點(diǎn)介紹下面兩種方式。

RBAC

RBAC（Role-Based Access Control)，Kubernetes提供ClusterRole、Role資源，分別對(duì)應(yīng)集群維度、Namespace維度角色權(quán)限管控，用戶可以自定義相應(yīng)的ClusterRole、Role資源，綁定到已經(jīng)認(rèn)證的User之上。

如下tke:pod-reader ClusterRole，定義了該角色可以訪問(wèn)core apigroup下面對(duì)pods資源的get/watch/list操作

apiVersion:rbac.authorization.k8s.io/v1

kind:ClusterRole

metadata:

name:tke:pod-reader

rules:

-apiGroups:[""]#""指定核心API組

resources:["pods"]

verbs:["get","watch","list"]

---

apiVersion:rbac.authorization.k8s.io/v1

#此角色綁定使得用戶"alex"能夠讀取"default"命名空間中的Pods

kind:ClusterRoleBinding

metadata:

name:alex-ClusterRole

subjects:

-kind:User

name:alex

apiGroup:rbac.authorization.k8s.io

roleRef:

kind:ClusterRole

name:tke:pod-reader#這里的名稱必須與你想要綁定的Role或ClusterRole名稱一致

apiGroup:rbac.authorization.k8s.io

通過(guò)以上的yaml配置，通過(guò)認(rèn)證模塊到達(dá)授權(quán)模塊的requestInfo中userInfo信息是alex的請(qǐng)求，在授權(quán)模塊中走到RBAC授權(quán)模塊時(shí)，則會(huì)進(jìn)行查詢集群的ClusterRole/ClusterRoleBinding信息。進(jìn)行判斷是否擁有context相應(yīng)操作的權(quán)限。

TKE的對(duì)接子賬戶的權(quán)限授權(quán)策略就是使用的Kubernetes原生的RBAC進(jìn)行對(duì)子賬戶資源訪問(wèn)控制，這樣符合原生，符合有K8s使用習(xí)慣的用戶。

WebHook

Webhook模式是一種基于HTTP回調(diào)的方式，通過(guò)配置好授權(quán)webhook server地址。當(dāng)APIServer接收到request的時(shí)候，會(huì)進(jìn)行包裝SubjectAccessReview請(qǐng)求Webhook Server，Webhook Server會(huì)進(jìn)行判斷是否可以訪問(wèn)，然后返回allow信息。

以下是kubernetes社區(qū)一個(gè)例子，以供參考。

{

  "apiVersion": "authorization.k8s.io/v1beta1",

  "kind": "SubjectAccessReview",

  "spec": {

    "resourceAttributes": {

      "namespace": "kittensandponies",

      "verb": "get",

      "group": "unicorn.example.org",

      "resource": "pods"

    },

    "user": "alex",

    "group": [

      "group1",

      "group2"

    ]

  }

}

{

  "apiVersion": "authorization.k8s.io/v1beta1",

  "kind": "SubjectAccessReview",

  "status": {

    "allowed": true

  }

}

目前TKE沒(méi)有考慮使用Webhook的模式，但是Webhook模式提供了強(qiáng)大的靈活性，比如對(duì)接CAM，實(shí)現(xiàn)K8s權(quán)限對(duì)接到平臺(tái)側(cè)，但是也有一定的風(fēng)險(xiǎn)和挑戰(zhàn)，比如依賴CAM的穩(wěn)定性；請(qǐng)求延遲、緩存/TTL的配置；CAM action配置與K8s權(quán)限對(duì)應(yīng)關(guān)系。此項(xiàng)授權(quán)模式仍然在考慮中，有需求的用戶可以反饋。

準(zhǔn)入控制

什么是admission controller？

In a nutshell,Kubernetes admission controllers are plugins that govern and enforce how the cluster is used.

Admission controllers是K8s的插件，用來(lái)管理和強(qiáng)制用戶如何來(lái)操作集群。

Admission controllers主要分為兩個(gè)phase，一個(gè)是mutating，一個(gè)是validating。這兩個(gè)階段都是在authn&authz之后的，mutating做的變更準(zhǔn)入，就是會(huì)對(duì)request的resource，進(jìn)行轉(zhuǎn)換，比如填充默認(rèn)的requestLimit？而validating admission的意思就是驗(yàn)證準(zhǔn)入，比如校驗(yàn)Pod副本數(shù)必須大于2。

API Server請(qǐng)求鏈路：

ValidatingAdmissionWebhooks and MutatingAdmissionWebhooks,both of which are in beta status as of Kubernetes 1.13.

K8s支持30多種admission control插件，其中有兩個(gè)具有強(qiáng)大的靈活性，即ValidatingAdmissionWebhooks和MutatingAdmissionWebhooks，這兩種控制變換和準(zhǔn)入以Webhook的方式提供給用戶使用，大大提高了靈活性，用戶可以在集群創(chuàng)建自定義的AdmissionWebhookServer進(jìn)行調(diào)整準(zhǔn)入策略。

TKE中1.10及以上版本也默認(rèn)開(kāi)啟了ValidatingAdmissionWebhooks、MutatingAdmissionWebhooks

了解更多Admission Controller參考準(zhǔn)入控制器[3]

kubernetes權(quán)限對(duì)接子賬戶

TKE權(quán)限實(shí)現(xiàn)對(duì)接子賬戶主要的方案是：x509客戶端認(rèn)證+Kubernetes RBAC授權(quán)。

認(rèn)證

每個(gè)子賬戶都擁有單獨(dú)的屬于自己的客戶端證書(shū)，用于訪問(wèn)KubernetesAPIServer。

·用戶在使用TKE的新授權(quán)模式時(shí)，不同子賬戶在獲取集群訪問(wèn)憑證時(shí)，即前臺(tái)訪問(wèn)集群詳情頁(yè)或調(diào)用DescribeClusterKubeconfig時(shí)，會(huì)展示子賬戶自己的x509客戶端證書(shū)，此證書(shū)是每個(gè)集群的自簽名CA簽發(fā)的。

·該用戶在控制臺(tái)訪問(wèn)Kubernetes資源時(shí)，后臺(tái)默認(rèn)使用此子賬戶的客戶端證書(shū)去訪問(wèn)用戶Kubernetes APIServer。

·支持子賬戶更新自己的證書(shū)。

·支持主賬戶或集群tke:admin權(quán)限的賬戶進(jìn)行查看、更新其他子賬戶證書(shū)。

授權(quán)

TKE控制臺(tái)通過(guò)Kubernetes原生的RBAC授權(quán)策略，對(duì)子賬戶提供細(xì)粒度的Kubernetes資源粒度權(quán)限控制。

·提供授權(quán)管理頁(yè)，讓主賬號(hào)和集群創(chuàng)建者默認(rèn)擁有管理員權(quán)限，可以對(duì)其他擁有此集群DescribeCluster Action權(quán)限的子賬戶進(jìn)行權(quán)限管理。

·并提供預(yù)設(shè)的ClusterRole。

所有命名空間維度：

a.管理員（tke:admin）：對(duì)所有命名空間下資源的讀寫權(quán)限，對(duì)集群節(jié)點(diǎn)，存儲(chǔ)卷，命名空間，配額的讀寫權(quán)限，可子賬號(hào)和權(quán)限的讀寫權(quán)限

b.運(yùn)維人員（tke:ops）：對(duì)所有命名空間下控制臺(tái)可見(jiàn)資源的讀寫權(quán)限，對(duì)集群節(jié)點(diǎn)，存儲(chǔ)卷，命名空間，配額的讀寫權(quán)限

c.開(kāi)發(fā)人員（tke:dev）：對(duì)所有命名空間下控制臺(tái)可見(jiàn)資源的讀寫權(quán)限

d.受限人員（tke:ro）：對(duì)所有命名空間下控制臺(tái)可見(jiàn)資源的只讀權(quán)限

e.用戶自定義ClusterRole

指定命名空間維度：

a.開(kāi)發(fā)人員（tke:ns:dev）：對(duì)所選命名空間下控制臺(tái)可見(jiàn)資源的讀寫權(quán)限，需要選擇指定命名空間。

b.只讀用戶（tke:ns:ro）：對(duì)所選命名空間下控制臺(tái)可見(jiàn)資源的只讀權(quán)限，需要選擇指定命名空間。

·所有預(yù)設(shè)的ClusterRole都將帶有固定label：cloud.tencent.com/tke-rbac-generated:"true"

·所有預(yù)設(shè)的ClusterRoleBinding都帶有固定的annotations：cloud.tencent.com/tke-account-nickname:yournickname，及l(fā)abel：cloud.tencent.com/tke-account:"yourUIN"

更多

當(dāng)然，除了TKE控制臺(tái)提供的預(yù)設(shè)授權(quán)策略，管理員也可以通過(guò)kubectl操作ClusterRole/Role來(lái)實(shí)現(xiàn)自定義角色的靈活配置細(xì)粒度權(quán)限，以及操作ClusterRoleBinding/RoleBinding進(jìn)行權(quán)限綁定，綁定到任意的角色權(quán)限之上。

例如你想設(shè)置CAM側(cè)用戶組為productA產(chǎn)品的pod-dev的用戶權(quán)限只能夠get/list/watch product-a命名空間下的pods資源，則你可以這樣操作：

·創(chuàng)建自定義ClusterRole/Role：dev-pod-reader，yaml實(shí)例如下，文件名為developer.yaml

apiVersion:rbac.authorization.k8s.io/v1

kind:ClusterRole#這里使用ClusterRole可以復(fù)用給產(chǎn)品其他命名空間

metadata:

name:pod-dev#pod-dev此角色為只能讀取pod的開(kāi)發(fā)

rules:

-apiGroups:[""]#""指定核心API組

resources:["pods"]

verbs:["get","watch","list"]

·使用kubectl或者通過(guò)TKE控制臺(tái)YAML創(chuàng)建資源創(chuàng)建上述Role

·綁定dev用戶組下的dev1、dev2、dev3用戶，綁定自定義權(quán)限pod-dev到product-a命名空間下

·從此dev1，dev2，dev3用戶則只能使用get/list/watch訪問(wèn)product-a下的pods資源

$kubectl--kubeconfig=./dev.kubeconfig get pods

Error from server(Forbidden):pods is forbidden:User"10000001xxxx-1592395536"cannot list resource"pods"in API group""in the namespace"default"

$kubectl--kubeconfig=./dev.kubeconfig get pods-n product-a

No resources found.

參考資料

[1]CAM產(chǎn)品說(shuō)明文檔:https://cloud.tencent.com/document/product/598/17848

[2]Kubernetes官方文檔:https://kubernetes.io/docs/reference/access-authn-authz/authentication/#openid-connect-tokens

[3]準(zhǔn)入控制器:https://kubernetes.io/zh/docs/reference/access-authn-authz/admission-controllers/

[4]kubernetes認(rèn)證介紹:https://kubernetes.io/docs/reference/access-authn-authz/authentication/

[5]kubernetes授權(quán)介紹:https://kubernetes.io/docs/reference/access-authn-authz/authorization/

[6]kubernetesRBAC介紹:https://kubernetes.io/docs/reference/access-authn-authz/rbac/