top of page

Kubernetes - Role-based access control (RBAC)

Kubernetes RBAC

The Kubernetes API provides access to sensitive data, including deployment details, persistent storage settings, and secrets. Over the years, the Kubernetes community has provided several important security features to the Kubernetes API, including role-based access control (RBAC).

Role-based access control (RBAC) is a way of granting users granular access to Kubernetes API resources. RBAC is a security design that restricts access to Kubernetes resources based on the role the user holds.

API Objects for configuring RBAC: Role, ClusterRole, RoleBinding and ClusterRoleBinding.

Role/ClusterRole only say what can be done, while who can do what is defined in a RoleBinding/ClusterRoleBinding.


  • Role defines what can be done to Kubernetes Resources.

  • Role contains one or more rules that represent a set of permissions.

  • Permissions are additive. There are no deny rules.

  • Roles are namespaced, meaning Roles work within the constraints of a namespace. It would default to the default namespace if none was specified.

  • After creating a Role, you assign it to a user or group of users by creating a RoleBinding.


  • ClusterRole works the same as Role, but they are applied to the cluster as a whole.

  • ClusterRoles are not bound to a specific namespace. ClusterRole give access across more than one namespace or all namespaces.

  • After creating a ClusterRole, you assign it to a user or group of users by creating a RoleBinding or ClusterRoleBinding.

  • ClusterRoles are typically used with service accounts.

Default ClusterRole:

cluster-admin: Cluster wide super user.

admin: Full access within a Namespace.

edit: Read/write within a Namespace.

view: Read-only within a Namespace.


  • Role Binding is used for granting permission to a Subject.

  • RoleBinding holds a list of subjects (users, groups, or service accounts), and a reference to the role being granted.

  • Role and RoleBinding are used in namespaced scoped.

  • RoleBinding may reference any Role in the same namespace.

  • After you create a binding, you cannot change the Role or ClusterRole that it refers to. If you do want to change the roleRef for a binding, you need to remove the binding object and create a replacement.


  • ClusterRole and ClusterRoleBinding function like Role and RoleBinding, except they have wider scope.

  • RoleBinding grants permissions within a specific namespace, whereas a ClusterRoleBinding grants access cluster-wide and to multiple namespaces.

  • ClusterRoleBinding is binding or associating a ClusterRole with a Subject (users, groups, or service accounts).

Elements in RBAC Definition


Subjects are nothing but a group of users, services, or team making an attempt at Kubernetes API. It defines what operations a user, service, or a group can perform.

Users: These are global, and meant for humans or processes living outside the cluster.

Groups: Set of users.

Service Accounts: Kubernetes uses service accounts to authenticate and authorize requests by pods to the Kubernetes API server. These are namespaced and meant for intra-cluster processes running inside pods.


The set of operations that can be executed to the resources are called verbs. For examples, different verbs are get, watch, create, delete. Ultimately all of them are Create, Read, Update or Delete (CRUD) operations.


The set of Kubernetes API Objects available in the cluster are called Resources. For examples, Pods, Deployments, Services, Nodes, PersistentVolumes etc.

RBAC Examples:

Kubernetes Cluster - RBAC Examples

Creating Service Account Run the following command to add a new service account called king: $ kubectl create serviceaccount king serviceaccount/king created Find the name of the secret that stores t

Kubernetes Cheat Sheet

This page contains a list of commonly used kubectl commands and flags. Kubectl apply - Creating objects # create resource(s) kubectl apply -f ./my-manifest.yaml # create from multiple files kubectl a

Kubernetes Sample Yaml Files

Here the Sample Deployment and Service yaml file to deploy the application start pods in the existing node. deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: king-app spec: repl


bottom of page