建站
咨詢
售后
建站咨詢
新聞中心
本篇內(nèi)容介紹了“審計(jì)Kubernetes RBAC策略的方法是什么”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)公司提供高防物理服務(wù)器租用、云服務(wù)器、香港服務(wù)器、成都聯(lián)通服務(wù)器托管等
認(rèn)證與授權(quán)對(duì)任何安全系統(tǒng)來(lái)說(shuō)都至關(guān)重要，Kubernetes 也不例外。即使我們不是安全工作人員，也需要了解我們的 Kubernetes 集群是否具有足夠的訪問(wèn)控制權(quán)限。Kubernetes 社區(qū)也越來(lái)越關(guān)注容器的安全評(píng)估（包括滲透測(cè)試，配置審計(jì)，模擬攻擊），如果你是應(yīng)用安全工程師，或者是安全感知的 DevOps 工程師，最好了解一下 Kubernetes 的授權(quán)模型。
Kubernetes 的授權(quán)控制原則與大多數(shù)系統(tǒng)一樣：在授予訪問(wèn)權(quán)限時(shí)采用最小授權(quán)原則。例如，如果某個(gè) Pod 使用了特定的 serviceAccount，那么該 Pod 被限定為只能擁有指定的權(quán)限，只能訪問(wèn)特定的資源。
Kubernetes 從 1.6 開(kāi)始支持基于角色的訪問(wèn)控制機(jī)制（Role-Based Access，RBAC），集群管理員可以對(duì)用戶或服務(wù)賬號(hào)的角色進(jìn)行更精確的資源訪問(wèn)控制。先簡(jiǎn)單回顧一下 RBAC 的原理。
1. RBAC 基礎(chǔ)概念
RBAC 授權(quán)策略會(huì)創(chuàng)建一系列的 Role 和 ClusterRole 來(lái)綁定相應(yīng)的資源實(shí)體（serviceAccount 或 group），以此來(lái)限制其對(duì)集群的操作。每一個(gè) Role 都基于 Create, Read, Update, Delete（CRUD）模型來(lái)構(gòu)建，并使用“動(dòng)詞”來(lái)應(yīng)用相應(yīng)的權(quán)限。例如，動(dòng)詞 get 表示能夠獲取特定資源的詳細(xì)信息。如果你想獲取對(duì) Secrets 的訪問(wèn)權(quán)限，可以創(chuàng)建如下的 ClusterRole：
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"]
關(guān)于 RBAC 的更多詳細(xì)文檔請(qǐng)參考 Kubernetes 官方文檔或 CNCF 的博客。
2. RBAC 實(shí)踐
RBAC 授權(quán)模型為我們提供了一種精確的訪問(wèn)控制機(jī)制，但隨著環(huán)境越來(lái)越復(fù)雜，這些 RBAC 配置也越來(lái)越難維護(hù)。RBAC 配置可能包含了 Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts 和 Groups 等，想要跟蹤它們之間的關(guān)系非常困難。
舉個(gè)栗子，先創(chuàng)建一個(gè)名叫 helm 的 ServiceAccount，然后創(chuàng)建相應(yīng)的 Role 綁定 “tiller-world” namespace，該 Role 只擁有 list pods 的權(quán)限，最后通過(guò)創(chuàng)建 RoleBinding 將該 Role 與之前創(chuàng)建的 ServiceAccount 綁定。
apiVersion: v1 kind: ServiceAccount metadata: name: helm namespace: helm-world --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: tiller-user namespace: tiller-world rules: - apiGroups: - "" resources: - pods/portforward verbs: - create - apiGroups: - "" resources: - pods verbs: - list --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: tiller-user-binding namespace: tiller-world roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: tiller-user subjects: - kind: ServiceAccount name: helm namespace: helm-world
如果你想知道新創(chuàng)建的授權(quán)對(duì)象是否僅被授予必要的訪問(wèn)權(quán)限，就需要審查這些對(duì)象及其在集群中的關(guān)系。有時(shí)候還需要確保其僅對(duì)特定的資源實(shí)例具有訪問(wèn)權(quán)限，不允許訪問(wèn)所有的資源實(shí)例。例如，如果你不想讓上面的 ServiceAccount 訪問(wèn)所有的 Secret，只允許它訪問(wèn)特定的 Secret，可以使用 resourceNames 字段指定：
rules: - apiGroups: [""] resources: ["secrets"] resourceNames: ["my-pod-secrets"] verbs: ["get", "watch", "list"]
這個(gè)方法的問(wèn)題在于無(wú)法過(guò)濾集群中不存在的資源，這意味著如果資源的名稱(chēng)是動(dòng)態(tài)變化的，那么就無(wú)法創(chuàng)建相應(yīng)的 Role，除非在創(chuàng)建 Role 的同時(shí)創(chuàng)建資源。
3. 審計(jì)很重要
為了查看每個(gè) Role 的作用以及每個(gè)資源對(duì)象應(yīng)該能做哪些事情，我們不得不進(jìn)行一些審計(jì)工作。最簡(jiǎn)單的審計(jì)就是確認(rèn)某個(gè) Service Account 是否擁有 Cluster Admin 的權(quán)限，再?gòu)?fù)雜一點(diǎn)，確認(rèn)某個(gè) CI/CD Service Account 在指定的 namespace 內(nèi)是否擁有 Update Pod 的權(quán)限。
基于審計(jì)的目標(biāo)，大致可以分為兩種審計(jì)模式：
資源審計(jì)：識(shí)別風(fēng)險(xiǎn)最高的資源對(duì)象，并查看誰(shuí)可以訪問(wèn)它們。
賬戶審計(jì)：查看賬戶的有效權(quán)限并確保它們的合理性。
賬戶審計(jì)比較徹底，但很耗時(shí)；資源審計(jì)可以更快發(fā)現(xiàn)問(wèn)題，但可能會(huì)有所遺漏。舉例：
資源審計(jì)：查看誰(shuí)能訪問(wèn)某個(gè) Secret 資源，并確保其是否遵循最小授權(quán)原則。
賬戶審計(jì)：遍歷所有的 user，group，Service Account 和 RoleBinding，確保它們是否被授予正確的訪問(wèn)權(quán)限，并只限定在特定的 namespace 內(nèi)。
下面提供幾種命令行工具來(lái)幫助大家更方便地審計(jì) RBAC。
4. Kubectl Can-I
某些生產(chǎn)環(huán)境不允許安裝額外的服務(wù)，只能使用 kubectl，我們可以使用 kubectl 的內(nèi)置命令 kubectl auth can-i 來(lái)查看 RBAC 權(quán)限。
例如，查看你是否擁有 get pod 的權(quán)限：
$ kubectl auth can-i get pods yes
查看你是否擁有 cluster-admin 的權(quán)限：
$ kubectl auth can-i "*" "*" yes
列出你在某個(gè) namesapce 中擁有的所有權(quán)限：
$ kubectl auth can-i --list --namespace=secure Resources Non-Resource URLs Resource Names Verbs *.* [] [] [*] [*] [] [*] selfsubjectaccessreviews.authorization.k8s.io [] [] [create] selfsubjectrulesreviews.authorization.k8s.io [] [] [create] [/api/*] [] [get] [/api] [] [get] [/apis/*] [] [get] [/apis] [] [get] [/healthz] [] [get] [/healthz] [] [get] [/openapi/*] [] [get] [/openapi] [] [get] [/version/] [] [get] [/version/] [] [get] [/version] [] [get] [/version] [] [get]
來(lái)點(diǎn)更有趣的，我們還可以通過(guò) Kubernetes 的 Impersonation API 來(lái)查看其他賬戶是否擁有訪問(wèn)特定資源的權(quán)限。例如，查看名為 unprivileged-service-account 的 Service Account 是否擁有 get pod 的權(quán)限：
$ kubectl auth can-i get pod \ --as system:serviceaccount:secure:unprivileged-service-account yes
--as 參數(shù)用來(lái)指定賬戶名稱(chēng)，類(lèi)似的參數(shù)還有 --as-group，背后的原理實(shí)際上是一組傳遞給 API Server 的請(qǐng)求頭。
Kubernetes 中除了有 Service Account 之外還會(huì)有 User，每創(chuàng)建一個(gè) Service Account，都會(huì)自動(dòng)創(chuàng)建一個(gè)對(duì)應(yīng)的 User，名稱(chēng)格式為：system:serviceaccount:。想知道某個(gè) Service Account 的 username 可以通過(guò)它的 yaml 文件來(lái)推算：
$ kubectl get serviceaccount unprivileged-service-account -o yaml apiVersion: v1 kind: ServiceAccount metadata: creationTimestamp: "2019-07-23T17:44:31Z" name: unprivileged-service-account namespace: default resourceVersion: "98089" selfLink: /api/v1/namespaces/default/serviceaccounts/unprivileged-service-account secrets: - name: unprivileged-service-account-token-9cggz
通過(guò)將 verbs 字段的值指定為 impersonate，可以讓某個(gè)用戶擁有其他用戶的權(quán)限，即可以模擬其他用戶。例如，管理員可以使用此功能通過(guò)暫時(shí)模擬其他用戶并查看請(qǐng)求是否被拒絕來(lái)調(diào)試授權(quán)策略。
例如，如果你想讓非 Cluster Admin 賬戶能夠模擬其他用戶，可以創(chuàng)建如下的 ClusterRole：
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole metadata: name: impersonator rules: - apiGroups: [""] resources: ["users", "groups", "serviceaccounts"] verbs: ["impersonate"]
5. Kubectl Who Can
下面介紹的這款工具是 kubectl 的插件，插件名叫 who-can，顧名思義，用來(lái)顯示哪些賬戶擁有訪問(wèn)特定資源的權(quán)限。安裝方法很簡(jiǎn)單，可以通過(guò) kubectl 的插件管理框架 Krew 來(lái)安裝：
安裝 krew。參考 https://github.com/kubernetes-sigs/krew/
安裝
who-can：$ kubectl krew install who-can
假設(shè) secure namespace 中有一個(gè) Secret 名為 cluster-admin-creds，你想查看誰(shuí)擁有訪問(wèn)它的權(quán)限：
$ kubectl who-can get secret cluster-admin-creds -n secure ROLEBINDING NAMESPACE SUBJECT TYPE SA-NAMESPACE unpriv_sa_binding secure unprivileged-service-account ServiceAccount secure CLUSTERROLEBINDING SUBJECT TYPE SA-NAMESPACE cluster-admin system:masters Group
輸出信息也很一目了然，沒(méi)什么可說(shuō)的。提醒一下，該工具只支持查看 create、update 和 delete 這幾個(gè)訪問(wèn)權(quán)限，不支持 use。use 用來(lái)將 Pod Security Policy 綁定到相應(yīng)的 Role。
6. Rakkess
rakkess 與 who-can 類(lèi)似，可以列出某個(gè)賬戶對(duì)所有資源的訪問(wèn)權(quán)限，可以通過(guò) krew 來(lái)安裝。
使用方法也很簡(jiǎn)單，如果想查看當(dāng)前用戶對(duì)所有資源的訪問(wèn)權(quán)限，可使用如下命令：
如果想查看某個(gè)特定的 Service Account 對(duì)所有資源的訪問(wèn)權(quán)限，可以使用如下命令：
$ kubectl access-matrix --as system:serviceaccount:kube-ovn:ovn -n kube-ovn
更多用例可以參考官方文檔。
7. RBack
rback 用來(lái)對(duì) kubectl 的輸出結(jié)果進(jìn)行可視化展示，可以輸出為 .dot 格式，也可以輸出為 .png 或任何格式。
例如：
$ kubectl get sa,roles,rolebindings \ -n monitoring -o json | rback > rback.dot
或者保存為 png：
$ kubectl get sa,roles,rolebindings \ -n monitoring -o json \ | rback | dot -Tpng > rback.png
8. RBAC-View
rbac-view 也可以用來(lái)可視化賬戶與權(quán)限之間的關(guān)系，但與 rback 不同，它是一個(gè) web 應(yīng)用，安裝方法參考官方文檔。
使用方式：
$ kubectl rbac-view serving RBAC View and http://localhost:8800
在瀏覽器中打開(kāi)鏈接 http://localhost:8800。
9. 終極測(cè)試
上面提到的所有方法都可以幫助我們快速收集信息，但有時(shí)難免會(huì)出現(xiàn)誤報(bào)的情況。想要確認(rèn)某賬戶到底有沒(méi)有相應(yīng)的權(quán)限，可以使用下面提到的終極方法。例如，要想確認(rèn) secure namespace 中的 unprivileged-service-account 是否具有 get secret 的權(quán)限，可以使用如下的命令：
$ kubectl get secrets \ --as system:serviceaccount:secure:unprivileged-service-account \ -o yaml
10. 模擬攻擊
預(yù)防攻擊最好的方法是模擬攻擊，我們可以模擬一個(gè)黑客進(jìn)入其中的某個(gè) Pod，看看能否執(zhí)行一些不可描述的操作。步驟如下：
創(chuàng)建一個(gè) Service Account。
$ kubectl create serviceaccount ncc-sa
創(chuàng)建相應(yīng)的角色。
將 Role 與 Service Account 綁定。
創(chuàng)建一個(gè)測(cè)試 Pod，serviceAccountName 指定為
ncc-sa。
進(jìn)入該 Pod
驗(yàn)證是否具有
get pod的權(quán)限。$ kubectl get pod
“審計(jì)Kubernetes RBAC策略的方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
網(wǎng)站名稱(chēng)：審計(jì)KubernetesRBAC策略的方法是什么
本文URL：http://www.dlmjj.cn/article/gdpdhh.html
