kubernetes - Kubernetes 管理员隔离

Question

大多数 Kubernetes 操作员都需要能够创建集群角色、集群角色绑定和 crd。

我想要一个适当的 rbac 隔离，并且我想避免将部署服务帐户直接作为管理员。

但是如果我只给它集群角色编辑权限，似乎它允许它把自己放在最后。

处理这个问题的正确方法是什么？（如果有的话）。

Answer 1

您可以拥有命名空间并拥有只能访问您想要的特定资源和 apiGroups 的服务帐户。

apiVersion: v1
kind: ServiceAccount
metadata:
  name: gitlab-tez-dev # account name
  namespace: tez-dev #namespace

---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tez-dev-full-access #role
  namespace: tez-dev
rules:
  - apiGroups: ["", "extensions", "apps"]
    resources: ["deployments", "replicasets", "pods", "services"] #resources to which permissions are granted
    verbs: ["*"] # what actions are allowed
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: tez-dev-view
  namespace: tez-dev
subjects:
  - kind: ServiceAccount
    name: gitlab-tez-dev
    namespace: tez-dev
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: tez-dev-full-access

因此，上述角色没有集群访问权限，如果仅限于定义的命名空间以及指定的特定资源和操作，则它的访问权限。

然后，您可以使用它在定义的命名空间中进行部署。

Answer 2

您是否看到在prometheus-operator的情况下它是如何完成的？
它避免为部署服务帐户提供完整的管理员权限，尤其是让它控制对“rbac.authorization.k8s.io”API 组中的角色或集群角色资源执行“创建/绑定”操作的权限。
我认为您可以将其用作一个很好的参考方案，为运行的 App 和 App-Operator 设置单独的 RBAC 规则。