審計Kubernetes RBAC策略的方法是什么

本篇內(nèi)容介紹了“審計Kubernetes RBAC策略的方法是什么”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

認證與授權(quán)對任何安全系統(tǒng)來說都至關(guān)重要，Kubernetes 也不例外。即使我們不是安全工作人員，也需要了解我們的 Kubernetes 集群是否具有足夠的訪問控制權(quán)限。Kubernetes 社區(qū)也越來越關(guān)注容器的安全評估（包括滲透測試，配置審計，模擬攻擊），如果你是應(yīng)用安全工程師，或者是安全感知的 DevOps 工程師，最好了解一下 Kubernetes 的授權(quán)模型。

Kubernetes 的授權(quán)控制原則與大多數(shù)系統(tǒng)一樣：在授予訪問權(quán)限時采用最小授權(quán)原則。例如，如果某個 Pod 使用了特定的 serviceAccount，那么該 Pod 被限定為只能擁有指定的權(quán)限，只能訪問特定的資源。

Kubernetes 從 1.6 開始支持基于角色的訪問控制機制（Role-Based Access，RBAC），集群管理員可以對用戶或服務(wù)賬號的角色進行更精確的資源訪問控制。先簡單回顧一下 RBAC 的原理。

1. RBAC 基礎(chǔ)概念

RBAC 授權(quán)策略會創(chuàng)建一系列的 Role 和 ClusterRole 來綁定相應(yīng)的資源實體（serviceAccount 或 group），以此來限制其對集群的操作。每一個 Role 都基于 Create, Read, Update, Delete（CRUD）模型來構(gòu)建，并使用“動詞”來應(yīng)用相應(yīng)的權(quán)限。例如，動詞 get 表示能夠獲取特定資源的詳細信息。如果你想獲取對 Secrets 的訪問權(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 的更多詳細文檔請參考 Kubernetes 官方文檔或 CNCF 的博客。

2. RBAC 實踐

RBAC 授權(quán)模型為我們提供了一種精確的訪問控制機制，但隨著環(huán)境越來越復(fù)雜，這些 RBAC 配置也越來越難維護。RBAC 配置可能包含了 Roles, RoleBindings, ClusterRoles, ClusterRoleBindings, ServiceAccounts 和 Groups 等，想要跟蹤它們之間的關(guān)系非常困難。

舉個栗子，先創(chuàng)建一個名叫 helm 的 ServiceAccount，然后創(chuàng)建相應(yīng)的 Role 綁定 “tiller-world” namespace，該 Role 只擁有 list pods 的權(quán)限，最后通過創(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)對象是否僅被授予必要的訪問權(quán)限，就需要審查這些對象及其在集群中的關(guān)系。有時候還需要確保其僅對特定的資源實例具有訪問權(quán)限，不允許訪問所有的資源實例。例如，如果你不想讓上面的 ServiceAccount 訪問所有的 Secret，只允許它訪問特定的 Secret，可以使用 resourceNames 字段指定：

rules:
- apiGroups: [""]
  resources: ["secrets"]
  resourceNames: ["my-pod-secrets"]
  verbs: ["get", "watch", "list"]

這個方法的問題在于無法過濾集群中不存在的資源，這意味著如果資源的名稱是動態(tài)變化的，那么就無法創(chuàng)建相應(yīng)的 Role，除非在創(chuàng)建 Role 的同時創(chuàng)建資源。

3. 審計很重要

為了查看每個 Role 的作用以及每個資源對象應(yīng)該能做哪些事情，我們不得不進行一些審計工作。最簡單的審計就是確認某個 Service Account 是否擁有 Cluster Admin 的權(quán)限，再復(fù)雜一點，確認某個 CI/CD Service Account 在指定的 namespace 內(nèi)是否擁有 Update Pod 的權(quán)限。

基于審計的目標(biāo)，大致可以分為兩種審計模式：

• 資源審計：識別風(fēng)險最高的資源對象，并查看誰可以訪問它們。

• 賬戶審計：查看賬戶的有效權(quán)限并確保它們的合理性。

賬戶審計比較徹底，但很耗時；資源審計可以更快發(fā)現(xiàn)問題，但可能會有所遺漏。舉例：

• 資源審計：查看誰能訪問某個 Secret 資源，并確保其是否遵循最小授權(quán)原則。

• 賬戶審計：遍歷所有的 user，group，Service Account 和 RoleBinding，確保它們是否被授予正確的訪問權(quán)限，并只限定在特定的 namespace 內(nèi)。

下面提供幾種命令行工具來幫助大家更方便地審計 RBAC。

4. Kubectl Can-I

某些生產(chǎn)環(huán)境不允許安裝額外的服務(wù)，只能使用 kubectl，我們可以使用 kubectl 的內(nèi)置命令 kubectl auth can-i 來查看 RBAC 權(quán)限。

例如，查看你是否擁有 get pod 的權(quán)限：

$ kubectl auth can-i get pods
yes

查看你是否擁有 cluster-admin 的權(quán)限：

$ kubectl auth can-i "*" "*"
yes

列出你在某個 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]

來點更有趣的，我們還可以通過 Kubernetes 的 Impersonation API 來查看其他賬戶是否擁有訪問特定資源的權(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ù)用來指定賬戶名稱，類似的參數(shù)還有 --as-group，背后的原理實際上是一組傳遞給 API Server 的請求頭。

Kubernetes 中除了有 Service Account 之外還會有 User，每創(chuàng)建一個 Service Account，都會自動創(chuàng)建一個對應(yīng)的 User，名稱格式為：system:serviceaccount:<namespace><serviceaccount>。想知道某個 Service Account 的 username 可以通過它的 yaml 文件來推算：

$ 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

通過將 verbs 字段的值指定為 impersonate，可以讓某個用戶擁有其他用戶的權(quán)限，即可以模擬其他用戶。例如，管理員可以使用此功能通過暫時模擬其他用戶并查看請求是否被拒絕來調(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，顧名思義，用來顯示哪些賬戶擁有訪問特定資源的權(quán)限。安裝方法很簡單，可以通過 kubectl 的插件管理框架 Krew 來安裝：

1. 安裝 krew。參考 https://github.com/kubernetes-sigs/krew/

2. 安裝 who-can：

   $ kubectl krew install who-can

   
   

假設(shè) secure namespace 中有一個 Secret 名為 cluster-admin-creds，你想查看誰擁有訪問它的權(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

輸出信息也很一目了然，沒什么可說的。提醒一下，該工具只支持查看 create、update 和 delete 這幾個訪問權(quán)限，不支持 use。use 用來將 Pod Security Policy 綁定到相應(yīng)的 Role。

6. Rakkess

rakkess 與 who-can 類似，可以列出某個賬戶對所有資源的訪問權(quán)限，可以通過 krew 來安裝。

使用方法也很簡單，如果想查看當(dāng)前用戶對所有資源的訪問權(quán)限，可使用如下命令：

如果想查看某個特定的 Service Account 對所有資源的訪問權(quán)限，可以使用如下命令：

$ kubectl access-matrix --as system:serviceaccount:kube-ovn:ovn -n kube-ovn

更多用例可以參考官方文檔。

7. RBack

rback 用來對 kubectl 的輸出結(jié)果進行可視化展示，可以輸出為 .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 也可以用來可視化賬戶與權(quán)限之間的關(guān)系，但與 rback 不同，它是一個 web 應(yīng)用，安裝方法參考官方文檔。

使用方式：

$ kubectl rbac-view
serving RBAC View and http://localhost:8800

在瀏覽器中打開鏈接 http://localhost:8800。

9. 終極測試

上面提到的所有方法都可以幫助我們快速收集信息，但有時難免會出現(xiàn)誤報的情況。想要確認某賬戶到底有沒有相應(yīng)的權(quán)限，可以使用下面提到的終極方法。例如，要想確認 secure namespace 中的 unprivileged-service-account 是否具有 get secret 的權(quán)限，可以使用如下的命令：

$ kubectl get secrets \
  --as system:serviceaccount:secure:unprivileged-service-account \
  -o yaml

10. 模擬攻擊

預(yù)防攻擊最好的方法是模擬攻擊，我們可以模擬一個黑客進入其中的某個 Pod，看看能否執(zhí)行一些不可描述的操作。步驟如下：

1. 創(chuàng)建一個 Service Account。

$ kubectl create serviceaccount ncc-sa

2. 創(chuàng)建相應(yīng)的角色。

3. 將 Role 與 Service Account 綁定。

4. 創(chuàng)建一個測試 Pod，serviceAccountName 指定為 ncc-sa。

5. 進入該 Pod

6. 驗證是否具有 get pod 的權(quán)限。

   $ kubectl get pod

“審計Kubernetes RBAC策略的方法是什么”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！