在 Kubernetes（K8s）的世界裡，根據角色的存取控制（RBAC, Role-Based Access Control）是守護叢集安全的重要防線。透過 RBAC，管理員可以精細地控制使用者和服務帳戶對 Kubernetes 資源的存取許可權。然而，在 RBAC 的許可權體系中，存在著三個經常被忽略，但卻極具威脅的許可權：提升（Escalate）、繫結（Bind）和模仿（Impersonate）。這些許可權如果被濫用，可能繞過現有的角色限制，導致未經授權的存取、機密資料外洩，甚至完全控制整個叢集。

本文將深入剖析這三個許可權的運作機制、潛在風險，並提供相應的防禦策略，幫助您強化 Kubernetes 環境的安全態勢。

1. RBAC 角色與動詞：基礎概念回顧

在探討「提升」、「繫結」和「模仿」之前，讓我們先快速回顧 RBAC 的核心概念：角色（Role）與動詞（Verb）。

角色（Role）： 定義在特定名稱空間（Namespace）內，對 Kubernetes 資源的存取許可權。角色由一系列規則組成，每個規則指定了可對特定資源執行的操作。
動詞（Verb）： 代表可以對 Kubernetes 資源執行的操作。常見的動詞包括 get（讀取）、list（列出）、watch（監控）、create（建立）、update（更新）和 delete（刪除）等。

例如，以下的角色授予對 default 名稱空間中 Pod 的讀取許可權：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

2. 三個鮮為人知的 RBAC 許可權

除了常見的動詞之外，Kubernetes RBAC 還提供了一些更細緻與強大的許可權控制機制，其中最值得關注的就是「提升」、「繫結」和「模仿」這三個動詞。

2.1 提升（Escalate）：角色許可權的自我擴張

escalate 動詞允許使用者或服務帳戶修改角色（Role）和叢集角色（ClusterRole）的許可權。這意味著，即使用者一開始沒有修改角色許可權的許可權，只要他擁有 escalate 許可權，就可以透過編輯角色來擴大自己的許可權範圍。

2.1.1 風險分析

許可權蔓延： 擁有 escalate 許可權的使用者可以不斷提升自己的許可權，最終可能獲得對整個叢集的完全控制。
安全漏洞： 如果 escalate 許可權被濫用，攻擊者可以利用它來修改角色，為自己或其他惡意使用者授予未經授權的存取許可權。

2.1.2 防禦策略

嚴格限制 escalate 許可權： 僅授予真正需要修改角色許可權的使用者或服務帳戶。
定期審查角色許可權： 檢查角色是否被未經授權地修改，及時發現並糾正任何異常情況。
使用 Kubernetes 稽核日誌（Audit Log）： 監控對角色和叢集角色的修改操作，以便追蹤潛在的安全事件。

2.2 繫結（Bind）：角色繫結的自由建立

bind 動詞允許使用者或服務帳戶建立角色繫結（RoleBinding）和叢集角色繫結（ClusterRoleBinding）。角色繫結將角色中定義的許可權授予特定的使用者、群組或服務帳戶。擁有 bind 許可權意味著，使用者可以將自己或其他使用者繫結到具有特定許可權的角色上，從而獲得相應的存取許可權。

2.2.1 風險分析

許可權提升： 擁有 bind 許可權的使用者可以將自己繫結到具有高許可權的角色上，例如 cluster-admin，從而獲得對整個叢集的完全控制。
橫向移動： 攻擊者可以利用 bind 許可權將自己繫結到具有存取敏感資源的角色上，例如可以讀取金鑰（Secret）的角色，從而實作橫向移動並竊取機密資料。

2.2.2 防禦策略

限制 bind 許可權： 僅授予需要管理角色繫結的使用者或服務帳戶。
使用名稱空間隔離： 將不同的應用程式和服務佈署到不同的名稱空間中，並限制角色繫結的作用範圍，以降低許可權提升的風險。
定期審查角色繫結： 檢查角色繫結是否符合預期，是否存在未經授權的繫結關係。

2.3 模仿（Impersonate）：身份偽裝的潛在威脅

impersonate 動詞允許使用者或服務帳戶模擬其他使用者或服務帳戶的身份。這意味著，擁有 impersonate 許可權的使用者可以像被模擬者一樣存取 Kubernetes 資源，並執行相應的操作。

2.3.1 風險分析

身份盜用： 攻擊者可以利用 impersonate 許可權模擬具有高許可權的使用者或服務帳戶，從而執行未經授權的操作，例如佈署惡意程式碼、竊取機密資料或破壞系統。
繞過稽核： 因為所有操作都以被模擬者的身份執行，所以追蹤攻擊者的真實身份變得更加困難。

2.3.2 防禦策略

嚴格控制 impersonate 許可權： impersonate 許可權應該被視為高風險許可權，僅在必要時授予，並進行嚴格的審查。
啟用稽核日誌： 監控所有 impersonate 操作，記錄模擬者和被模擬者的身份，以便追蹤潛在的安全事件。
使用雙重驗證： 對於具有 impersonate 許可權的使用者，強制使用雙重驗證，以防止身份被盜用。

3. 案例分析：利用 `escalate` 許可權提升許可權

為了更深入地理解 escalate 許可權的風險，讓我們來看一個實際的案例。假設一個使用者擁有對 rbac 名稱空間中 Pod 和角色的讀取許可權，但他沒有修改角色的許可權。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "roles"]
  verbs: ["get", "watch", "list"]

如果我們授予該使用者 escalate 許可權，他就可以修改 pod-reader 角色，新增新的許可權，例如 update 和 delete，從而獲得對 Pod 和角色的完全控制權。

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: rbac
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods", "roles"]
  verbs: ["get", "watch", "list", "update", "delete"]

這個案例清楚地展示了 escalate 許可權的危險性，它可以讓使用者繞過現有的角色限制，實作許可權的自我擴張。

Kubernetes RBAC 提供了強大的許可權控制機制，但如果不加以正確設定和管理，也可能帶來嚴重的安全風險。escalate、bind 和 impersonate 這三個許可權雖然不常被提及，但卻極具威脅，可能被濫用以繞過角色限制、竊取機密資料或完全控制整個叢集。

因此，我們必須深入理解這些許可權的運作機制和潛在風險，並採取相應的防禦策略，包括嚴格限制許可權授予、定期審查角色許可權、啟用稽核日誌和使用雙重驗證等。只有這樣，才能確保 Kubernetes 環境的安全，並保護我們的應用程式和資料免受攻擊。身為 Kubernetes 管理者，應時刻保持警惕，定期檢視和調整 RBAC 設定，以應對不斷演變的安全威脅，確保叢集的安全性與穩定性。

Kubernetes RBAC：許可權提升防禦與實踐

在 Kubernetes 環境中，RBAC（Role-Based Access Control，根據角色的存取控制）是控制資源存取許可權的核心機制。然而，不當的 RBAC 設定可能導致許可權提升，使得未授權的使用者或服務帳戶獲得過高的許可權，進而威脅叢集安全。本文將探討 Kubernetes RBAC 許可權提升的風險，並提供實用的防禦措施與最佳實踐。

瞭解 Kubernetes RBAC 的許可權邊界

Kubernetes RBAC 透過 Role（角色）和 RoleBinding（角色繫結）來定義和分配許可權。Role 定義了一組資源上的操作許可權（例如，讀取、更新、刪除），而 RoleBinding 則將這些許可權授予特定的使用者、群組或服務帳戶。

理解 RBAC 的許可權邊界至關重要。Kubernetes 的設計原則之一是「最小許可權原則」（Principle of Least Privilege），這意味著使用者或服務帳戶應該只被授予執行其任務所需的最小許可權。若違反此原則，可能導致許可權提升的風險。

許可權提升的風險情境

以下是一些常見的許可權提升風險情境：

允許更新 Role 或 RoleBinding： 如果使用者或服務帳戶被允許更新 Role 或 RoleBinding 資源，他們可能修改這些資源，將自己繫結到具有更高許可權的角色，從而實作許可權提升。
允許建立 Pod 並掛載 ServiceAccount Token： 如果使用者或服務帳戶被允許建立 Pod，並掛載具有高許可權的 ServiceAccount Token，他們可以透過 Pod 存取該 ServiceAccount 的許可權。
濫用 ClusterRole 和 ClusterRoleBinding： ClusterRole 和 ClusterRoleBinding 用於定義叢集範圍的許可權。不當使用這些資源可能導致整個叢集的許可權洩露。

防禦許可權提升的策略

以下是一些防禦 Kubernetes RBAC 許可權提升的策略：

1. 實施最小許可權原則

精確定義 Role： 確保每個 Role 只包含執行特定任務所需的最小許可權。避免使用萬用字元（*）授予過於寬泛的許可權。
限制 RoleBinding 的範圍： 盡可能將 RoleBinding 的範圍限制在特定的名稱空間（Namespace）內，避免跨名稱空間的許可權洩露。
定期審查 RBAC 設定： 定期審查現有的 RBAC 設定，確保其仍然符合最小許可權原則，並移除不再需要的許可權。

2. 限制 Role 和 RoleBinding 的更新許可權

禁止普通使用者更新 Role 和 RoleBinding： 只有具有特定管理許可權的使用者或群組才能更新 Role 和 RoleBinding 資源。
使用 PodSecurityPolicy 或 PodSecurityAdmission 限制 Pod 的行為： 透過 PodSecurityPolicy（在 Kubernetes 1.21 已棄用，建議使用 PodSecurityAdmission）或其他類別似機制，限制 Pod 掛載 ServiceAccount Token 的能力，防止未授權的許可權存取。

3. 監控和警示

監控 RBAC 資源的變更： 建立監控系統，追蹤 Role 和 RoleBinding 資源的變更。當發現未授權的變更時，立即發出警示。
稽核日誌： 啟用 Kubernetes 稽核日誌，記錄所有 API 請求。定期分析稽核日誌，檢測潛在的許可權提升行為。

實用範例：防止 Role 更新的許可權提升

以下範例展示如何防止使用者透過更新 Role 資源來提升許可權。

假設我們有一個名為 developer 的 Role，允許開發者在 development 名稱空間中執行常見的操作：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer
  namespace: development
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

為了防止開發者修改此 Role，我們可以建立另一個 Role，限制他們更新 rbac.authorization.k8s.io API 群組下的 roles 資源：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: developer-no-role-update
  namespace: development
rules:
- apiGroups: ["", "apps"]
  resources: ["pods", "deployments", "services"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["roles"]
  verbs: ["get", "list", "watch"] # 禁止 update, patch, delete

然後，我們可以建立一個 RoleBinding，將開發者繫結到 developer-no-role-update 這個 Role：

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: developer-binding
  namespace: development
subjects:
- kind: User
  name: jane.doe # 開發者使用者名稱
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: developer-no-role-update
  apiGroup: rbac.authorization.k8s.io

透過以上設定，開發者 jane.doe 可以在 development 名稱空間中執行常見的操作，但無法更新 Role 資源，從而防止了潛在的許可權提升風險。

Kubernetes RBAC 是保護叢集安全的重要機制。然而，不當的 RBAC 設定可能導致許可權提升，使得未授權的使用者或服務帳戶獲得過高的許可權。

玄貓（BlackCat）建議您實施最小許可權原則，限制 Role 和 RoleBinding 的更新許可權，並建立完善的監控和警示系統，及早發現並應對潛在的許可權提升風險，確保 Kubernetes 叢集的安全性。只有透過持續的監控、稽核和策略調整，才能夠有效地保護 Kubernetes 叢集，防止未授權的存取和潛在的安全威脅。

  verbs: ["escalate", "bind"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterrolebindings"]
  resourceNames: ["edit", "view"]
  verbs: ["create"]

使用外部工具監控角色使用像SaaS工具，例如Aqua Security, Datadog, Prisma Cloud可以幫助監控角色。這些工具可以幫助您發現異常模式，並提供關於誰正在存取哪些資源的額外可見性。

在本文中，我們討論了在根據角色的存取控制（RBAC）中可以被濫用以達到管理員許可權的三個Kubernetes動詞。這些動詞是：escalate、bind和impersonate。我們看到，透過使用escalate動詞，使用者可以編輯現有的角色，從而提升SA許可權。我們還看到，bind動詞允許使用者編輯RoleBinding或ClusterRoleBinding物件以進行許可權提升。

最後，我們看到在K8s中，impersonate動詞類別似於Linux中的sudo。如果使用者擁有模擬存取許可權，他們可以其他使用者的身份進行身份驗證並代表他們執行命令。我們還討論了三種做法，可以幫助您減輕這些動詞被誤用或惡意使用的潛在危險。這些做法是：

定期檢查RBAC清單。
在角色和叢集角色清單中使用resourceNames欄位。
使用外部工具來監控角色。

在 Kubernetes（K8s）環境中，bind、impersonate 和 escalate 這三個動詞賦予管理者彈性地管理使用者對 K8s 基礎設施的存取許可權，同時也允許使用者提升自身的許可權。然而，這些強大的工具若遭到濫用，可能會對 K8s 叢集造成嚴重的損害。因此，必須仔細審查這些動詞的使用，並確保遵循最小許可權原則。

許可權繫結（Binding）

在繫結的情境下，管理者會為角色設定許可權，而使用者只有在資源名稱中被允許的情況下，才能將該角色繫結到自身。這意味著管理者可以精確地控制使用者可以執行的操作，從而降低潛在的安全風險。

許可權提升（Escalation）

相較於繫結，提升則賦予使用者更大的許可權。使用者可以在角色內寫入任何引數，並成為名稱空間或叢集的管理者。這種方式雖然方便，但也可能導致許可權過度擴張，增加安全風險。

使用外部工具監控角色

建議匯入自動化系統來監控具有可疑內容之角色的建立或編輯，例如 Falco 或 Tetragon。此外，將 Kubernetes 稽核日誌重定向到日誌管理系統，例如 Gcore Managed Logging，對於分析和解析 K8s 日誌也相當有幫助。

為了防止意外刪除資源，可以建立一個具有刪除動詞的獨立服務帳戶（Service Account），並允許使用者僅模擬該服務帳戶。這體現了最小許可權原則的精神，並可透過 kubectl 外掛 kubectl-sudo 來簡化此流程。

upgrade、bind 和 impersonate 這些動詞讓管理者可以靈活地管理對 K8s 基礎設施的存取，並讓使用者提升其許可權。請務必謹慎使用這些工具，並確保遵循最小許可權原則，使用者僅需擁有執行所需操作的最低許可權即可。

玄貓（BlackCat）認為，在 Kubernetes 環境中，許可權管理至關重要。透過仔細審查和遵循最小許可權原則，我們可以確保 K8s 叢集的安全性，並避免因許可權濫用而造成的潛在風險。

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

揭秘 Kubernetes RBAC：提升、繫結與模仿許可權的風險與防禦