您可以將角色限制為滿足選擇器的物件嗎?

您可以將角色限制為滿足選擇器的物件嗎?

我們如何限制服務帳戶只能建立、列出、刪除等在給定命名空間內具有特定標籤的物件?


我們設計了一個服務層次結構(映射到 kubernetes 命名空間)和元件(由persona各種物件上的標籤表示),並將其與保管庫集成,這樣您有權訪問的秘密就特定於某個服務 -元件對。這有助於隔離事物。例如,假設一個團隊管理大量部署,但只有其中一些部署處理 PII 資料。我們可以使用該標籤來選擇性地授予對這些秘密的存取權限。

# only approximatively k8s objects
---
kind: Deployment
metadata:
  name: backend
  namespace: banana
  labels:
    persona: backend
spec: ...
# pods in this deployment have access to banana§backend secrets via a vault sidecar
---
kind: Deployment
metadata:
  name: frontend
  labels:
    persona: frontend
spec: ...
# pods in this deployment have access to banana§frontend secrets via a vault sidecar

但是,這意味著我們不想只建立一個可以管理的服務帳戶全部該命名空間中的 pod - 如果該服務帳戶的秘密被洩露,攻擊者可以使用它來啟動帶有惡意映像的 pod 並存取 PII。

所以我想要這樣的東西:(請注意,我對服務帳戶、角色和角色綁定的了解非常有限)

# even more approximatively so k8s objects
kind: Role
metadata:
  name: deploy-frontend
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]
  selector:
    labels:
      persona: frontend
# even if compromised, this service account cannot access banana§backend secrets

好像是k8s可能支援像這樣模糊的東西,例如透過提供特定資源名稱的清單(#),但是到目前為止 k8s 還不支援這個?還是我錯過了什麼?

我們唯一的選擇是設定對所有內容具有廣泛存取權限的叢集範圍服務帳戶,然後啟動 Web 服務,在使用令牌之前執行自己的自訂身分驗證和授權例程嗎?如果是的話,怎樣才能盡可能地限制這個「上帝帳戶」的範圍呢?

答案1

Kubernetes 沒有辦法限制清單動詞由賓語。如果您可以列出一個集合,則可以讀取該集合中的所有物件。

也許有一天這種情況會改變,但現在這就是 Kubernetes 在集合和讀取存取方面的工作方式。這包括對 Secrets 的讀取存取權…

但是,如果您想限制對於對象,你可以這樣做。您可以使用以下方法限制寫入特定命名物件的能力:

  • 外部驗證准入 Webhook
  • 一個(測試版)ValidatingAdmissionPolicy
  • 授權 Webhook

或使用精心設計的 RBAC 規則。


可以幫助您管理訪問的東西是分層命名空間控制器,允許團隊管理每個命名空間都有自己的限制。如果您的叢集支援 ValidatingAdmissionPolicies,您可以使用它們來進一步委託存取和限制寫入存取(儘管這是一個相當複雜的主題)。


如果您希望擁有一個可以執行某些操作的 ServiceAccount,但要委託控制這些操作,則可以使用 RoleBinding 在每個目標命名空間中建立一個 ServiceAccount,然後允許整個 ServiceAccount 模擬特定的 ServiceAccount。再說一次,這是一個相當複雜的事情,但它是可能的。

相關內容