/ taohigo.com / 0浏览

一文讀懂 TKE 及 Kubernetes 訪問權限控制

當你在使用騰訊雲容器服務TKE(Tencent Kubernetes Engine)的時候,如果多人共用一個賬號的情況下,是否有遇到以下問題呢?

  • 密鑰由多人共享,泄密風險高。
  • 無法限制其他人的訪問權限,其他人誤操作易造成安全風險。

為瞭解決以上問題,騰訊雲CAM(Cloud Access Management)提供瞭主賬號和子賬號的認證體系以及基於角色的權限控制。

而不同的子賬號對於TKE平臺側資源的控制粒度比較粗(cluster實例級別),又會遇到以下問題:

  • 同一個集群由多子賬號可訪問,無法保證集群資源級別、命名空間級別的讀寫控制。
  • 集群的高權限子賬戶無法對低權限子賬戶進行授權管理。

為瞭解決以上兩個問題,TKE針對平臺側資源Kubernetes資源分別進行相應的訪問控制管理。

平臺側訪問控制

首先介紹下什麼是平臺側資源,平臺側資源即Cluster資源CVM資源CLB資源VPC資源等騰訊雲資源,而訪問的用戶主要分為用戶服務角色載體

  1. 用戶就是我們平時登錄控制臺的主賬號、子賬號或者協作者賬號
  2. 服務角色是一種定義好帶有某些權限的角色,可以將這個角色賦予某個載體,可以是某個其他賬戶,也可以是騰訊雲下一個產品的服務提供者,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容器服務需要授予TKE平臺為您操作CVMCLBVPCCBS等權限,所以首次訪問TKE控制臺需要確保同意授權,即創建預設角色TKE_QCSRole,此角色默認授予TKE載體,該載體會通過CAM獲取操作您集群的臨時密鑰,來進行相應的雲API操作。

更多

更多豐富的平臺側訪問控制用法請訪問CAM產品說明文檔

Kubernetes訪問控制

介紹完平臺側資源的訪問控制,我們再來看看TKE集群內的資源如何進行權限管理。當不同的子賬戶都擁有訪問同一個TKE Kubernetes集群權限之後,如何保證不同的子賬戶,對於集群內資源擁有不同的角色和權限呢?讓我們首先從社區的Kubernetes訪問鏈路來分析整個過程,從而向您介紹TKE是如何實現容器服務子賬戶對接Kubernetes認證授權體系的。

Overview

首先從宏觀的角度看下Kubernetes的請求鏈路是如何進行的。圖片來源於k8s社區官網。

可以大概瞭解到一個請求的鏈路是依次通過Authentication(認證,簡稱Authn)、Authorization(授權,簡稱Authz)、AdmissionControl(準入控制),從而獲取到後端持久化的數據。

從圖中可以看到Authn、Authz、AdmissionControl是由多個模塊組成的,每個步驟都有多種方式構成的。

在進入認證模塊之前會將HTTP的Request進行構建context,而context中就包含瞭用戶的RequestInfo,userInfo、Verb、APIGroup、Version、Namespace、Resource、Path等。

帶著這些信息,下面我們來一次看下準入過程中的每個步驟吧。

Kubernetes認證

認證的過程的證明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請求,然後會返回一個http://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)
}

編碼日志 | 這些疾病該如何編碼?快來學習!
不小心刪除微信APP,重新安裝後聊天記錄怎麼恢復?
不小心刪除微信APP,重新安裝後聊天記錄怎麼恢復?
會銷模式之品鑒會模式的詳細解讀
會銷模式之品鑒會模式的詳細解讀
什麼是超融合服務器
2023年北京移動寬帶資費一覽表(全傢享套餐5折優惠寬帶免費用)可攜號轉網辦理,低消51元送1000M寬帶
2023年北京移動寬帶資費一覽表(全傢享套餐5折優惠寬帶免費用)可攜號轉網辦理,低消51元送1000M寬帶
廣聯達實操:如何快速繪制模型?GTJ快速建模技巧!
廣聯達實操:如何快速繪制模型?GTJ快速建模技巧!

0

  1. This post has no comment yet

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注