K
Q

Creating new CRD resource with cluster-admin role

1/4/2021

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
-- Revital Eres
kubernetes
rbac

Similar Questions

Kubernetes Ingress SSL certificate
Cert-Manager provide own SSL Certificate for AKS
How can I connect with a database deployed at Kubernetes
Access parent (chart) context from subcharts
Nodejs Mongodb returns EHOSTUNREACH when requested from within a docker container hosted on kubernetes

1 Answer

1/5/2021

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 ClusterRoleDefault ClusterRoleBindingDescription
cluster-adminsystem:masters groupAllows 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.
adminNoneAllows 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.

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:

-- Dawid Kruk
Source: StackOverflow