k8s 認證和權(quán)限控制
k8s 的認證機制是啥?
說到 k8s 的認證機制,其實之前咋那么也有提到過 ServiceAccouont ,以及相應(yīng)的 token ,證書 crt,和基于 HTTP 的認證等等
k8s 會使用如上幾種方式來獲取客戶端身份信息,不限于上面幾種
前面有說到 ApiServer 收到請求后,會去校驗客戶端是否有權(quán)限訪問,ApiServer 會去自身的認證插件中進行處理認證,進而到授權(quán)插件中進行授權(quán),例如這樣的:

ServiceAccount 相當(dāng)重要,之前我們說到過訪問 pod 元數(shù)據(jù)的時候,就提到過 ServiceAccount,以及相應(yīng)的掛載文件:
/var/run/secrets/kubernetes.io/serviceaccount/token
/var/run/secrets/kubernetes.io/serviceaccount/namespace
/var/run/secrets/kubernetes.io/serviceaccount/ca.crt

pod 就是通過發(fā)送上述的 token 文件來進行身份認證的,這是代表了運行的 pod 中的應(yīng)用程序的身份證明,每一個 pod 都是會有一個 ServiceAccoount 與之關(guān)聯(lián)的
我們可以理解 ServiceAccoount 不是什么也別的東西,也是 k8s 的其中一種資源而已,咱們可以寫 yaml 創(chuàng)建該 資源,當(dāng)然也是可以通過命令來創(chuàng)建 sa 資源的, sa 是 ServiceAccoount ?的縮寫
例如,我們可以通過命令 kubectl get sa
來查看 ServiceAccoount

一個 pod 只會對應(yīng)一個 SA,但是 一個 SA 是可以和多個 pod 關(guān)聯(lián)的,并且,我們需要清楚,這些都是得再同一個命名空間下的,例如畫一個簡圖來是表示一下

我們可以看到,同一個命名空間中
一個 SA 可以對應(yīng)多個 pod
一個 ns (namespace) 中可以有多個 ServiceAccount
一個 pod 只能關(guān)聯(lián) 一個 ServiceAccount
再來看看這個:

絕對不會存在 ns 4 的 pod ,會關(guān)聯(lián)到 ns 3 的 ServiceAccount, 不在同一個命名空間,根本無法操作
自行創(chuàng)建一個 SA
kubectl create sa xmt
創(chuàng)建一個 SA 名為 xmt

查看上述 xmt SA 的信息,k8s 默認給我們 xmt 賬戶生成了 token 和 secrets
我們可以查看 secrets 的內(nèi)容

我們可以通過在線的 jwt 解碼工具來查看這個 secrets,他是一個 JWT 編碼的信息
https://tooltt.com/jwt-decode/

我們解碼后,可以看到具體的信息
{
?"iss":?"kubernetes/serviceaccount",
?"kubernetes.io/serviceaccount/namespace":?"default",
?"kubernetes.io/serviceaccount/secret.name":?"xmt-token-kbv8b",
?"kubernetes.io/serviceaccount/service-account.name":?"xmt",
?"kubernetes.io/serviceaccount/service-account.uid":?"587fbca5-f20c-4421-a3fd-db21b76c7ac6",
?"sub":?"system:serviceaccount:default:xmt"
}
通過上述 secrets ?可以得到 namespace,secret.name,service-account.name,service-account.uid 等信息 ?,這個 uid 是唯一的
創(chuàng)建 pod 指定 SA
我們可以查看任意一個 pod 的詳情,也可以看到配置里面有 ServiceName

今天就到這里,學(xué)習(xí)所得,若有偏差,還請斧正
歡迎點贊,關(guān)注,收藏
朋友們,你的支持和鼓勵,是我堅持分享,提高質(zhì)量的動力

好了,本次就到這里
技術(shù)是開放的,我們的心態(tài),更應(yīng)是開放的。擁抱變化,向陽而生,努力向前行。
我是阿兵云原生,歡迎點贊關(guān)注收藏,下次見~