Skip to content

Role-based access control

Role-based access control (RBAC) is used to control access to Kubernetes API resources in a cluster. Permissions are granted via Roles and ClusterRoles. Permissions cannot be denied, only granted to a role.

To create these resources, you must be a cluster administrator. To install the charts into a cluster for which you do not have a Cluster Admin role, disable creation of these resources, and instead reference an account created for you.

Role Based Access Control on Kubernetes

Role and ClusterRole

An RBAC Role is set at a namespace level.

Grant a Role permissions to one or many API namespaces by setting the apiGroup field in the RBAC definition.

A ClusterRole is granted permissions in the same way as a Role however the permissions are applied at a cluster level. This lets you grant additional resources to the ClusterRole, such as nodes.

For example:

- apiGroups: [""]

In our examples we set this to an empty string. This applies the rule across all namespaces.

Rules are then applied on a Kubernetes resource level.

- apiGroups: [""]
  resources: ["endpoints", "services"]

The example applies the rule to the endpoints and services resources in the API server. You can also configure a named resource.

- apiGroups: [""]
  resources: ["services"]
  resourceNames: ["ticker-tp"]

To complete the Role permissions we need to add verbs to the rule.

- apiGroups: [""]
  resources: ["endpoints", "services"]
  verbs: ["get", "watch", "list"]

Here we allow the Role to list all endpoints and services, and to retrieve details on a resource within the namespace.

RoleBinding and ClusterRoleBinding

A Role or ClusterRole by itself does not allow an entity permissions: a user must then be bound to that Role.

Subjects are bound to a Role in a RoleBinding or ClusterRole in a ClusterRoleBinding. A subject may be a user, group or a serviceAccount.

In our example we use a serviceAccount to allow access to the Kubernetes API.

kind: RoleBinding
  name: gw-kx-viewer
- kind: ServiceAccount
  name: gw-kx
  apiGroup: ""
  kind: Role
  name: gw-kx-viewer
  apiGroup: ""

This gives the service account gw-kx the Role of gw-kx-viewer, granting that service account all the permissions of the Role.

Service account

A service account differs from a user entity. A user account is for a human user of the Kubernetes cluster, active over the entire cluster. A service account is for a pod process and is active only within a namespace.

By default, when a pod is not assigned a service account the default is assigned.

Regardless if it is a named or default service account assigned to the pod, the permissions and secrets of that service account are granted and mounted to the pod.

A secrets volume is mounted for the given service account:


This contains items such as access tokens which can be used to authenticate and permit querying the Kubernetes API server.

Helm configuration

The charts allow for service accounts SAs and RBAC resources to be created. The charts use RBAC to permit the containers to query the Kubernetes API.

Within each component Helm chart a RBAC Role and RoleBinding has been templated for a service account related to that chart.


name: {{ include "gw.fullname" . }}-viewer


name: {{ include "gw.fullname" . }}-viewer


name: {{ include "gw.serviceAccountName" . }}

To enable the creation of the RBAC roles and service account, update the component values file:

  create: true
  create: true

You can also use the global.rbac.create boolean to enable or disable the creation of these RBAC resources.

Alternatively if RBAC and service accounts have previously been created for you by a cluster admin, the relevant service account can be set by updating your component values file.

  # The name of the service account to use.
  # If not set and create is true, a name is generated using the fullname template
  name: "my-service-account"