談談 Kubernetes 的匿名訪問

rife發表於2023-03-28

文字翻譯自: https://raesene.github.io/blog/2023/03/18/lets-talk-about-ano...

本週有一些關於 Dero Cryptojacking operation 的文章，其中關於攻擊者所實施的細節之一引起了我的注意。有人提到他們正在攻擊允許匿名訪問 Kubernetes API 的叢集。究竟如何以及為什麼可以匿名訪問 Kubernetes 是一個有趣的話題，涉及幾個不同的領域，所以我想我會寫一些關於它的內容。

匿名訪問如何工作？

叢集是否可以進行匿名訪問由 kube-apiserver 元件的標誌 --anonymous-auth 控制，其預設為true，因此如果您在傳遞給伺服器的引數列表中沒有看到它，那麼匿名訪問將被啟用。

然而，僅憑此項設定並不能給攻擊者提供訪問叢集的很多許可權，因為它只涵蓋了請求在被處理之前透過的三個步驟之一（Authentication -> Authorization -> Admission Control ）。正如 Kubernetes 控制訪問 的文件中所示，在身份認證後，請求還必須經過授權和准入控制（認證 -> 授權 -> 准入控制）。

授權和匿名訪問

因此下一步是請求需要匹配授權策略（通常是 RBAC，但也可能是其他策略）。當然，為了做到這一點，請求必須分配一個身份標識，這個時候 system:anonymous 和 system:unauthenticated 許可權組就派上了用場。這些身份標識被分配給任何沒有有效身份驗證令牌的請求，並用於匹配授權政策。

您可以透過檢視Kubeadm 叢集上的 system:public-info-viewer clusterrolebinding 來了解類似的工作原理。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
    annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
    labels:
    kubernetes.io/bootstrapping: rbac-defaults
    name: system:public-info-viewer
roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: system:public-info-viewer
subjects:
- apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
    kind: Group
    name: system:unauthenticated

匿名訪問有多常見

現在我們知道了匿名訪問是如何工作的，問題就變成了“這有多常見？”。答案是大多數主要發行版都會預設啟用匿名訪問，並通常透過 system:public-info-viewer clusterrole提供一些對 /version 以及其他幾個端點的訪問許可權。

要了解這適用於多少叢集，我們可以使用 censys 或 shodan 來查詢返回版本資訊的叢集。例如，這個 censys 查詢 顯示返回版本資訊的主機超過一百萬，因此我們可以說這是一個相當常見的配置。

一個更嚴重的也更符合 dero 文章中提出的要點是，這些叢集中有多少允許攻擊者在其中建立工作負載。雖然您無法從 Censys 獲得確切的資訊，但它確實有一個顯示叢集的查詢，允許匿名使用者列舉叢集中的 pod，在撰寫本文時顯示 302 個叢集節點。我猜其中一些/大部分是蜜罐，但也可能有幾個就是高風險的易受攻擊的叢集。

禁用匿名訪問

在非託管叢集（例如 Rancher、Kubespray、Kubeadm）上，您可以透過將標誌 --anonymous-auth=false 傳遞給 kube-apiserver 元件來禁用匿名訪問。在託管叢集（例如 EKS、GKE、AKS）上，您不能這樣做，但是您可以刪除任何允許匿名使用者執行操作的 RBAC 規則。例如，在 Kubeadm 叢集上，您可以刪除system:public-info-viewer clusterrolebinding和system:public-info-viewer clusterrole，以有效阻止匿名使用者從叢集獲取資訊。

當然，如果您有任何依賴這些端點的應用程式（例如健康檢查），它們就會中斷，因此測試您對叢集所做的任何更改非常重要。這裡的一種選擇是檢視您的審計日誌，看看是否有任何匿名請求向 API 伺服器發出。

結論

允許某種級別的匿名訪問是 Kubernetes 中的常見預設設定。這本身並不是一個很大的安全問題，但它確實意味著在許多配置中，阻止攻擊者破壞您的叢集的唯一方法是 RBAC 規則，因此一個錯誤可能會導致重大問題，尤其是當您的叢集暴露在網際網路上時。

相關文章