我目前面臨著目前的情況。我想讓用戶訪問各個命名空間，以便他們可以
- 使用 Helm 圖表創建和部署資源（例如，來自 Bitnami）
另一方面，用戶不應該
- 創建/檢索/修改/洗掉 RBAC 設定，如 ServiceAccounts、RoleBindings、Roles、NetworkPolicies
- 獲取與 ServiceAccounts 相關的秘密
當然，關鍵是在這里為它定義最好的Role。可能，以下不是最好的主意：
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: role
namespace: example-namespace
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
因此，如果您能提出一些明智的方法，讓用戶可以盡可能自由地作業，但不要接觸一些更“危險”的資源，那就太好了。
本質上，我想遵循此處概述的作業流程（https://jeremievallee.com/2018/05/28/kubernetes-rbac-namespace-user.html）。所以最重要的是，同一命名空間中的單個用戶無法讀取同一命名空間中用戶的秘密，從而無法使用其他人的憑據進行身份驗證。
uj5u.com熱心網友回復：
在我看來，以下策略會有所幫助：
- RBAC 僅限制對自己命名空間的服務帳戶的訪問。
automountServiceAccountToken: false使用策略確保秘密和 POD 級別。這有助于在出現節點安全漏洞時保護機密。該密鑰僅在執行時可用，不會存盤在 POD 中。
https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server
- 使用 kms（推薦）加密存盤在 ETCD 中的機密。但是，如果您沒有 km??s 提供商，那么您也可以選擇其他提供商以確保最低限度的安全性。
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/#providers
uj5u.com熱心網友回復：
聽起來 ClusterRole 編輯幾乎可以滿足您的需求。 https://kubernetes.io/docs/reference/access-authn-authz/rbac/#user-looking-roles
它將允許訪問機密“但是，此角色允許訪問機密并作為命名空間中的任何 ServiceAccount 運行 Pod，因此它可用于獲得命名空間中任何 ServiceAccount 的 API 訪問級別。”
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/396847.html
標籤：Kubernetes kubernetes-helm 红细胞 k8s-serviceaccount k8s-角色绑定