K
Q

Question about using apiGroup with RoleRef when creating ClusterRoleBinding

1/8/2020

Here is a ClusterRoleBinding syntax that I found for creating Cluster role binding. Why does apiGroup needed to be specified when referring to role in roleRef? I have seen similar example in the Kubernetes docs. What is the possible explanation?

Example 1

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # Name is case sensitive
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

Example 2

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: traefik-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: traefik-ingress-controller
subjects:
- kind: ServiceAccount
  name: traefik-ingress-controller
  namespace: kube-system
-- randominstanceOfLivingThing
kubernetes

Similar Questions

Telepresence show full log for --run-shell
SonarQube on Kubernetes with MySQL via AWS RDS
CIDR and IP Address Ranges
Converting Docker-Compose to Kubernetes
GKE single ip load balancers overlap ports
what does nginx command do inside the container?

1 Answer

1/8/2020

All Kubernetes resources have group, version, name, so an apiGroup field is required to identify a group.
For example, if you create your Custom Resource Definition(CRD), you need setting these fields.
below is the sample controller example:

apiVersion: apiextensions.k8s.io/v1beta1
kind: CustomResourceDefinition
metadata:
  name: foos.samplecontroller.k8s.io
spec:
  group: samplecontroller.k8s.io
  version: v1alpha1
  names:
    kind: Foo
    plural: foos
  scope: Namespaced

(ServiceAccount resource is the core group. so I think ServiceAccount could be omitted a group field.)

-- bells17
Source: StackOverflow