使用集群管理员角色创建新的 CRD 资源

Question

我创建了一个新的服务帐户和一个角色绑定，赋予他集群管理员的角色，如下所示。我用它应用了一个新的 CRD 资源，我预计它会失败，因为默认集群管理员角色无法管理 CRD，除非创建了一个带有聚合到管理员标签的新 ClusterRole，但是 CRD 已创建，我不明白为什么.

https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles

kubectl create -f new_crd.yaml --as=system:serviceaccount:test-ns:test

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: test-rolebinding
subjects:
- kind: ServiceAccount
  name: test
  namespace: test-ns
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

Answer 1

解决最后一条评论的部分：

<块引用>

我不明白使用aggregate-to-admin标签的目的——我认为它的目的是向cluster-admin添加规则，但如果cluster-admin可以做任何事情，那么为什么要使用它？< /p>

aggregate-to-admin 是用于聚合 label 的 ClusterRoles。此精确值用于将 ClusterRoles 聚合为 admin ClusterRole。

<块引用>

附注！

cluster-admin 和 admin 是两个独立的 ClusterRoles。

我将包含聚合 ClusterRoles 的示例，并在下面进行说明。

您可以阅读Kubernetes官方文档：

<头>

默认集群角色	默认集群角色绑定	说明
集群管理员	系统：大师组	允许超级用户访问对任何资源执行任何操作。在 ClusterRoleBinding 中使用时，它可以完全控制集群和所有命名空间中的每个资源。在 RoleBinding 中使用时，它可以完全控制角色绑定命名空间中的每个资源，包括命名空间本身。
管理员	无	允许管理员访问，旨在使用 RoleBinding 在命名空间内授予。如果在 RoleBinding 中使用，则允许对命名空间中的大多数资源进行读/写访问，包括能够在命名空间内创建角色和角色绑定。此角色不允许对资源配额或命名空间本身进行写访问。

• Kubernetes.io: Docs: Reference: Access authn authz: RBAC: User facing roles

---

使用聚合 ClusterRoles

聚合 Clusterroles 背后的原理是让一个 ClusterRole 聚合多个其他 ClusterRoles。

假设：

• A ClusterRole：aggregated-clusterrole 将聚合另外两个 ClusterRoles，它们对某些操作需要权限。
• A ClusterRole：clusterrole-one 将用于向 aggregated-clusterrole 添加一些权限
• A ClusterRole：clusterrole-two 将用于向 aggregated-clusterrole 添加一些权限

此类设置的示例可以通过 YAML 定义实现，如下所示：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: aggregated-clusterrole
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/put-here-any-label-name: "true" # <-- IMPORTANT
rules: [] 

以上定义将聚合使用 ClusterRoles 创建的 label：

• rbac.example.com/put-here-any-label-name: "true"

描述此 ClusterRole 而不将任何 ClusterRoles 与前面提到的 label 聚合：

• $ kubectl describe clusterrole aggregated-clusterrole

Name:         aggregated-clusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----

将使用的两个 ClusterRoles 如下：

clusterrole-one.yaml：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-one
  labels:
    rbac.example.com/put-here-any-label-name: "true" # <-- IMPORTANT
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

clusterrole-two.yaml：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: clusterrole-two
  labels:
    rbac.example.com/put-here-any-label-name: "true" # <-- IMPORTANT
rules:
- apiGroups: [""]
  resources: ["services"]
  verbs: ["create", "delete"]

应用上述定义后，您可以检查 aggregated-clusterrole 是否具有在 clusterrole-one 和 clusterrole-two 中使用的权限：

• $ kubectl describe clusterrole aggregated-clusterrole

Name:         aggregated-clusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  services   []                 []              [create delete]
  pods       []                 []              [get list watch]

---

其他资源：

• Kubernetes.io: Docs: Reference: Access authn authz: RBAC