Kubernetes 基于角色的訪問控制良好實(shí)踐

基于角色的訪問控制良好實(shí)踐

Kubernetes RBAC 是一項(xiàng)關(guān)鍵的安全控制，可確保集群用戶和工作負(fù)載只能訪問執(zhí)行其角色所需的資源。 重要的是確保在為集群用戶設(shè)計(jì)權(quán)限時，集群管理員了解可能發(fā)生權(quán)限提升的區(qū)域，以降低過度訪問導(dǎo)致安全事件的風(fēng)險(xiǎn)。

一般良好做法

最低權(quán)限

理想情況下，應(yīng)將最少的 RBAC 權(quán)限分配給用戶和服務(wù)帳戶。 僅應(yīng)使用其操作明確要求的權(quán)限。 雖然每個集群都會有所不同，但可以應(yīng)用的一些一般規(guī)則是：

• 盡可能在命名空間級別分配權(quán)限。使用 RoleBindings 而不是 ClusterRoleBindings 僅在特定命名空間內(nèi)授予用戶權(quán)限。
• 盡可能避免提供通配符權(quán)限，尤其是對所有資源。由于 Kubernetes 是一個可擴(kuò)展的系統(tǒng)，提供通配符訪問不僅可以授予集群中當(dāng)前所有對象類型的權(quán)限，還可以授予將來創(chuàng)建的所有未來對象類型的權(quán)限。
• 除非特別需要，否則管理員不應(yīng)使用?cluster-admin?帳戶。提供具有模擬權(quán)限的低權(quán)限帳戶可以避免意外修改集群資源。

• 避免將用戶添加到 ?system:masters? 組。作為該組成員的任何用戶都會繞過所有 RBAC 權(quán)限檢查，并且將始終擁有不受限制的超級用戶訪問權(quán)限，這不能通過刪除角色綁定或集群角色綁定來撤銷。順便說一句，如果集群正在使用授權(quán) webhook，則該組的成員身份也會繞過該 webhook（來自該組成員的用戶的請求永遠(yuǎn)不會發(fā)送到 webhook）

盡量減少特權(quán)代幣的分配

理想情況下，不應(yīng)為 pod 分配被授予強(qiáng)大權(quán)限的服務(wù)帳戶。 如果工作負(fù)載需要強(qiáng)大的權(quán)限，請考慮以下做法：

• 限制運(yùn)行強(qiáng)大 pod 的節(jié)點(diǎn)數(shù)量。 確保您運(yùn)行的任何 DaemonSet 都是必需的，并且以最小權(quán)限運(yùn)行以限制容器逃逸的爆炸半徑。
• 避免與不受信任或公開的 Pod 一起運(yùn)行強(qiáng)大的 Pod。 考慮使用 Taints and Toleration、NodeAffinity 或 PodAntiAffinity 來確保 Pod 不會與不受信任或不太受信任的 Pod 一起運(yùn)行。 特別注意可信度較低的 Pod 不符合 Restricted Pod 安全標(biāo)準(zhǔn)的情況。

Hardening

Kubernetes 默認(rèn)提供并非每個集群都需要的訪問權(quán)限。 查看默認(rèn)提供的 RBAC 權(quán)限可以為安全加固提供機(jī)會。 通常，不應(yīng)更改提供給系統(tǒng)的權(quán)限：帳戶存在一些強(qiáng)化集群權(quán)限的選項(xiàng)：

• 查看 ?system:unauthenticated? 組的綁定并在可能的情況下刪除，因?yàn)檫@樣可以訪問可以在網(wǎng)絡(luò)級別聯(lián)系 API 服務(wù)器的任何人。
• 通過設(shè)置 ?automountServiceAccountToken: false? 來避免默認(rèn)自動掛載服務(wù)帳戶令牌。為 Pod 設(shè)置此值將覆蓋服務(wù)帳戶設(shè)置，需要服務(wù)帳戶令牌的工作負(fù)載仍然可以掛載它們。

定期審查

定期檢查 Kubernetes RBAC 設(shè)置是否有冗余條目和可能的權(quán)限升級至關(guān)重要。 如果攻擊者能夠創(chuàng)建與已刪除用戶同名的用戶帳戶，他們可以自動繼承已刪除用戶的所有權(quán)限，尤其是分配給該用戶的權(quán)限。

Kubernetes RBAC - 提權(quán)風(fēng)險(xiǎn)

在 Kubernetes RBAC 中有許多權(quán)限，如果授予這些權(quán)限，則可以允許用戶或服務(wù)帳戶提升其在集群中的權(quán)限或影響集群外的系統(tǒng)。

本節(jié)旨在提供集群操作員應(yīng)注意的區(qū)域的可見性，以確保他們不會無意中允許對集群的訪問超出預(yù)期。

Listing secrets

通常很清楚，允許對 Secrets 的訪問將允許用戶閱讀其內(nèi)容。 同樣重要的是要注意，?list?和?watch?訪問也有效地允許用戶透露秘密內(nèi)容。 例如，當(dāng)返回 List 響應(yīng)時（例如，通過 ?kubectl get secrets -A -o yaml?），響應(yīng)包括所有 Secrets 的內(nèi)容。

工作負(fù)載創(chuàng)建

除非有基于 Kubernetes Pod 安全標(biāo)準(zhǔn)的限制，否則能夠創(chuàng)建工作負(fù)載（Pod 或管理 Pod 的工作負(fù)載資源）的用戶將能夠訪問底層節(jié)點(diǎn)。

可以運(yùn)行特權(quán) Pod 的用戶可以使用該訪問權(quán)限來獲得節(jié)點(diǎn)訪問權(quán)限，并可能進(jìn)一步提升他們的權(quán)限。如果您不完全信任具有創(chuàng)建適當(dāng)安全和隔離 Pod 的能力的用戶或??其他主體，則應(yīng)強(qiáng)制執(zhí)行基線或受限 Pod 安全標(biāo)準(zhǔn)。您可以使用 Pod 安全準(zhǔn)入或其他（第三方）機(jī)制來實(shí)施該強(qiáng)制。

您還可以使用已棄用的 PodSecurityPolicy 機(jī)制來限制用戶創(chuàng)建特權(quán) Pod 的能力（注意，PodSecurityPolicy 計(jì)劃在版本 1.25 中刪除）。

在命名空間中創(chuàng)建工作負(fù)載還會授予對該命名空間中 Secret 的間接訪問權(quán)限。在 kube-system 或類似特權(quán)的命名空間中創(chuàng)建一個 pod 可以授予用戶對他們直接通過 RBAC 沒有的 Secret 的訪問權(quán)限

持久卷創(chuàng)建

對創(chuàng)建 PersistentVolume 的訪問可以允許升級對底層主機(jī)的訪問。 在需要訪問持久存儲的地方，受信任的管理員應(yīng)該創(chuàng)建 PersistentVolume，并且受限用戶應(yīng)該使用 PersistentVolumeClaims 來訪問該存儲。

訪問節(jié)點(diǎn)的代理子資源

有權(quán)訪問節(jié)點(diǎn)對象的代理子資源的用戶有權(quán)訪問 Kubelet API，該 API 允許在他們有權(quán)訪問的節(jié)點(diǎn)上的每個 pod 上執(zhí)行命令。 此訪問繞過審核日志記錄和準(zhǔn)入控制，因此在授予此資源權(quán)限之前應(yīng)小心。

Escalate verb

通常，RBAC 系統(tǒng)會阻止用戶創(chuàng)建比他們擁有的權(quán)限更多的集群角色。 一個例外是?escalate ?verb，擁有此權(quán)限的用戶可以有效地提升他們的權(quán)限。

Bind verb

與?escalate ?verb類似，授予用戶此權(quán)限允許繞過 Kubernetes 內(nèi)置的針對權(quán)限升級的保護(hù)，允許用戶創(chuàng)建與具有他們不具有的權(quán)限的角色的綁定。

Impersonate verb

此verb允許用戶模擬并獲得集群中其他用戶的權(quán)限。 授予它時應(yīng)小心，以確保不能通過模擬帳戶之一獲得過多的權(quán)限。

CSRs 和證書頒發(fā)

CSR API 允許具有 CSR 創(chuàng)建權(quán)限和更新?certificatesigningrequests/approval?權(quán)限的用戶，其中簽名者是 ?kubernetes.io/kube-apiserver-client?，以創(chuàng)建新的客戶端證書，允許用戶對集群進(jìn)行身份驗(yàn)證。 這些客戶端證書可以具有任意名稱，包括 Kubernetes 系統(tǒng)組件的副本。 這將有效地允許特權(quán)升級。

Token請求

對 ?serviceaccounts/token? 具有?create?權(quán)限的用戶可以創(chuàng)建 TokenRequests 來為現(xiàn)有的服務(wù)帳戶頒發(fā)令牌。

控制準(zhǔn)入 webhook

控制驗(yàn)證?webhookconfigurations?或?mutatingwebhookconfigurations?的用戶可以控制可以讀取集群允許的任何對象的webhook，并且在改變webhook的情況下，也可以改變允許的對象。

Kubernetes RBAC - 拒絕服務(wù)風(fēng)險(xiǎn)

對象創(chuàng)建拒絕服務(wù)

有權(quán)在集群中創(chuàng)建對象的用戶可能能夠根據(jù)對象的大小或數(shù)量創(chuàng)建足夠大的對象來創(chuàng)建拒絕服務(wù)條件，正如 Kubernetes 使用的 etcd 中所討論的那樣容易受到 OOM 攻擊。 如果允許半受信任或不受信任的用戶對系統(tǒng)進(jìn)行有限訪問，這可能與多租戶集群特別相關(guān)。

緩解此問題的一種選擇是使用資源配額來限制可以創(chuàng)建的對象數(shù)量。