使用 cluster-admin 角色创建新的 CRD 资源

Question

I created a new service account and a rolebining giving him the role of cluster-admin as follows. I applied a new CRD resource with it and I expected it to fail as the default cluster-admin role can not manage CRD unless a new ClusterRole is created with aggregate-to-admin label, but the CRD was created and I do not understand why.

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

Addressing the part of the last comment:

I do not understand the purpose of using aggregate-to-admin label -- I thought its purpose is to add rules to cluster-admin but if cluster-admin can do anything in the first place then why it is used?

aggregate-to-admin is a label used to aggregate ClusterRoles . This exact is used to aggregate ClusterRoles to an admin ClusterRole .

A side note!

cluster-admin and admin are two separate ClusterRoles .

I will include the example of aggregating ClusterRoles with an explanation below.

You can read in the official Kubernetes documentation:

Default ClusterRole	Default ClusterRoleBinding	Description
cluster-admin	system:masters group	Allows super-user access to perform any action on any resource. When used in a ClusterRoleBinding, it gives full control over every resource in the cluster and in all namespaces. When used in a RoleBinding, it gives full control over every resource in the role binding's namespace, including the namespace itself.
admin	None	Allows admin access, intended to be granted within a namespace using a RoleBinding. If used in a RoleBinding, allows read/write access to most resources in a namespace, including the ability to create roles and role bindings within the namespace. This role does not allow write access to resource quota or to the namespace itself.

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

---

Using aggregated ClusterRoles

The principle behind aggregated Clusterroles is to have one ClusterRole that have multiple other ClusterRoles aggregated to it.

Let's assume that:

• A ClusterRole : aggregated-clusterrole will be aggregating two other ClusterRoles that will have needed permissions on some actions.
• A ClusterRole : clusterrole-one will be used to add some permissions to aggregated-clusterrole
• A ClusterRole : clusterrole-two will be used to add some permissions to aggregated-clusterrole

An example of such setup could be implemented by YAML definitions like below:

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: [] 

Above definition will be aggregating ClusterRoles created with a label :

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

Describing this ClusterRole without aggregating any ClusterRoles with previously mentioned label :

• $ kubectl describe clusterrole aggregated-clusterrole

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

Two ClusterRoles that will be used are the following:

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"]

After applying above definitions, you can check if aggregated-clusterrole have permissions used in clusterrole-one and 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]

---

Additional resources:

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