How does roleRef define permissions?

The roleRef field defines permissions by referencing a specific Role or ClusterRole that contains the rules outlining what actions can be performed on which resources. Here's how it works:

Components of roleRef:

1. kind: Indicates whether the referenced role is a Role (namespace-scoped) or a ClusterRole (cluster-wide).
2. name: The name of the Role or ClusterRole that contains the permission rules.
3. apiGroup: Specifies the API group of the role, typically rbac.authorization.k8s.io.

How Permissions are Defined:

• Role/ClusterRole Rules: The referenced Role or ClusterRole includes a set of rules that define:
  • Verbs: Actions that can be performed (e.g., get, list, create, delete).
  • Resources: The types of resources the actions apply to (e.g., pods, services, deployments).
  • Resource Names: Specific names of resources (optional) that the actions can be performed on.
  • Namespaces: For Roles, it is scoped to a specific namespace; for ClusterRoles, it applies across all namespaces.

Example:

If you have a ClusterRole defined as follows:

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: myapp-admin
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "create", "delete"]

And you reference it in a ClusterRole Binding:

roleRef:
  kind: ClusterRole
  name: myapp-admin
  apiGroup: rbac.authorization.k8s.io

Result:

The subjects defined in the ClusterRole Binding will have the permissions to get, list, create, and delete pods across all namespaces, as specified in the myapp-admin ClusterRole. Thus, roleRef effectively links the subjects to the permissions defined in the referenced role.