Kubernetes RBAC 101: 如何使用輔助命令加強安全控制
今天，我們繼續深入 Kubernetes 的世界，探索一些關鍵但不太顯眼的輔助命令，這些命令對于加強集群的安全控制至關重要。我將詳細介紹這些工具，它們能夠幫助我們更加有效地理解和管理 RBAC 策略，確保我們的 Kubernetes 環境的安全。
初始準備
在開始之前，我們在集群中創建了一個供開發者使用的命名空間 developer，并配置了必要的資源，這些步驟包括創建命名空間、服務賬號、服務賬號秘鑰（token），以及定義了具體的角色和角色綁定：
# 1. 創建 namespace
kubectl create ns developer
# 2. 創建 ServiceAccount
kubectl -n developer create serviceaccount owner
# 3. 創建服務賬號 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. 創建角色
kubectl create role Owner \
--resource pods,services,endpoints,secrets \
--verb get,list,watch \
-n developer
# 5. 將這個 Owner 角色的權限授予服務賬號 developer:owner
kubectl create rolebinding owner-binding \
--role=Owner \
--serviceaccount=developer:owner \
-n developerkubectl auth can-i
kubectl auth can-i 是一款實用的權限檢查工具，用于驗證用戶或服務賬戶是否有權限執行特定的 Kubernetes 操作。
好比說，我們可以驗證在初始化階段是否正確地限制了創建 Pod 的權限：
? kubectl --kubeconfig dev-config auth can-i create pod
no同樣，用戶也可以通過以下命令，來檢查自己是否在當前命名空間中擁有執行所有操作的權限：
? kubectl --kubeconfig dev-config auth can-i '*''*'
no管理員還可以使用 --as 參數來模擬任何服務賬戶的權限，進一步檢查權限設置：
? 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 實用，但它不支持復雜查詢，也不能提供完整的權限視圖。
作為集群管理員，如果我想要知道某個資源的特定操作都有哪些人擁有，它就更加做不到了 ??
kubectl-who-can
kubectl-who-can[1] 是一個進階工具，擴展了 Kubernetes 的原生功能，提供了對 RBAC 策略的深入分析，幫助管理員和開發者能夠快速了解誰有權限執行特定的操作。
它主要用于顯示哪些主體（用戶、組、服務賬戶等）有權限執行指定的動作（如創建、獲取、刪除）在特定的資源上。這是通過分析現有的 RBAC 配置來實現的。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install who-can如何使用？
例如，要找出哪些用戶或服務賬戶有權在特定命名空間中獲取 Pod，可以運行以下命令：
? 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這個命令將列出所有有權限在 developer 命名空間獲取 Pod 的主體（同時包括 namespace 級別和 cluster 級別）。這對于審核權限、準備安全報告或進行故障排除非常有用。
kubectl-who-can 的優勢
- 深入的權限分析： 與 K8s 自帶的 kubectl auth can-i 相比，kubectl-who-can 提供了更全面的視角，不僅能告知你是否有權限，還能指出集群中誰有這些權限。
- 安全審計： 這個工具對于安全團隊來說尤其重要，因為它有助于快速識別可能的權限過度分配。
- 簡化故障排除： 在調試權限問題時，能夠迅速找出有權限執行特定操作的所有主體，大大簡化了問題解決的過程。
局限性
盡管 kubectl-who-can 在權限管理和安全審計方面極為有效，但它的輸出僅基于當前的 RBAC 配置。
kubectl-rolesum
隨后，我們將轉向 kubectl-rolesum[2]，這是一個非常實用的第三方工具，提供了對角色和角色綁定的清晰視圖。
它的主要功能是匯總和顯示特定 K8s 實體（如用戶、組或服務賬戶）的角色權限，這對于驗證安全策略和進行故障排除非常重要。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install rolesum如何使用？
重新回到我們上面的用例，只要通過以下命令，它就能能夠提供比標準 kubectl 命令更加詳細和直觀的權限視圖。
? 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
實際應用案例
下面是一個實際應用案例截圖，我們可以清晰的看到這個服務被賦予了哪些權限。
圖片
在實際開發過程中，如果發現有些資源創建不出來或者其他權限異常，我們通過該工具能夠快速定位到原因。
同時它對于審計和合規性檢查也是一個寶貴的工具，因為它可以迅速展示權限的當前狀態。
局限性
kubectl-rolesum 的主要優勢在于其能夠提供比標準 kubectl 命令更加詳細和直觀的權限視圖。這對于管理復雜的 RBAC 策略特別有用。
但也有其局限性，就是它提供不了創建或修改這些角色的能力。
rbac-tool
最后，我們將探討 rbac-tool[3]，這是一個強大的多功能工具，它不僅簡化了 RBAC 策略的查詢，還幫助我們更容易地創建和管理這些策略。
安裝
我們可以通過 Krew 非常方便的安裝它：
kubectl krew install rbac-tool如何使用？
例如，要生成特定命名空間或整個集群的 RBAC 權限圖，可以使用以下命令：
kubectl rbac-tool viz --outformat dot \
&& cat rbac.dot | dot -Tpng > rbac.png && open rbac.png這個命令會創建一個 DOT 文件，該文件可以用圖形化工具（如 Graphviz）打開，展示角色和角色綁定之間的關系圖。
對于前面的例子，我們也可以使用如下命令用 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
提供查詢主體的權限：
? kubectl rbac-tool lookup -e '^owner.*'
SUBJECT | SUBJECT TYPE | SCOPE | NAMESPACE | ROLE
+---------+----------------+-------+-----------+-------+
owner | ServiceAccount | Role | developer | Ownerrbac-tool who-can
查看誰有執行特定操作的權限，類比 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
展示詳細的權限規則，類比 kubectl-rolesum 的能力，但在輸出可視化上，個人覺得 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]，它在對資源的訪問矩陣表現的也挺友好。
圖片
rbac-tool gen
生成自定義 RBAC 規則。類比 kubectl create role 和 kubectl create clusterrole，但是在靈活性和資源的指定上，在部分場景下會更加高效：
? 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 管理方面還是非常強大的。
將學習付諸實踐
在前面的章節中，我們詳細探討了 Kubernetes 中的 RBAC 工具和命令，了解了如何使用它們來做安全審計或者簡化故障排除。但是，光有工具并不足以保障安全，正確和高效地應用這些工具同樣重要。因此，接下來的部分，我將分享一些 “RBAC 最佳實踐” 關鍵的策略和建議：
1. 最小權限原則
在定義角色時，應遵循最小權限原則。只授予執行特定任務所需的最少權限，以最大限度地減少未授權操作的風險。這是確保安全的關鍵步驟。
2. 定期審計
定期回顧和審計集群里的 RBAC 配置，確保它們與組織的安全策略保持一致。刪除不必要或過度的權限，并根據需要更新角色。這有助于維持一個清晰、安全的權限結構。
3. 有效使用命名空間
利用命名空間邏輯地隔離不同的團隊或項目，并在命名空間級別執行 RBAC 策略。這樣可以更有效地管理權限，確保不同團隊或項目之間的操作隔離。
4. 測試 RBAC 策略
在非生產環境中徹底測試我們的 RBAC 策略，確保它們按預期工作，然后再應用到生產集群中。這是防止潛在問題影響生產環境的重要一步。
Conclusion
經過對這些強大工具的探索，我們不僅加深了對 Kubernetes RBAC 管理的理解，還獲得了加強集群安全的新視角。從 kubectl auth can-i 的基本權限檢查到 kubectl-who-can 的深入分析，再到 kubectl-rolesum 和 rbac-tool 的全面視圖，這些工具共同為我們構筑了一個更加透明、健壯的 Kubernetes 環境。
記住，Kubernetes 安全是一項持續的努力。借助這些工具和不斷的學習，我們能夠確保我們的集群既強大又安全。
