建站
咨詢
售后
建站咨詢
新聞中心
基于角色的訪問控制良好實踐
Kubernetes RBAC 是一項關鍵的安全控制，可確保集群用戶和工作負載只能訪問執(zhí)行其角色所需的資源。 重要的是確保在為集群用戶設計權限時，集群管理員了解可能發(fā)生權限提升的區(qū)域，以降低過度訪問導致安全事件的風險。
創(chuàng)新互聯(lián)公司為您提適合企業(yè)的網(wǎng)站設計?讓您的網(wǎng)站在搜索引擎具有高度排名，讓您的網(wǎng)站具備超強的網(wǎng)絡競爭力！結合企業(yè)自身，進行網(wǎng)站設計及把握，最后結合企業(yè)文化和具體宗旨等，才能創(chuàng)作出一份性化解決方案。從網(wǎng)站策劃到網(wǎng)站設計制作、成都網(wǎng)站制作， 我們的網(wǎng)頁設計師為您提供的解決方案。
一般良好做法
最低權限
理想情況下，應將最少的 RBAC 權限分配給用戶和服務帳戶。 僅應使用其操作明確要求的權限。 雖然每個集群都會有所不同，但可以應用的一些一般規(guī)則是：
- 盡可能在命名空間級別分配權限。使用 RoleBindings 而不是 ClusterRoleBindings 僅在特定命名空間內(nèi)授予用戶權限。
- 盡可能避免提供通配符權限，尤其是對所有資源。由于 Kubernetes 是一個可擴展的系統(tǒng)，提供通配符訪問不僅可以授予集群中當前所有對象類型的權限，還可以授予將來創(chuàng)建的所有未來對象類型的權限。
- 除非特別需要，否則管理員不應使用?
cluster-admin?帳戶。提供具有模擬權限的低權限帳戶可以避免意外修改集群資源。
- 避免將用戶添加到 ?
system:masters? 組。作為該組成員的任何用戶都會繞過所有 RBAC 權限檢查，并且將始終擁有不受限制的超級用戶訪問權限，這不能通過刪除角色綁定或集群角色綁定來撤銷。順便說一句，如果集群正在使用授權 webhook，則該組的成員身份也會繞過該 webhook（來自該組成員的用戶的請求永遠不會發(fā)送到 webhook）
盡量減少特權代幣的分配
理想情況下，不應為 pod 分配被授予強大權限的服務帳戶。 如果工作負載需要強大的權限，請考慮以下做法：
- 限制運行強大 pod 的節(jié)點數(shù)量。 確保您運行的任何 DaemonSet 都是必需的，并且以最小權限運行以限制容器逃逸的爆炸半徑。
- 避免與不受信任或公開的 Pod 一起運行強大的 Pod。 考慮使用 Taints and Toleration、NodeAffinity 或 PodAntiAffinity 來確保 Pod 不會與不受信任或不太受信任的 Pod 一起運行。 特別注意可信度較低的 Pod 不符合 Restricted Pod 安全標準的情況。
Hardening
Kubernetes 默認提供并非每個集群都需要的訪問權限。 查看默認提供的 RBAC 權限可以為安全加固提供機會。 通常，不應更改提供給系統(tǒng)的權限：帳戶存在一些強化集群權限的選項：
- 查看 ?
system:unauthenticated? 組的綁定并在可能的情況下刪除，因為這樣可以訪問可以在網(wǎng)絡級別聯(lián)系 API 服務器的任何人。 - 通過設置 ?
automountServiceAccountToken: false? 來避免默認自動掛載服務帳戶令牌。為 Pod 設置此值將覆蓋服務帳戶設置，需要服務帳戶令牌的工作負載仍然可以掛載它們。
定期審查
定期檢查 Kubernetes RBAC 設置是否有冗余條目和可能的權限升級至關重要。 如果攻擊者能夠創(chuàng)建與已刪除用戶同名的用戶帳戶，他們可以自動繼承已刪除用戶的所有權限，尤其是分配給該用戶的權限。
Kubernetes RBAC - 提權風險
在 Kubernetes RBAC 中有許多權限，如果授予這些權限，則可以允許用戶或服務帳戶提升其在集群中的權限或影響集群外的系統(tǒng)。
本節(jié)旨在提供集群操作員應注意的區(qū)域的可見性，以確保他們不會無意中允許對集群的訪問超出預期。
Listing secrets
通常很清楚，允許對 Secrets 的訪問將允許用戶閱讀其內(nèi)容。 同樣重要的是要注意，?list?和?watch?訪問也有效地允許用戶透露秘密內(nèi)容。 例如，當返回 List 響應時（例如，通過 ?kubectl get secrets -A -o yaml?），響應包括所有 Secrets 的內(nèi)容。
工作負載創(chuàng)建
除非有基于 Kubernetes Pod 安全標準的限制，否則能夠創(chuàng)建工作負載（Pod 或管理 Pod 的工作負載資源）的用戶將能夠訪問底層節(jié)點。
可以運行特權 Pod 的用戶可以使用該訪問權限來獲得節(jié)點訪問權限，并可能進一步提升他們的權限。如果您不完全信任具有創(chuàng)建適當安全和隔離 Pod 的能力的用戶或??其他主體，則應強制執(zhí)行基線或受限 Pod 安全標準。您可以使用 Pod 安全準入或其他（第三方）機制來實施該強制。
您還可以使用已棄用的 PodSecurityPolicy 機制來限制用戶創(chuàng)建特權 Pod 的能力（注意，PodSecurityPolicy 計劃在版本 1.25 中刪除）。
在命名空間中創(chuàng)建工作負載還會授予對該命名空間中 Secret 的間接訪問權限。在 kube-system 或類似特權的命名空間中創(chuàng)建一個 pod 可以授予用戶對他們直接通過 RBAC 沒有的 Secret 的訪問權限
持久卷創(chuàng)建
對創(chuàng)建 PersistentVolume 的訪問可以允許升級對底層主機的訪問。 在需要訪問持久存儲的地方，受信任的管理員應該創(chuàng)建 PersistentVolume，并且受限用戶應該使用 PersistentVolumeClaims 來訪問該存儲。
訪問節(jié)點的代理子資源
有權訪問節(jié)點對象的代理子資源的用戶有權訪問 Kubelet API，該 API 允許在他們有權訪問的節(jié)點上的每個 pod 上執(zhí)行命令。 此訪問繞過審核日志記錄和準入控制，因此在授予此資源權限之前應小心。
Escalate verb
通常，RBAC 系統(tǒng)會阻止用戶創(chuàng)建比他們擁有的權限更多的集群角色。 一個例外是?escalate ?verb，擁有此權限的用戶可以有效地提升他們的權限。
Bind verb
與?escalate ?verb類似，授予用戶此權限允許繞過 Kubernetes 內(nèi)置的針對權限升級的保護，允許用戶創(chuàng)建與具有他們不具有的權限的角色的綁定。
Impersonate verb
此verb允許用戶模擬并獲得集群中其他用戶的權限。 授予它時應小心，以確保不能通過模擬帳戶之一獲得過多的權限。
CSRs 和證書頒發(fā)
CSR API 允許具有 CSR 創(chuàng)建權限和更新?certificatesigningrequests/approval?權限的用戶，其中簽名者是 ?kubernetes.io/kube-apiserver-client?，以創(chuàng)建新的客戶端證書，允許用戶對集群進行身份驗證。 這些客戶端證書可以具有任意名稱，包括 Kubernetes 系統(tǒng)組件的副本。 這將有效地允許特權升級。
Token請求
對 ?serviceaccounts/token? 具有?create?權限的用戶可以創(chuàng)建 TokenRequests 來為現(xiàn)有的服務帳戶頒發(fā)令牌。
控制準入 webhook
控制驗證?webhookconfigurations?或?mutatingwebhookconfigurations?的用戶可以控制可以讀取集群允許的任何對象的webhook，并且在改變webhook的情況下，也可以改變允許的對象。
Kubernetes RBAC - 拒絕服務風險
對象創(chuàng)建拒絕服務
有權在集群中創(chuàng)建對象的用戶可能能夠根據(jù)對象的大小或數(shù)量創(chuàng)建足夠大的對象來創(chuàng)建拒絕服務條件，正如 Kubernetes 使用的 etcd 中所討論的那樣容易受到 OOM 攻擊。 如果允許半受信任或不受信任的用戶對系統(tǒng)進行有限訪問，這可能與多租戶集群特別相關。
緩解此問題的一種選擇是使用資源配額來限制可以創(chuàng)建的對象數(shù)量。
本文標題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes基于角色的訪問控制良好實踐
網(wǎng)頁網(wǎng)址：http://www.5511xx.com/article/cohpdgi.html
