Synthetic ClusterRole or Role using an aggregationRule

kubernetes Role ClusterRole aggregationRule

2 min read | by Jordi Prats

Having a Role or ClusterRole giving permissions to different apiGroups for different reasons makes it difficult to track and, later on, to maintain. By splitting the permissions on logical groups allows us to give predefined groups of permissions to the actual Role.

First we'll have to create a ClusterRole or Role with a specific function, for instance, read-external-secrets or update-external-secrets.

To be able to aggregate it later on we'll need to add a label that we'll be using across other Roles, for example:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    rbac.authorization.k8s.io/aggregate-to-additional-demo: "true"
  name: some-logical-aggregation
rules:
(...)

To create a Role that is the aggregation of others we'll need to use aggregationRule with whatever label we are using on the pieces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  name: demo-composable
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.authorization.k8s.io/aggregate-to-demo: "true"

This ClusterRole is going to get the rules from the other ClusterRoles. This way we won't be mixing apiGroups that belong to completely different use-cases, making it much easier to update in the long run, specially if we rely on CRDs to provide functionality:

$ kubectl get clusterrole demo -o yaml | wc -l
     273
$ kubectl get clusterrole -l rbac.authorization.k8s.io/aggregate-to-demo=true | wc -l
      76

Posted on 13/12/2022

Categories