Kubernetes RBAC 101: 如何使用輔助命令加強(qiáng)安全控制
今天，我們繼續(xù)深入 Kubernetes 的世界，探索一些關(guān)鍵但不太顯眼的輔助命令，這些命令對于加強(qiáng)集群的安全控制至關(guān)重要。我將詳細(xì)介紹這些工具，它們能夠幫助我們更加有效地理解和管理 RBAC 策略，確保我們的 Kubernetes 環(huán)境的安全。
初始準(zhǔn)備
在開始之前，我們在集群中創(chuàng)建了一個(gè)供開發(fā)者使用的命名空間 developer，并配置了必要的資源，這些步驟包括創(chuàng)建命名空間、服務(wù)賬號、服務(wù)賬號秘鑰（token），以及定義了具體的角色和角色綁定：
# 1. 創(chuàng)建 namespace
kubectl create ns developer
# 2. 創(chuàng)建 ServiceAccount
kubectl -n developer create serviceaccount owner
# 3. 創(chuàng)建服務(wù)賬號 token 類型的 secret
cat << EOF | kubectl apply -f -
apiVersion: v1
kind: Secret
metadata:
name: owner-secret
namespace: developer
annotations:
kubernetes.io/service-account.name: owner
type: kubernetes.io/service-account-token
EOF
# 4. 創(chuàng)建角色
kubectl create role Owner \
--resource pods,services,endpoints,secrets \
--verb get,list,watch \
-n developer
# 5. 將這個(gè) Owner 角色的權(quán)限授予服務(wù)賬號 developer:owner
kubectl create rolebinding owner-binding \
--role=Owner \
--serviceaccount=developer:owner \
-n developerkubectl auth can-i
kubectl auth can-i 是一款實(shí)用的權(quán)限檢查工具，用于驗(yàn)證用戶或服務(wù)賬戶是否有權(quán)限執(zhí)行特定的 Kubernetes 操作。
好比說，我們可以驗(yàn)證在初始化階段是否正確地限制了創(chuàng)建 Pod 的權(quán)限：
? kubectl --kubeconfig dev-config auth can-i create pod
no同樣，用戶也可以通過以下命令，來檢查自己是否在當(dāng)前命名空間中擁有執(zhí)行所有操作的權(quán)限：
? kubectl --kubeconfig dev-config auth can-i '*''*'
no管理員還可以使用 --as 參數(shù)來模擬任何服務(wù)賬戶的權(quán)限，進(jìn)一步檢查權(quán)限設(shè)置：
? kubectl auth can-i \
get pods --as=system:serviceaccount:developer:owner -n developer
yes
? kubectl auth can-i \
create pod --as=system:serviceaccount:developer:owner -n developer
no局限性
盡管 kubectl auth can-i 實(shí)用，但它不支持復(fù)雜查詢，也不能提供完整的權(quán)限視圖。
作為集群管理員，如果我想要知道某個(gè)資源的特定操作都有哪些人擁有，它就更加做不到了 ??
kubectl-who-can
kubectl-who-can[1] 是一個(gè)進(jìn)階工具，擴(kuò)展了 Kubernetes 的原生功能，提供了對 RBAC 策略的深入分析，幫助管理員和開發(fā)者能夠快速了解誰有權(quán)限執(zhí)行特定的操作。
它主要用于顯示哪些主體（用戶、組、服務(wù)賬戶等）有權(quán)限執(zhí)行指定的動(dòng)作（如創(chuàng)建、獲取、刪除）在特定的資源上。這是通過分析現(xiàn)有的 RBAC 配置來實(shí)現(xiàn)的。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install who-can如何使用？
例如，要找出哪些用戶或服務(wù)賬戶有權(quán)在特定命名空間中獲取 Pod，可以運(yùn)行以下命令：
? kubectl who-can get pods -n developer
ROLEBINDING NAMESPACE SUBJECT TYPE SA-NAMESPACE
owner-binding developer owner ServiceAccount developer
CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE
cluster-admin system:masters Group
system:kube-scheduler system:kube-scheduler User
system:controller:deployment-controller deployment-controller ServiceAccount kube-system
system:controller:endpoint-controller endpoint-controller ServiceAccount kube-system
system:controller:endpointslice-controller endpointslice-controller ServiceAccount kube-system
system:controller:ephemeral-volume-controller ephemeral-volume-controller ServiceAccount kube-system
system:controller:generic-garbage-collector generic-garbage-collector ServiceAccount kube-system
system:controller:namespace-controller namespace-controller ServiceAccount kube-system
system:controller:node-controller node-controller ServiceAccount kube-system
system:controller:persistent-volume-binder persistent-volume-binder ServiceAccount kube-system
system:controller:statefulset-controller statefulset-controller ServiceAccount kube-system
system:controller:pvc-protection-controller pvc-protection-controller ServiceAccount kube-system
k3s-cloud-controller-manager k3s-cloud-controller-manager User kube-system
local-path-provisioner-bind local-path-provisioner-service-account ServiceAccount kube-system
system:k3s-controller system:k3s-controller User
cert-manager-controller-challenges cert-manager ServiceAccount cert-manager
xfs2-csi-driver xfs2-csi-driver-controller-sa ServiceAccount xfs2-csi-driver這個(gè)命令將列出所有有權(quán)限在 developer 命名空間獲取 Pod 的主體（同時(shí)包括 namespace 級別和 cluster 級別）。這對于審核權(quán)限、準(zhǔn)備安全報(bào)告或進(jìn)行故障排除非常有用。
kubectl-who-can 的優(yōu)勢
- 深入的權(quán)限分析： 與 K8s 自帶的 kubectl auth can-i 相比，kubectl-who-can 提供了更全面的視角，不僅能告知你是否有權(quán)限，還能指出集群中誰有這些權(quán)限。
- 安全審計(jì)： 這個(gè)工具對于安全團(tuán)隊(duì)來說尤其重要，因?yàn)樗兄诳焖僮R別可能的權(quán)限過度分配。
- 簡化故障排除： 在調(diào)試權(quán)限問題時(shí)，能夠迅速找出有權(quán)限執(zhí)行特定操作的所有主體，大大簡化了問題解決的過程。
局限性
盡管 kubectl-who-can 在權(quán)限管理和安全審計(jì)方面極為有效，但它的輸出僅基于當(dāng)前的 RBAC 配置。
kubectl-rolesum
隨后，我們將轉(zhuǎn)向 kubectl-rolesum[2]，這是一個(gè)非常實(shí)用的第三方工具，提供了對角色和角色綁定的清晰視圖。
它的主要功能是匯總和顯示特定 K8s 實(shí)體（如用戶、組或服務(wù)賬戶）的角色權(quán)限，這對于驗(yàn)證安全策略和進(jìn)行故障排除非常重要。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install rolesum如何使用？
重新回到我們上面的用例，只要通過以下命令，它就能能夠提供比標(biāo)準(zhǔn) kubectl 命令更加詳細(xì)和直觀的權(quán)限視圖。
? kubectl rolesum owner -n developer
ServiceAccount: developer/owner
Secrets:
Policies:
? [RB] developer/owner-binding ? [R] developer/Owner
Resource Name Exclude Verbs G L W C U P D DC
endpoints [*] [-] [-] ? ? ? ? ? ? ? ?
pods [*] [-] [-] ? ? ? ? ? ? ? ?
secrets [*] [-] [-] ? ? ? ? ? ? ? ?
services [*] [-] [-] ? ? ? ? ? ? ? ?以下是部分字段的描述：
- RB: RoleBinding
- R: Role
- CRB: ClusterRoleBinding
- CR: ClusterRole
- G: get
- L: list
- W: watch
- C: create
- U: udpate
- P: patch
- D: delete
- DC: deletecollection
實(shí)際應(yīng)用案例
下面是一個(gè)實(shí)際應(yīng)用案例截圖，我們可以清晰的看到這個(gè)服務(wù)被賦予了哪些權(quán)限。
圖片
在實(shí)際開發(fā)過程中，如果發(fā)現(xiàn)有些資源創(chuàng)建不出來或者其他權(quán)限異常，我們通過該工具能夠快速定位到原因。
同時(shí)它對于審計(jì)和合規(guī)性檢查也是一個(gè)寶貴的工具，因?yàn)樗梢匝杆僬故緳?quán)限的當(dāng)前狀態(tài)。
局限性
kubectl-rolesum 的主要優(yōu)勢在于其能夠提供比標(biāo)準(zhǔn) kubectl 命令更加詳細(xì)和直觀的權(quán)限視圖。這對于管理復(fù)雜的 RBAC 策略特別有用。
但也有其局限性，就是它提供不了創(chuàng)建或修改這些角色的能力。
rbac-tool
最后，我們將探討 rbac-tool[3]，這是一個(gè)強(qiáng)大的多功能工具，它不僅簡化了 RBAC 策略的查詢，還幫助我們更容易地創(chuàng)建和管理這些策略。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install rbac-tool如何使用？
例如，要生成特定命名空間或整個(gè)集群的 RBAC 權(quán)限圖，可以使用以下命令：
kubectl rbac-tool viz --outformat dot \
&& cat rbac.dot | dot -Tpng > rbac.png && open rbac.png這個(gè)命令會(huì)創(chuàng)建一個(gè) DOT 文件，該文件可以用圖形化工具（如 Graphviz）打開，展示角色和角色綁定之間的關(guān)系圖。
對于前面的例子，我們也可以使用如下命令用 chrome 打開，查看 owner 的情況。
? kubectl rbac-tool viz --include-subjects=owner && open -a "Google Chrome" rbac.html
[RAPID7-INSIGHTCLOUDSEC] Namespaces included '*'
[RAPID7-INSIGHTCLOUDSEC] Namespaces excluded 'kube-system'
[RAPID7-INSIGHTCLOUDSEC] Connecting to cluster ''
[RAPID7-INSIGHTCLOUDSEC] Generating Graph and Saving as 'rbac.html'效果如下所示：
圖片
kubectl rbac-tool lookup
提供查詢主體的權(quán)限：
? kubectl rbac-tool lookup -e '^owner.*'
SUBJECT | SUBJECT TYPE | SCOPE | NAMESPACE | ROLE
+---------+----------------+-------+-----------+-------+
owner | ServiceAccount | Role | developer | Ownerrbac-tool who-can
查看誰有執(zhí)行特定操作的權(quán)限，類比 kubectl-who-can 的能力：
? kubectl rbac-tool who-can get pod
TYPE | SUBJECT | NAMESPACE
+----------------+----------------------------------------+------------------------------------------------+
Group | system:masters |
ServiceAccount | cert-manager | cert-manager
ServiceAccount | deployment-controller | kube-system
ServiceAccount | endpoint-controller | kube-system
ServiceAccount | endpointslice-controller | kube-system
ServiceAccount | ephemeral-volume-controller | kube-system
ServiceAccount | generic-garbage-collector | kube-system
ServiceAccount | local-path-provisioner-service-account | kube-system
ServiceAccount | namespace-controller | kube-system
ServiceAccount | node-controller | kube-system
ServiceAccount | owner | developer
ServiceAccount | persistent-volume-binder | kube-system
ServiceAccount | pvc-protection-controller | kube-system
ServiceAccount | statefulset-controller | kube-system
ServiceAccount | user-sa | user-zone-4ef1aab6-3c45-4d37-bdb1-0b0c629b3b26
ServiceAccount | user-sa | user-zone-729281f1-46e8-4d63-8ab8-cfd895923bab
ServiceAccount | xfs2-csi-driver-controller-sa | xfs2-csi-driver
User | k3s-cloud-controller-manager | kube-system
User | system:k3s-controller |
User | system:kube-scheduler |rbac-tool policy-rules
展示詳細(xì)的權(quán)限規(guī)則，類比 kubectl-rolesum 的能力，但在輸出可視化上，個(gè)人覺得 kubectl-rolesum 要更加清晰一些：
? kubectl rbac-tool policy-rules -e '^owner'
TYPE | SUBJECT | VERBS | NAMESPACE | API GROUP | KIND | NAMES | NONRESOURCEURI | ORIGINATED FROM
+----------------+---------+-------+-----------+-----------+-----------+-------+----------------+-------------------------+
ServiceAccount | owner | get | developer | core | endpoints | | | Roles>>developer/Owner
ServiceAccount | owner | get | developer | core | pods | | | Roles>>developer/Owner
ServiceAccount | owner | get | developer | core | secrets | | | Roles>>developer/Owner
ServiceAccount | owner | get | developer | core | services | | | Roles>>developer/Owner
ServiceAccount | owner | list | developer | core | endpoints | | | Roles>>developer/Owner
ServiceAccount | owner | list | developer | core | pods | | | Roles>>developer/Owner
ServiceAccount | owner | list | developer | core | secrets | | | Roles>>developer/Owner
ServiceAccount | owner | list | developer | core | services | | | Roles>>developer/Owner
ServiceAccount | owner | watch | developer | core | endpoints | | | Roles>>developer/Owner
ServiceAccount | owner | watch | developer | core | pods | | | Roles>>developer/Owner
ServiceAccount | owner | watch | developer | core | secrets | | | Roles>>developer/Owner
ServiceAccount | owner | watch | developer | core | services | | | Roles>>developer/Owner以前用過 rakkess[4]，它在對資源的訪問矩陣表現(xiàn)的也挺友好。
圖片
rbac-tool gen
生成自定義 RBAC 規(guī)則。類比 kubectl create role 和 kubectl create clusterrole，但是在靈活性和資源的指定上，在部分場景下會(huì)更加高效：
? kubectl rbac-tool gen \
--generated-type=Role \
--allowed-verbs=get,list,watch \
--allowed-groups=, \
--deny-resources=bindings.,persistentvolumeclaims.,limitranges.,events.,replicationcontrollers.,configmaps.,resourcequotas.,podtemplates.,serviceaccounts.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
creationTimestamp: null
name: custom-role
namespace: mynamespace
rules:
- apiGroups:
- ""
resources:
- pods
- secrets
- endpoints
- services
verbs:
- get
- list
- watch相比較而言，rbac-tool 在 RBAC 管理方面還是非常強(qiáng)大的。
將學(xué)習(xí)付諸實(shí)踐
在前面的章節(jié)中，我們詳細(xì)探討了 Kubernetes 中的 RBAC 工具和命令，了解了如何使用它們來做安全審計(jì)或者簡化故障排除。但是，光有工具并不足以保障安全，正確和高效地應(yīng)用這些工具同樣重要。因此，接下來的部分，我將分享一些 “RBAC 最佳實(shí)踐” 關(guān)鍵的策略和建議：
1. 最小權(quán)限原則
在定義角色時(shí)，應(yīng)遵循最小權(quán)限原則。只授予執(zhí)行特定任務(wù)所需的最少權(quán)限，以最大限度地減少未授權(quán)操作的風(fēng)險(xiǎn)。這是確保安全的關(guān)鍵步驟。
2. 定期審計(jì)
定期回顧和審計(jì)集群里的 RBAC 配置，確保它們與組織的安全策略保持一致。刪除不必要或過度的權(quán)限，并根據(jù)需要更新角色。這有助于維持一個(gè)清晰、安全的權(quán)限結(jié)構(gòu)。
3. 有效使用命名空間
利用命名空間邏輯地隔離不同的團(tuán)隊(duì)或項(xiàng)目，并在命名空間級別執(zhí)行 RBAC 策略。這樣可以更有效地管理權(quán)限，確保不同團(tuán)隊(duì)或項(xiàng)目之間的操作隔離。
4. 測試 RBAC 策略
在非生產(chǎn)環(huán)境中徹底測試我們的 RBAC 策略，確保它們按預(yù)期工作，然后再應(yīng)用到生產(chǎn)集群中。這是防止?jié)撛趩栴}影響生產(chǎn)環(huán)境的重要一步。
Conclusion
經(jīng)過對這些強(qiáng)大工具的探索，我們不僅加深了對 Kubernetes RBAC 管理的理解，還獲得了加強(qiáng)集群安全的新視角。從 kubectl auth can-i 的基本權(quán)限檢查到 kubectl-who-can 的深入分析，再到 kubectl-rolesum 和 rbac-tool 的全面視圖，這些工具共同為我們構(gòu)筑了一個(gè)更加透明、健壯的 Kubernetes 環(huán)境。
記住，Kubernetes 安全是一項(xiàng)持續(xù)的努力。借助這些工具和不斷的學(xué)習(xí)，我們能夠確保我們的集群既強(qiáng)大又安全。
