Kubernetes RBAC 最佳安全實(shí)踐

作者：韋偉、李昌昊 2024-09-03 16:28:20

本文將簡(jiǎn)要介紹 Kubernetes的認(rèn)證與授權(quán)體系以及RBAC授權(quán)原理。通過(guò)實(shí)際案例展示RBAC管理不當(dāng)可能導(dǎo)致的安全風(fēng)險(xiǎn)，然后向大家分享RBAC安全研發(fā)與運(yùn)維的最佳實(shí)踐，以及我們?cè)谧止?jié)跳動(dòng)內(nèi)部的安全防護(hù)和治理經(jīng)驗(yàn)。

「引言」

Kubernetes 是一個(gè)開(kāi)源的容器編排平臺(tái)，用于自動(dòng)化部署、擴(kuò)展和管理容器化應(yīng)用程序。它提供了豐富的功能，如服務(wù)發(fā)現(xiàn)、負(fù)載均衡、自動(dòng)縮放等。隨著 Kubernetes 在云原生領(lǐng)域的廣泛應(yīng)用，「有效管理誰(shuí)可以對(duì) Kubernetes 集群執(zhí)行何種操作變得至關(guān)重要」。本文將簡(jiǎn)要介紹 Kubernetes的認(rèn)證與授權(quán)體系以及RBAC授權(quán)原理。通過(guò)實(shí)際案例展示RBAC管理不當(dāng)可能導(dǎo)致的安全風(fēng)險(xiǎn)，然后向大家分享RBAC安全研發(fā)與運(yùn)維的最佳實(shí)踐，以及我們?cè)谧止?jié)跳動(dòng)內(nèi)部的安全防護(hù)和治理經(jīng)驗(yàn)。

背景知識(shí)

?
如果您對(duì)相關(guān)背景知識(shí)比較了解，可直接跳轉(zhuǎn)到“RBAC 安全風(fēng)險(xiǎn)剖析”、“RBAC 安全研發(fā)與運(yùn)維最佳實(shí)踐” 章節(jié)閱讀。
?

本章節(jié)將對(duì) Kubernetes 的認(rèn)證和授權(quán)體系進(jìn)行概述，了解這些機(jī)制的原理有助于理解不同場(chǎng)景下集群權(quán)限的安全風(fēng)險(xiǎn)。特別是那些能夠被輕易利用的未授權(quán)訪問(wèn)漏洞，以及那些容易被忽視的權(quán)限提升與橫向移動(dòng)攻擊風(fēng)險(xiǎn)。

Kubernetes 認(rèn)證與授權(quán)體系

Kubernetes 的認(rèn)證與授權(quán)體系主要用于滿足對(duì)關(guān)鍵服務(wù) API（API Server、Kubelet Server）的訪問(wèn)控制。在經(jīng)過(guò)多年的發(fā)展后，Kubernetes 已經(jīng)實(shí)現(xiàn)了一套比較完善的認(rèn)證與授權(quán)機(jī)制，可以滿足用戶大多數(shù)場(chǎng)景的使用需求。

「API Server」

Kubernetes 是一個(gè)以容器技術(shù)為基礎(chǔ)，以聲明式 API Server 為核心的分布式容器編排系統(tǒng)。Kubernetes 幾乎所有的功能都通過(guò) API Server 對(duì)外暴露。而 API Server 支持了多種認(rèn)證機(jī)制，內(nèi)置了多種授權(quán)模式和準(zhǔn)入控制器，允許用戶根據(jù)需要靈活配置和使用。

簡(jiǎn)單來(lái)說(shuō)，當(dāng)一個(gè)用戶訪問(wèn) Kubernetes 的 API Server 時(shí)，API Server 會(huì)使用啟用的認(rèn)證器依次對(duì)請(qǐng)求進(jìn)行身份認(rèn)證，API Server 使用第一個(gè)成功認(rèn)證的身份來(lái)標(biāo)識(shí)請(qǐng)求者；然后再使用啟用的授權(quán)器依次對(duì)請(qǐng)求進(jìn)行授權(quán)策略的檢查，當(dāng)有任意一個(gè)授權(quán)器顯式地允許、拒絕一個(gè)請(qǐng)求時(shí)，則立刻返回當(dāng)前授權(quán)結(jié)果（如果沒(méi)有授權(quán)器顯式地授權(quán)，那么請(qǐng)求也將被拒絕）。除此之外，在 API Server 真正處理請(qǐng)求前，它還會(huì)使用啟用的準(zhǔn)入控制器對(duì)請(qǐng)求進(jìn)一步變異和驗(yàn)證。只有所有的準(zhǔn)入控制器都驗(yàn)證通過(guò)后，請(qǐng)求才會(huì)被真正處理。

?
注意：API Server 不保證認(rèn)證器和準(zhǔn)入控制器的執(zhí)行順序，但會(huì)按照授權(quán)模式的配置順序進(jìn)行鑒權(quán)。
?

「Kubelet Server」

Kubernetes 中還有一個(gè)非常重要的組件，那就是 Kubelet。它充當(dāng)了分布式系統(tǒng)中的 Agent 角色，并使用節(jié)點(diǎn)專(zhuān)屬的用戶證書(shū)訪問(wèn) API Server，管理節(jié)點(diǎn)上的資源。但 Kubelet 自身也會(huì)作為服務(wù)端，對(duì)外提供服務(wù)。從而實(shí)現(xiàn)在容器內(nèi)執(zhí)行命令、獲取指標(biāo)信息、容器日志、宿主機(jī)日志等功能。

Kubernetes 也為 Kubelet Server 提供了多種認(rèn)證和授權(quán)模式。值得一提的是其中的 webhook 認(rèn)證和 webhook 授權(quán)，它們本質(zhì)上是向 API Server 發(fā)送 TokenReview 和 SubjectAccessReview 請(qǐng)求，對(duì)客戶端的身份進(jìn)行認(rèn)證與授權(quán)。

「小結(jié)」

Kubernetes 為 API Server 和 Kubelet Server 支持了多種認(rèn)證機(jī)制、授權(quán)機(jī)制、準(zhǔn)入控制器，以及靈活的自定義接口。這些機(jī)制雖然能夠滿足各種用戶需求，但也給用戶帶來(lái)了困擾。因?yàn)槿绻涣私膺@些機(jī)制的原理和負(fù)面影響，就很容易為集群引入安全風(fēng)險(xiǎn)和入侵檢測(cè)盲點(diǎn)。特別是那些能夠被輕易利用的未授權(quán)訪問(wèn)漏洞，以及那些容易被忽視的提權(quán)與橫向移動(dòng)攻擊風(fēng)險(xiǎn)。

請(qǐng)參見(jiàn)附錄和參考文獻(xiàn)，了解更多 API Server 和 Kubelet Server 的認(rèn)證、授權(quán)、準(zhǔn)入控制的技術(shù)細(xì)節(jié)。

Kubernetes RBAC 授權(quán)原理

RBAC 是 Kubernetes 默認(rèn)啟用的授權(quán)機(jī)制，也是 Kubernetes 核心組件所使用的授權(quán)機(jī)制。用戶在使用集群時(shí)，往往需要使用 RBAC 授權(quán)機(jī)制來(lái)為其用戶賬號(hào)授權(quán)，以便部署、運(yùn)維工作負(fù)載及所需的各種資源。各類(lèi)云原生應(yīng)用的 Operator、Controller 往往也需要利用 RBAC 授權(quán)機(jī)制來(lái)為其服務(wù)賬戶授權(quán)，以確保它們能夠訪問(wèn)必要的資源，從而實(shí)現(xiàn)其功能。

下面的示意圖展示了用戶賬號(hào)和服務(wù)賬號(hào)訪問(wèn) API Server 時(shí)的認(rèn)證、授權(quán)、準(zhǔn)入控制過(guò)程。

在 Kubernetes 的 RBAC 授權(quán)體系中，引入了以下幾種概念：

「Subject」

在 Kubernetes 環(huán)境中有三類(lèi) Subject 可以被授予 RBAC 角色權(quán)限。

「Rule」

用于在 Role, ClusterRole 內(nèi)部定義具體權(quán)限，每一個(gè) rule 都可以通過(guò) apiGroups, resources, resourcesName, verbs, nonResourceURLs 來(lái)定義允許對(duì)什么資源（API 組，資源類(lèi)型，資源名稱(chēng) ）執(zhí)行什么操作（動(dòng)詞）。
注意：rule中的apiGroups, resources, resourcesNames, verbs, nonResourceURLs 支持使用通配符

「Role & ClusterRole」

Role 用來(lái)定義當(dāng)前命名空間范圍內(nèi)資源的角色，它通過(guò) Rules 顯式地定義權(quán)限。
ClusterRole 用來(lái)定義集群范圍內(nèi)資源的角色，它通過(guò) Rules 顯式地定義權(quán)限。

「Role & ClusterRoleBinding」

RoleBinding 將某個(gè) ClusterRole 或當(dāng)前命名空間中的某個(gè) Role 綁定到 subjects，使 subjects 獲得當(dāng)前命名空間中的 ClusterRole、Role所定義的角色權(quán)限，例如可以在命名空間 A 中創(chuàng)建 RoleBinding，將命名空間 A 中的 Role 與命名空間 B 中的 ServiceAccount 綁定。那么命名空間 B 中的 ServiceAccount 將獲得命名空間 A 中的 Role 定義的權(quán)限。
ClusterRoleBinding 將某個(gè) ClusterRole 綁定到 subjects，使 subjects 獲得 ClusterRole 所定義的角色權(quán)限。

由以上可知，Role 和 ClusterRole 內(nèi)的 rules 代表一系列顯式授予的權(quán)限，遵從 Deny-by-Default 安全模型。由于不支持 "deny" 規(guī)則，因而不支持顯式的排除某些權(quán)限。

這一特點(diǎn)使得某些應(yīng)用場(chǎng)景無(wú)法利用 RBAC 授權(quán)機(jī)制實(shí)現(xiàn)：在授予所有已知、未知 CRD 資源操作權(quán)限的同時(shí)，顯式地排除某些敏感權(quán)限。但我們可以借助 ABAC、Webhook 授權(quán)模式，結(jié)合準(zhǔn)入控制器來(lái)為此類(lèi)場(chǎng)景的服務(wù)賬號(hào)進(jìn)行權(quán)限管理，從而緩解這類(lèi)問(wèn)題。

下面是一個(gè)通過(guò) RBAC 授權(quán)機(jī)制為 ServiceAccount 綁定權(quán)限的示例：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: example-clusterrole
  namespace: example-ns
rules:
- apiGroups:
  - apps
  resources:
  - daemonsets
  - deployments
  - replicasets
  - statefulsets
  resourcesNames:
  - test
  verbs:
  - '*'
- nonResourceURLs:
  - /healthz
  - /healthz/*
  verbs:
  - get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: example-rolebinding
  namespace: example-ns
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: example-clusterrole
subjects:
- kind: ServiceAccount
  name: example-sa
  namespace: example-ns

RBAC 安全風(fēng)險(xiǎn)剖析

Kubernetes 是一個(gè)分布式的容器編排系統(tǒng)。除了要確保 Kubernetes 基礎(chǔ)組件的配置安全（例如 API Server、Kubelet Server 基本的認(rèn)證授權(quán)配置等，對(duì)應(yīng) CIS Kubernetes Benchmark 中的第一至第四章中的要求）外，我們還需要對(duì)其 RBAC 授權(quán)配置進(jìn)行精細(xì)化管理。

正確的授予主體 RBAC 權(quán)限能夠避免為集群引入不必要的穩(wěn)定性 & 安全性風(fēng)險(xiǎn)，而不恰當(dāng)?shù)臋?quán)限設(shè)置可能導(dǎo)致敏感數(shù)據(jù)泄露、資源濫用、權(quán)限提升，甚至威脅整個(gè)集群的安全。接下來(lái)我們將借助文獻(xiàn)和案例來(lái)進(jìn)一步說(shuō)明其安全風(fēng)險(xiǎn)。

概述

在 Kubernetes 中，可以通過(guò)對(duì)資源的操作來(lái)實(shí)現(xiàn)信息竊取、權(quán)限提升、橫向移動(dòng)等攻擊。例如可以利用 pods/exec 資源的 create 權(quán)限通過(guò) API Server 在指定容器內(nèi)執(zhí)行任意命令，也可以利用 nodes/proxy 資源的 create 權(quán)限直接訪問(wèn) Kubelet Server 在指定容器內(nèi)執(zhí)行任意命令，還可以利用 pods 的 create 權(quán)限創(chuàng)建具有安全風(fēng)險(xiǎn)的容器、利用 pods 的 patch 權(quán)限在指定 Pod 的容器內(nèi)執(zhí)行代碼......「隨著 Kubernetes 的廣泛使用，此類(lèi)風(fēng)險(xiǎn)在云廠商、PaaS平臺(tái)、云原生應(yīng)用、SaaS產(chǎn)品中愈演愈烈，輕則被用于后滲透入侵，重則會(huì)給產(chǎn)品引入安全漏洞。」

Palo Alto Networks 的安全研究員深入分析了 Kubernetes 中的所有敏感權(quán)限，并根據(jù)其危害類(lèi)型將其分類(lèi)和分級(jí)[2]（嚴(yán)重等級(jí)請(qǐng)參考開(kāi)源項(xiàng)目 rbac-police 的風(fēng)險(xiǎn)權(quán)限掃描策略集[3]）。如下圖所示，在這些敏感權(quán)限中，有許多都可以被攻擊者用于信息泄漏、權(quán)限提升、橫向移動(dòng)等攻擊，最終實(shí)現(xiàn)整個(gè)集群的接管。

Palo Alto Networks 的研究結(jié)果表明，在針對(duì)主流公有云、CNI 廠商的分析中，有將近 50% 的廠商存在容器逃逸后輕易導(dǎo)致集群淪陷的安全問(wèn)題。另外有 25% 的廠商存在容器逃逸后在一定條件下導(dǎo)致集群淪陷的安全風(fēng)險(xiǎn)[2]。

公開(kāi)案例

RBAC Buster：來(lái)自 Aqua Sec 的研究者通過(guò)蜜罐首次捕獲到利用 Kubernetes 的 RBAC 配置漏洞進(jìn)行攻擊的行為，黑客通過(guò)創(chuàng)建后門(mén)訪問(wèn)集群，導(dǎo)致未授權(quán)訪問(wèn)和數(shù)據(jù)泄露的風(fēng)險(xiǎn)。詳見(jiàn) First-Ever Attack Leveraging Kubernetes RBAC to Backdoor Clusters[5]
Sys:All：研究團(tuán)隊(duì) The Orca Research Pod 掃描了 250,000 個(gè) GKE 集群（約總數(shù)的 2%），發(fā)現(xiàn)其中 1300 個(gè)集群存在錯(cuò)誤配置的角色綁定，其中有 108 個(gè)集群允許攻擊者使用任何有效的谷歌帳號(hào)接管集群。詳見(jiàn)：How A Simple Loophole in Google Kubernetes Engine Puts Clusters at Risk of Compromise[6] & GCP-2024-003 security-bulletins[7]
在 OWASP Kubernetes Top 10 安全風(fēng)險(xiǎn)中，RBAC 配置錯(cuò)誤導(dǎo)致的“權(quán)限過(guò)多”問(wèn)題排名第三，可能引發(fā)未授權(quán)操作和權(quán)限提升。詳見(jiàn) OWASP Kubernetes Top 10[8]

風(fēng)險(xiǎn)示例

下面的示例演示了攻擊者可以利用任意 secrets 的 create 權(quán)限，來(lái)獲取了包含敏感權(quán)限的 ServiceAccount（這里以竊取 prometheus-agent SA 的 token 為例）的 token。對(duì)此，我們建議使用專(zhuān)用命名空間中的 Role 來(lái)定義所需權(quán)限，從而與 kube-system 等敏感命名空間隔離。

下面的示例演示了攻擊者可以利用任意 secrets 的 get 權(quán)限，來(lái)爆破獲取保存 SA token 的 secrets。雖然爆破 SA token 需要較長(zhǎng)時(shí)間（爆破一個(gè)擁有 5 個(gè)隨機(jī)字符串的 SA token 最多需要 27^5 次），但此權(quán)限也可能被用于竊取其他已知名稱(chēng)的 secrets 資源。對(duì)此，我們建議使用 Role 定義角色，或者通過(guò) resourceNames 對(duì) secrets 的權(quán)限范圍進(jìn)行約束，而非授予全部命名空間中任意 secrets 的 get 權(quán)限。

以上數(shù)據(jù)和案例表明，Kubernetes RBAC 權(quán)限管理已成為一個(gè)必須認(rèn)真對(duì)待并及時(shí)采取有效防御措施的安全問(wèn)題。

RBAC 安全研發(fā)與運(yùn)維最佳實(shí)踐

基于我們?cè)谧止?jié)跳動(dòng)內(nèi)部的安全實(shí)踐，我們?yōu)?RBAC 授權(quán)配置總結(jié)了如下原則，以指引大家進(jìn)行 Kubernetes RBAC 權(quán)限管理，從而降低由此為集群引入的安全風(fēng)險(xiǎn)。

遵循最小權(quán)限原則

在 RBAC 角色中分配權(quán)限時(shí)，請(qǐng)遵循最小權(quán)限原則授予執(zhí)行任務(wù)所需的最低權(quán)限。例如：

優(yōu)先使用 Role, RoleBinding 授予一個(gè)、多個(gè)特定命名空間中的權(quán)限。
定義 rule 時(shí)，使用明確的 apiGroups, resources, verbs 以及 resourceNames 來(lái)限定權(quán)限范圍。

?
注意：
如果設(shè)置了 resourceNames 字段，那么請(qǐng)求權(quán)限不能是 list、watch、create、deletecollection，否則請(qǐng)求將不會(huì)被允許（「當(dāng)使用 resourceNames 限制 list、watch 權(quán)限范圍時(shí)，客戶端必須在請(qǐng)求參數(shù)中指定 fieldSelector=metadata.name%3D{RESOURCENAME} 用于通過(guò)授權(quán)」）。但當(dāng) resourceNames 字段中包含 "" 時(shí)，將允許 list 請(qǐng)求。
雖然 RBAC 授權(quán)模式不支持通過(guò) resourceNames 來(lái)約束 create、deletecollection 權(quán)限，但仍然建議通過(guò) resourceNames 來(lái)約束 update、patch、get 等權(quán)限。
?

RBAC 權(quán)限最小化不應(yīng)被視作“非黑即白”，哪怕組件的某些敏感權(quán)限無(wú)法收斂，最小化權(quán)限仍然對(duì)降低風(fēng)險(xiǎn)、增加入侵檢測(cè)的機(jī)率有重要作用。

避免使用默認(rèn)角色/用戶/用戶組

一般情況下，Kubernetes 和基于 Kubernetes 的 PaaS 平臺(tái)會(huì)自動(dòng)將一些默認(rèn)角色綁定到默認(rèn)用戶和用戶組，以保證系統(tǒng)的正常運(yùn)行。如需查看 Kubernetes 創(chuàng)建的默認(rèn)角色和綁定的完整列表，請(qǐng)參閱 Default roles and role bindings。

常見(jiàn)的默認(rèn)角色有：cluster-admin, system:node, system:controller:daemon-set-controller ...
常見(jiàn)的系統(tǒng)用戶有：system:anonymous, system:kube-controller-manager, system:kube-scheduler, system:kube-proxy, system:serviceaccounts:NAMESPACE:default ...
常見(jiàn)的系統(tǒng)用戶組：system:unauthenticated, system:authenticated, system:serviceaccounts, system:nodes, system:monitoring, system:masters ...

大部分默認(rèn)角色（例如 cluster-admin, edit, system:node 等）都會(huì)被授予較廣泛的權(quán)限。因此，我們「不建議」將默認(rèn)角色綁定到服務(wù)賬號(hào)，除非您知道并接受由此帶來(lái)的安全風(fēng)險(xiǎn)。用戶可以根據(jù)實(shí)際需要將其綁定到用戶賬號(hào)上。

除此之外，我們「應(yīng)當(dāng)避免」為系統(tǒng)用戶（例如 system:anonymous, system:serviceaccounts:NAMESPACE:default 等）、系統(tǒng)用戶組（例如 system:authenticated, system:serviceaccounts 等）綁定額外的角色，這會(huì)導(dǎo)致權(quán)限的非預(yù)期擴(kuò)散，引入嚴(yán)重的安全風(fēng)險(xiǎn)。

避免為 default 服務(wù)賬號(hào)授予權(quán)限

在附錄 1 的“準(zhǔn)入控制機(jī)制”一節(jié)中，我們提到了默認(rèn)啟用的 ServiceAccount 準(zhǔn)入控制器。創(chuàng)建 Pod 時(shí)如果未指定 ServiceAccount，那么 ServiceAccount 準(zhǔn)入控制器會(huì)將命名空間內(nèi)名為 default 的 ServiceAccount 分配給 Pod。

因此，我們「應(yīng)當(dāng)避免」為 default 服務(wù)賬號(hào)授予權(quán)限，這會(huì)導(dǎo)致非預(yù)期的權(quán)限泄露。

盡量避免使用通配符

* 字符是一個(gè)適用于所有內(nèi)容的通配符，「應(yīng)盡量避免」在規(guī)則中使用通配符。這容易造成授權(quán)范圍過(guò)大，除非您明確知曉并接受此行為可能引入的安全風(fēng)險(xiǎn)。建議您在 RBAC 規(guī)則中明確指定 API 組（apiGroups）、資源（resources）、動(dòng)詞（verbs），甚至是資源名稱(chēng)（resourceNames）。

例如，在 verbs 字段中指定 * 將授予 get、list、watch、patch、update、deletecollection 和 delete 等權(quán)限。下表舉例說(shuō)明了如何避免在規(guī)則中使用通配符。

盡量避免使用敏感權(quán)限

設(shè)計(jì)角色前，請(qǐng)先仔細(xì)評(píng)估存在權(quán)限提升、命令執(zhí)行、信息泄漏等安全風(fēng)險(xiǎn)的權(quán)限。例如 secrets 的操作權(quán)限、證書(shū)簽發(fā)權(quán)限、pods/exec 訪問(wèn)權(quán)限等，更多請(qǐng)參考 Kubernetes RBAC - privilege escalation risks[9] 和風(fēng)險(xiǎn)權(quán)限掃描策略集[3]。

為應(yīng)用服務(wù)、控制組件授予敏感權(quán)限會(huì)給整個(gè)集群引入安全風(fēng)險(xiǎn)。在系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)時(shí)，「應(yīng)盡量避免」使用它們，并配合其他手段進(jìn)行安全編排、安全加固和入侵檢測(cè)。

盡量使用單獨(dú)規(guī)則對(duì)特定資源授予權(quán)限

規(guī)劃規(guī)則時(shí)，建議您嘗試以下簡(jiǎn)要步驟，在每個(gè)角色中采用更高效、可讀、易于維護(hù)的規(guī)則設(shè)計(jì)[4]：

為主體需要訪問(wèn)的每項(xiàng)資源上的動(dòng)詞草擬單獨(dú)的 RBAC 規(guī)則。
草擬規(guī)則后，分析規(guī)則，以檢查多條規(guī)則是否具有相同的 verbs 列表。將這些規(guī)則合并為一條規(guī)則。
請(qǐng)將其余的所有規(guī)則彼此分散。

這種方法可實(shí)現(xiàn)更有條理的規(guī)則設(shè)計(jì)，將對(duì)多個(gè)資源授予相同動(dòng)詞的規(guī)則組合起來(lái)，將為資源授予不同動(dòng)詞的規(guī)則彼此分散[4]。

例如，如果您的工作負(fù)載需要獲取 deployments 資源的權(quán)限，但需要 daemonsets 資源的 list 和 watch 權(quán)限，則您應(yīng)該在創(chuàng)建角色是使用單獨(dú)規(guī)則。當(dāng)您將 RBAC 角色綁定到工作負(fù)載時(shí)，該角色將無(wú)法對(duì) deployments 資源進(jìn)行 watch 操作[4]。

再舉一例，如果您的工作負(fù)載需要 pods 資源和 daemonsets 資源的 get 和 watch 權(quán)限，您可以將它們組合成一條規(guī)則，因?yàn)楣ぷ髫?fù)載需要在這兩個(gè)資源上使用相同的動(dòng)詞[4]。

在下表中，這兩種規(guī)則設(shè)計(jì)均有效，但拆分規(guī)則會(huì)根據(jù)需要更精細(xì)地限制資源訪問(wèn)權(quán)限[4]。

安全編排與其它

有些場(chǎng)景下，業(yè)務(wù)需求可能與安全要求產(chǎn)生沖突。例如一些應(yīng)用必需某些敏感權(quán)限才可以正常運(yùn)行或提供必要功能。對(duì)此，我們建議您考慮采取以下安全編排、縱深防御策略來(lái)盡量降低風(fēng)險(xiǎn)。

?
注意：如果您的組件是 DaemonSet 類(lèi)型且必需某些敏感權(quán)限，我們強(qiáng)烈建議您對(duì)其進(jìn)行重構(gòu)或緩解（例如通過(guò)webhook準(zhǔn)入控制器進(jìn)行校驗(yàn)等）。否則當(dāng)出現(xiàn)節(jié)點(diǎn)淪陷的事件時(shí)，整個(gè)集群都將遭受威脅。
?

「使用專(zhuān)用命名空間」

如果應(yīng)用僅需命名空間范圍內(nèi)的權(quán)限，那么我們「強(qiáng)烈建議」將其部署在專(zhuān)用命名空間中，而非 kube-system 命名空間、default 命名空間、業(yè)務(wù)負(fù)載所在的命名空間，從而避免不必要的權(quán)限擴(kuò)散。
例如某控制組件的 SA 會(huì)被授予所在命名空間 secrets 的 list & watch 權(quán)限用于維護(hù) ssl 密鑰對(duì)。我們可以將其部署在專(zhuān)用命名空間（而非 kube-system 命名空間、業(yè)務(wù)負(fù)載所在的命名空間）來(lái)降低 SA token 泄漏后的能夠帶來(lái)的安全風(fēng)險(xiǎn)。
如果應(yīng)用需要所有全局范圍內(nèi)的敏感權(quán)限，那么「不建議」將其部署在 default 命名空間、業(yè)務(wù)負(fù)載所在的命名空間，從而避免潛在的權(quán)限擴(kuò)散。

「制定特殊調(diào)度策略」

如果某些組件需要全局范圍內(nèi)的敏感權(quán)限，那么「建議」制定合適的調(diào)度策略（通過(guò)節(jié)點(diǎn)污點(diǎn)、準(zhǔn)入控制策略等確保調(diào)度策略不會(huì)被繞過(guò)），將此類(lèi)組件強(qiáng)制調(diào)度到專(zhuān)用節(jié)點(diǎn)池或使用彈性容器部署組件，從而實(shí)現(xiàn)將包含敏感權(quán)限的控制組件與業(yè)務(wù)負(fù)載分離。避免業(yè)務(wù)負(fù)載所在節(jié)點(diǎn)淪陷后，敏感權(quán)限 SA token 泄漏帶來(lái)的安全風(fēng)險(xiǎn)。

「單獨(dú)部署敏感組件」

您也可以將需要敏感權(quán)限的組件部署到獨(dú)立的控制面，從而解決此類(lèi)安全風(fēng)險(xiǎn)。

「建設(shè)縱深防御」

在實(shí)際業(yè)務(wù)場(chǎng)景中，不是所有的敏感權(quán)限都能夠被消除。尤其是那些風(fēng)險(xiǎn)等級(jí)較高，但業(yè)務(wù)又強(qiáng)依賴(lài)的權(quán)限。因此，除權(quán)限最小化、安全編排外，我們強(qiáng)烈建議您引入主機(jī)、Kubernetes 層面的威脅管理與入侵檢測(cè)能力。從而及時(shí)發(fā)現(xiàn)并管理風(fēng)險(xiǎn)，告警并響應(yīng)潛在的入侵行為。

RBAC 安全防護(hù)與治理實(shí)踐

在許多企業(yè)中，往往會(huì)因?yàn)榘踩庾R(shí)不足、云原生安全建設(shè)開(kāi)展較晚、使用開(kāi)源云原生應(yīng)用等原因，已經(jīng)為系統(tǒng)引入了大量 RBAC 權(quán)限風(fēng)險(xiǎn)。但由于涉及基礎(chǔ)設(shè)施，并且缺乏相應(yīng)的知識(shí)和手段，針對(duì)這類(lèi)風(fēng)險(xiǎn)的防護(hù)和治理往往充滿挑戰(zhàn)。接下來(lái)筆者將向大家介紹我們?cè)谧止?jié)跳動(dòng)內(nèi)部的一些經(jīng)驗(yàn)和實(shí)踐，拋磚引玉供大家參考。

整體思路

通過(guò)公開(kāi)案例和紅藍(lán)演練等方式，向研發(fā)團(tuán)隊(duì)展示 K8s RBAC 錯(cuò)誤配置對(duì)生產(chǎn)環(huán)境安全性和穩(wěn)定性造成的危害。與 DevOps 團(tuán)隊(duì)在風(fēng)險(xiǎn)認(rèn)知上達(dá)成一致，從而自上而下對(duì)齊治理目標(biāo)。在開(kāi)展治理工作前，應(yīng)根據(jù)企業(yè)的實(shí)際情況制定合理的計(jì)劃。同時(shí)，安全團(tuán)隊(duì)?wèi)?yīng)提供治理所需的知識(shí)庫(kù)、工具和系統(tǒng)，與 Ops 團(tuán)隊(duì)構(gòu)建合適的治理流程，以確保治理工作順利推進(jìn)。此外，安全團(tuán)隊(duì)還應(yīng)持續(xù)加強(qiáng)反入侵能力建設(shè)，為 K8s RBAC 等安全風(fēng)險(xiǎn)提供兜底保障。

制定計(jì)劃

制定切實(shí)可行的計(jì)劃，以及提供必要的工具與系統(tǒng)，是收斂 K8s RBAC 安全風(fēng)險(xiǎn)的重要前提和保障。

「數(shù)據(jù)驅(qū)動(dòng)」

我們建議以數(shù)據(jù)驅(qū)動(dòng)的方式開(kāi)展防護(hù)和治理工作。通過(guò)持續(xù)的安全掃描來(lái)識(shí)別風(fēng)險(xiǎn)、評(píng)估風(fēng)險(xiǎn)嚴(yán)重性、明確優(yōu)先級(jí)。通過(guò)定位風(fēng)險(xiǎn)引入的原因，來(lái)定位責(zé)任人和卡點(diǎn)，從而對(duì)癥下藥。

?
需要指出的是，雖然“RBAC 安全風(fēng)險(xiǎn)剖析”一章已經(jīng)指出 Kubernetes 中有大量權(quán)限存在安全風(fēng)險(xiǎn)，但面對(duì)各種場(chǎng)景和現(xiàn)實(shí)因素，我們很可能無(wú)法要求業(yè)務(wù)避免使用所有的敏感權(quán)限。這需要我們?cè)诎踩雷o(hù)與業(yè)務(wù)需求之間取得平衡。
?

「明確優(yōu)先級(jí)」

我們結(jié)合 RBAC 風(fēng)險(xiǎn)權(quán)限的可利用性、嚴(yán)重等級(jí)，以及影響范圍等，將其劃分成五個(gè)優(yōu)先級(jí)（風(fēng)險(xiǎn)權(quán)限及其安全掃描策略請(qǐng)參考風(fēng)險(xiǎn)權(quán)限掃描策略集[3]），以此來(lái)推進(jìn) K8s RBAC 的權(quán)限評(píng)估和治理。在完成風(fēng)險(xiǎn)評(píng)估和治理前后，我們還需借助入侵檢測(cè)等機(jī)制來(lái)進(jìn)行持續(xù)監(jiān)控與兜底。

「增量管控 & 存量整改」

通過(guò)在企業(yè)的 PaaS 平臺(tái)、K8s 集群內(nèi)集成準(zhǔn)入控制機(jī)制，以此來(lái)實(shí)現(xiàn)增量管控。建議提供必要的白名單機(jī)制，為無(wú)法立刻整改的應(yīng)用進(jìn)行臨時(shí)豁免。然后根據(jù)定期掃描結(jié)果來(lái)推動(dòng)責(zé)任人進(jìn)行存量組件的整改、灰度測(cè)試、全量更新。

防護(hù)與治理框架

在字節(jié)內(nèi)部，我們構(gòu)建了如下圖所示的安全防護(hù)和治理框架，并推進(jìn)了權(quán)限治理工作。

在開(kāi)發(fā)與集成階段，我們借助最佳安全實(shí)踐來(lái)指導(dǎo)研發(fā)部門(mén)進(jìn)行安全的 RBAC 權(quán)限設(shè)計(jì)和開(kāi)發(fā)。并在部分 CI/CD 流水線中集成了安全掃描，對(duì)存在危險(xiǎn) RBAC 配置的 chart 產(chǎn)物進(jìn)行攔截、告警和記錄。

在部署階段，我們通過(guò)與 PaaS 平臺(tái)集成的準(zhǔn)入控制機(jī)制、K8s 準(zhǔn)入控制器來(lái)對(duì)非法的應(yīng)用和資源進(jìn)行增量管控。并指導(dǎo)關(guān)鍵業(yè)務(wù)通過(guò)安全編排等手段來(lái)降低具有敏感權(quán)限的控制組件的安全風(fēng)險(xiǎn)。這里我們基于開(kāi)源項(xiàng)目 Kyverno 的策略引擎，實(shí)現(xiàn)了 Policy as Code。從而在流水線安全掃描、準(zhǔn)入控制中實(shí)現(xiàn)策略兼容，降低了安全策略的維護(hù)成本。

在運(yùn)行階段，我們通過(guò)定期掃描（基于開(kāi)源項(xiàng)目 rbac-police）來(lái)持續(xù)識(shí)別風(fēng)險(xiǎn)。此外，我們還設(shè)計(jì)實(shí)現(xiàn)了針對(duì)服務(wù)賬號(hào)和用戶賬號(hào)的行為建模能力。此能力基于賬戶行為來(lái)生成最小權(quán)限的角色定義，為組件的權(quán)限收斂提供參考。由于不是所有的敏感權(quán)限都能得到整改，因此，在實(shí)踐中我們會(huì)基于 K8s 的審計(jì)日志進(jìn)行入侵檢測(cè)，從而發(fā)現(xiàn)潛在的攻擊行為。

通過(guò)以上機(jī)制，我們構(gòu)建了針對(duì) K8s RBAC 安全風(fēng)險(xiǎn)的防護(hù)和治理框架，為字節(jié)內(nèi)部大規(guī)模生產(chǎn)集群的 RBAC 安全治理和防護(hù)提供了必要能力。

總結(jié)

RBAC 是 Kubernetes 中的一項(xiàng)重要的授權(quán)機(jī)制，正確地配置 RBAC 對(duì)于保障基于 Kubernetes 的系統(tǒng)安全至關(guān)重要。在設(shè)計(jì)中，我們應(yīng)遵循最小權(quán)限原則進(jìn)行權(quán)限設(shè)計(jì)，并理解敏感權(quán)限的安全風(fēng)險(xiǎn)，為其引入必要的防護(hù)能力。在開(kāi)發(fā)中，我們要注意避免過(guò)度授權(quán)、權(quán)限混亂等問(wèn)題。在安全防護(hù)和運(yùn)營(yíng)中，我們還要平衡安全要求和業(yè)務(wù)需求，持續(xù)收斂安全風(fēng)險(xiǎn)，建立縱深防御體系。

希望本文能讓大家更好地理解 Kubernetes 的權(quán)限體系，了解 RBAC 授權(quán)模式的安全風(fēng)險(xiǎn)和最佳安全實(shí)踐，從而指導(dǎo)系統(tǒng)的安全設(shè)計(jì)、開(kāi)發(fā)和防護(hù)，最終構(gòu)建更加安全可靠的系統(tǒng)。