溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關怎么實現TKE及Kubernetes訪問權限控制，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
下面將會向你介紹騰訊云TKE平臺側的訪問控制、Kubernetes訪問控制鏈路，以及演示如何將平臺側賬號對接到Kubernetes內。
當你在使用騰訊云容器服務TKE（Tencent Kubernetes Engine）的時候，如果多人共用一個賬號的情況下，是否有遇到以下問題呢？
密鑰由多人共享，泄密風險高。
無法限制其他人的訪問權限，其他人誤操作易造成安全風險。
為了解決以上問題，騰訊云CAM（Cloud Access Management）提供了主賬號和子賬號的認證體系以及基于角色的權限控制。
而不同的子賬號對于TKE平臺側資源的控制粒度比較粗（cluster實例級別），又會遇到以下問題：
同一個集群由多子賬號可訪問，無法保證集群資源級別、命名空間級別的讀寫控制。
集群的高權限子賬戶無法對低權限子賬戶進行授權管理。
為了解決以上兩個問題，TKE針對平臺側資源、Kubernetes資源分別進行相應的訪問控制管理。
首先介紹下什么是平臺側資源，平臺側資源即Cluster資源、CVM資源、CLB資源、VPC資源等騰訊云資源，而訪問的用戶主要分為用戶和服務角色載體。
用戶就是我們平時登錄控制臺的主賬號、子賬號或者協作者賬號
服務角色是一種定義好帶有某些權限的角色，可以將這個角色賦予某個載體，可以是某個其他賬戶，也可以是騰訊云下一個產品的服務提供者，CAM會默認為產品提供一個預設的載體和默認的角色，例如TKE的默認角色就是TKE_QCSRole，而載體就是ccs.qcloud.com。
而這個角色有什么用處呢？舉個TKE的例子，比如TKE的service-controller會Watch集群內的Service資源，如果需要創建LoadBalance類型的Service，會通過云API購買并創建CLB資源，而service-controller是TKE平臺為用戶部署的，去訪問云API需要有身份，這個身份就是ccs.qcloud.com載體，而權限則需要用戶給載體授予一個角色，即TKE_QCSRole。只有用戶在授權TKE載體之后，TKE才可以通過服務扮演的方式代替用戶購買CLB。 下面我會簡單為你介紹如何給用戶授權，以及如何給TKE平臺授予角色。
TKE通過接入CAM，對集群的API接口級別進行權限細分，需要您在CAM控制臺對子賬戶進行不同的權限授予。同時TKE也在CAM側提供了預設的權限，提供您默認選擇，例如： 
也可以自定義策略，具體策略定制請參考CAM產品介紹文檔 
例如擁有只讀權限的子賬戶嘗試修改集群名稱，將會在API接口時校驗CAM權限失敗 
可以依據團隊的職責劃分好用戶組，將之前規劃好的自定義策略綁定到一個用戶組上，來方便的進行權限管理。 例如：有新同學入職時可方便的加入指定用戶組（如運維組），就可以獲取到該用戶組的權限，避免了繁瑣的權限配置操作。
使用TKE容器服務需要授予TKE平臺為您操作CVM\CLB\VPC\CBS等權限，所以首次訪問TKE控制臺需要確保同意授權，即創建預設角色TKE_QCSRole，此角色默認授予TKE載體，該載體會通過CAM獲取操作您集群的臨時密鑰，來進行相應的云API操作。
更多豐富的平臺側訪問控制用法請訪問CAM產品說明文檔
介紹完平臺側資源的訪問控制，我們再來看看TKE集群內的資源如何進行權限管理。當不同的子賬戶都擁有訪問同一個TKE Kubernetes集群權限之后，如何保證不同的子賬戶，對于集群內資源擁有不同的角色和權限呢？讓我們首先從社區的Kubernetes訪問鏈路來分析整個過程，從而向您介紹TKE是如何實現容器服務子賬戶對接Kubernetes認證授權體系的。
首先從宏觀的角度看下Kubernetes的請求鏈路是如何進行的。
圖片來源于k8s社區官網。
可以大概了解到一個請求的鏈路是依次通過Authentication（認證，簡稱Authn）、Authorization（授權，簡稱Authz）、AdmissionControl（準入控制），從而獲取到后端持久化的數據。
從圖中可以看到Authn、Authz、AdmissionControl是由多個模塊組成的，每個步驟都有多種方式構成的。
在進入認證模塊之前會將HTTP的Request進行構建context，而context中就包含了用戶的RequestInfo，userInfo、Verb、APIGroup、Version、Namespace、Resource、Path等。
帶著這些信息，下面我們來一次看下準入過程中的每個步驟吧。
認證的過程的證明user身份的過程。
Kubernetes中有兩類用戶，一類是ServiceAccount，一類是集群真實的用戶。
ServiceAccount賬戶是由Kubernetes提供API（資源）進行創建和管理的，ServiceAccount可以認為是特殊的Secret資源，可用戶集群內資源訪問APIServer的認證所用。通過可以通過mount的方式掛載到Pod內進行使用。
真實的用戶通常是從外部發起請求訪問APIServer，由管理員進行管理認證憑證，而Kubernetes本身不管理任何的用戶和憑證信息的，即所有的用戶都是邏輯上的用戶，無法通過API調用Kubernetes API進行創建真實用戶。
Kubernetes認證的方式眾多，常見的有TLS客戶端證書雙向認證、BearerToken認證、BasicAuthorization或認證代理（WebHook）
所有的認證方式都是以插件的形式串聯在認證鏈路中，只要有一種認證方式通過，即可通過認證模塊，且后續的認證方式不會被執行。
在此處參考一點點Kubernetes APIServer Authentication模塊的代碼，可以發現，任何的認證方式都是一下Interface的實現方式都是接收http Request請求，然后會返回一個user.Info的結構體，一個bool，以及一個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返回了用戶是否通過認證，false的話即返回無法通過認證，即返回401錯誤。
error則返回了當Request無法被檢查的錯誤，如果遇到錯誤則會繼續進行下一種注冊的方式進行認證。
如果認證通過，則會把user.Info寫入到到請求的context中，后續請求過程可以隨時獲取用戶信息，比如授權時進行鑒權。
下面我會以Kubernetes代碼中的認證方式順序，挑選幾項認證方式，并結合TKE開啟的認證方式來向你介紹TKE創建的Kubernetes集群默認的認證策略。
APIServer啟動參數--basic-auth-file=SOMEFILE指定basic認證的csv文件，在APIServer啟動之后修改此文件都不會生效，需要重啟APIServer來更新basic authentication的token。csv文件格式為：token,user,uid,"group1,group2,group3"。
請求時，需要指定HTTP Header中Authentication為Basic，并跟上Base64Encode(user:passward)值。
APIServer啟動參數--client-ca-file=SOMEFILE指定CA證書，而在TKE的K8s集群創建過程中，會對集群進行自簽名CA密鑰和證書用于管理，如果用戶下發的客戶端證書是由此CA證書的密鑰簽發的，那么就可以通過客戶端證書認證，并使用客戶端證書中的CommonName、Group字段分別作為Kubernetes的UserInfo中Username和Group信息。
目前TKE對接子賬戶都是通過自簽名的CA憑證進行簽發子賬戶Uin對應CN的客戶端證書。
Bearer Token的認證方式包含很多，比如啟動參數指定的、ServiceAccount（也是一種特殊的BeaerToken）、BootstrapToken、OIDCIssure、WebhookToken
APIServer啟動參數--token-auth-file=SOMEFILE指定Bearer Token認證的csv文件。和Basic Authentication方式相似，只不過請求APIServer時，指定的HTTP認證方式為Bearer方式。此Bearer后直接跟passward即可。csv文件格式為：password,user,uid,"group1,group2,group3"。
請求時，需要指定HTTP Header中Authentication為Bearer，并跟上Base64Encode(user:passward)值。
ServiceAccount也是一種特殊beaer token，ServiceAccount在Kubernetes中是一種資源，創建一個ServiceAccount資源之后默認會創建一個Secret資源，而Secret資源中就包含了一個JWT格式的Token字段，以Bearer Token的方式請求到Kube-APIServer，Kube-APIServer解析token中的部分user信息，以及validate以下ServiceAccount是否存在即可進行認證檢查。這種方式即之前提到的“兩種用戶”中常見的集群內認證方式，ServiceAccount，主要用于集群內資源訪問APIServer，但不限于集群內。
此項開關在Kubernetes v1.18版本中才為stable版本，此類Token是專門用來引導集群安裝使用的，需要配合controller-manager的TokenCleaner。
目前TKE默認開啟此配置。
OIDCToken的認證方式是結合OAuth3向身份提供方獲取ID Token來訪問APIServer。
如需要開啟此項功能，需要在APIServer的啟動參數中指定oidc的配置參數，例如--oidc-issuer-url指定oidc身份提供方的地址，--oidc-client-id指定身份提供方側的賬戶ID，--oidc-username-claim身份提供方的用戶名。
具體可參考Kubernetes官方文檔，目前公有云TKE沒有使用此參數對接騰訊云賬戶，因為涉及用戶需要主動登錄授權后才可返回Id Token，和當前官網交互沖突，可以在后續CLI工具中實現。
Webhook Token是一種hook的方式來校驗是否認證通過。
APIServer啟動參數--authentication-token-webhook-config-file及--authentication-token-webhook-cache-ttl來分別指定Webhook地址以及token的cache ttl。
若APiServer開啟此方式進行認證校驗，則在接受到用戶的Request之后，會包裝Bearer Token成一個TokenReview發送給WebHookServer，Server端接收到之后會進行校驗，并返回TokenReview接口，在status字段中進行反饋是否通過校驗通過和user.Info信息。
以上即為Kubernetes APIServer認證的幾種方式，TKE在每種認證方式都有支持。供用戶靈活使用。
目前TKE正在推使用x509客戶端證書方式來進行認證管理，以方便進行對接子賬戶的創建、授權管理、更新。
Kubernetes的授權模式支持一下幾種，和認證一樣，參考開始說的RequestInfo context，可知用戶Reqeust的context除了認證需要的userInfo，還有一些其他的字段例如Verb、APIGroup、APIVersion、Resource、Namespaces、Path……
授權就是判斷user是否擁有操作資源的相應權限。
Kubernetes支持AlwaysAllow、AlwaysDeny、Node、ABAC、RBAC、Webhook授權Mode，和認證一樣，只要有一種鑒權模塊通過，即可返回資源。
在這里重點介紹下面兩種方式
RBAC（Role-Based Access Control)，Kubernetes提供ClusterRole、Role資源，分別對應集群維度、Namespace維度角色權限管控，用戶可以自定義相應的ClusterRole、Role資源，綁定到已經認證的User之上。
如下tke:pod-reader ClusterRole，定義了該角色可以訪問core apigroup下面對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
通過以上的yaml配置，通過認證模塊到達授權模塊的requestInfo中userInfo信息是alex的請求，在授權模塊中走到RBAC授權模塊時，則會進行查詢集群的ClusterRole/ClusterRoleBinding信息。進行判斷是否擁有context相應操作的權限。
TKE的對接子賬戶的權限授權策略就是使用的Kubernetes原生的RBAC進行對子賬戶資源訪問控制，這樣符合原生，符合有K8s使用習慣的用戶。
Webhook模式是一種基于HTTP回調的方式，通過配置好授權webhook server地址。當APIServer接收到request的時候，會進行包裝SubjectAccessReview請求Webhook Server，Webhook Server會進行判斷是否可以訪問，然后返回allow信息。
以下是kubernetes社區一個例子，以供參考。
{
"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沒有考慮使用Webhook的模式，但是Webhook模式提供了強大的靈活性，比如對接CAM，實現K8s權限對接到平臺側，但是也有一定的風險和挑戰，比如依賴CAM的穩定性；請求延遲、緩存/TTL的配置；CAM action配置與K8s權限對應關系。此項授權模式仍然在考慮中，有需求的用戶可以反饋。
什么是admission controller？
In a nutshell, Kubernetes admission controllers are plugins that govern and enforce how the cluster is used.
Admission controllers是K8s的插件，用來管理和強制用戶如何來操作集群。
Admission controllers主要分為兩個phase，一個是mutating，一個是validating。這兩個階段都是在authn&authz之后的，mutating做的變更準入，就是會對request的resource，進行轉換，比如填充默認的requestLimit？而validating admission的意思就是驗證準入，比如校驗Pod副本數必須大于2。
API Server請求鏈路： 
ValidatingAdmissionWebhooksandMutatingAdmissionWebhooks, both of which are in beta status as of Kubernetes 1.13.
k8s支持30多種admission control 插件 ，而其中有兩個具有強大的靈活性，即ValidatingAdmissionWebhooks和MutatingAdmissionWebhooks，這兩種控制變換和準入以Webhook的方式提供給用戶使用，大大提高了靈活性，用戶可以在集群創建自定義的AdmissionWebhookServer進行調整準入策略。
TKE中1.10及以上版本也默認開啟了ValidatingAdmissionWebhooks、MutatingAdmissionWebhooks
了解更多Admission Controller參考這里
TKE權限實現對接子賬戶主要的方案是：x509客戶端認證+Kubernetes RBAC授權。
每個子賬戶都擁有單獨的屬于自己的客戶端證書，用于訪問KubernetesAPIServer。
用戶在使用TKE的新授權模式時，不同子賬戶在獲取集群訪問憑證時，即前臺訪問集群詳情頁或調用DescribeClusterKubeconfig時，會展示子賬戶自己的x509客戶端證書，此證書是每個集群的自簽名CA簽發的。
該用戶在控制臺訪問Kubernetes資源時，后臺默認使用此子賬戶的客戶端證書去訪問用戶Kubernetes APIServer。
支持子賬戶更新自己的證書。
支持主賬戶或集群tke:admin權限的賬戶進行查看、更新其他子賬戶證書。 
TKE控制臺通過Kubernetes原生的RBAC授權策略，對子賬戶提供細粒度的Kubernetes資源粒度權限控制。
提供授權管理頁，讓主賬號和集群創建者默認擁有管理員權限，可以對其他擁有此集群DescribeCluster Action權限的子賬戶進行權限管理。 
并提供預設的ClusterRole。
開發人員（tke:ns:dev）： 對所選命名空間下控制臺可見資源的讀寫權限， 需要選擇指定命名空間。
只讀用戶（tke:ns:ro）：對所選命名空間下控制臺可見資源的只讀權限， 需要選擇指定命名空間。 
管理員（tke:admin）：對所有命名空間下資源的讀寫權限， 對集群節點，存儲卷，命名空間，配額的讀寫權限， 可子賬號和權限的讀寫權限
運維人員（tke:ops）：對所有命名空間下控制臺可見資源的讀寫權限， 對集群節點，存儲卷，命名空間，配額的讀寫權限
開發人員（tke:dev）：對所有命名空間下控制臺可見資源的讀寫權限
受限人員（tke:ro）：對所有命名空間下控制臺可見資源的只讀權限
用戶自定義ClusterRole
所有命名空間維度：
指定命名空間維度：
所有預設的ClusterRole都將帶有固定label：cloud.tencent.com/tke-rbac-generated: "true"
所有預設的ClusterRoleBinding都帶有固定的annotations：cloud.tencent.com/tke-account-nickname: yournickname，及label：cloud.tencent.com/tke-account: "yourUIN" 
當然，除了TKE控制臺提供的預設授權策略，管理員也可以通過kubectl操作ClusterRole/Role來實現自定義角色的靈活配置細粒度權限，以及操作ClusterRoleBinding/RoleBinding進行權限綁定，綁定到任意的角色權限之上。
例如你想設置CAM側用戶組為productA產品的pod-dev的用戶權限只能夠get/list/watch product-a命名空間下的pods資源，則你可以這樣操作：
創建自定義ClusterRole/Role：dev-pod-reader，yaml實例如下，文件名為developer.yaml
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole # 這里使用ClusterRole可以復用給產品其他命名空間 metadata: name: pod-dev # pod-dev此角色為只能讀取pod的開發 rules: - apiGroups: [""] # "" 指定核心 API 組 resources: ["pods"] verbs: ["get", "watch", "list"]
使用kubectl或者通過TKE控制臺YAML創建資源創建上述Role 
綁定dev用戶組下的dev1、dev2、dev3用戶，綁定自定義權限pod-dev到product-a命名空間下 
從此dev1，dev2，dev3用戶則只能使用get/list/watch訪問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.
看完上述內容，你們對怎么實現TKE及Kubernetes訪問權限控制有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
