What Is Kubernetes RBAC and Why Do You Need It?

What Is Kubernetes RBAC?

Often, when organizations start their Kubernetes journey, they look up to implementing least privilege roles and proper authorization to secure their infrastructure. That’s where Kubernetes RBAC is implemented to secure Kubernetes resources such as sensitive data, including deployment details, persistent storage settings, and secrets. Kubernetes RBAC provides the ability to control who can access each API resource with what kind of access. You can use RBAC for both human (individual or group) and non-human users (service accounts) to define their types of access to various Kubernetes resources. 

For example, there are three different environments, Dev, Staging, and Production, which have to be given access to the team, such as developers, DevOps, SREs, App owners, and product managers.

What Is Kubernetes RBAC and Why Do You Need It?


Before we get started, we would like to stress that we will treat users and service accounts as the same, from a level of abstraction- every request, either from a user or a service account, is finally an HTTP request. Yes, we understand users and service accounts  (for non-human users) are different in nature in Kubernetes.

How To Enable Kubernetes RBAC

One can enable RBAC in Kubernetes by starting the API server with an authorization-mode flag on. Kubernetes resources used to apply RBAC on users are: 

Service Account

To manage users, Kubernetes provides an authentication mechanism, but it is usually advisable to integrate Kubernetes with your enterprise identity management for users such as Active Directory or LDAP. When it comes to non-human users (or machines or services) in a Kubernetes cluster, the concept of a Service Account comes into the picture. 

For example, The Kubernetes resources need to be accessed by a CD application such as Spinnaker or Argo to deploy applications, or one pod of service A needs to talk to another pod of service B. In such cases, a Service Account is used to create an account of a non-human user and specify the required authorization (using RoleBinding or ClusterRoleBinding).

You can create a Service Account by creating a yaml like the below:

YAML
  
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-sa
spec: 
  automountServiceAccountToken: false


And then apply it. 

Shell
  
$ kubectl apply -f nginx-sa.yaml
serviceaccount/nginx-sa created


And now you have to ServiceAccount for pods in the Deployments resource.

YAML
  
kind: Deployment
metadata:
  name: nginx1
  labels:
    app: nginx1
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx1
  template:
    metadata:
      labels:
        app: nginx1
    spec:
      serviceAccountName: nginx-sa
      containers:
      - name: nginx1
        image: nginx
        ports:
        - containerPort: 80


In case you don’t specify about serviceAccountName in the Deployment resources, then the pods will belong to the default Service Account. Note there is a default Service Account for each namespace and one for clusters. All the default authorization policies as per the default Service Account will be applied to the pods where Service Account info is not mentioned. 

In the next section, we will see how to assign various permissions to a Service Account using RoleBinding and ClusterRoleBinding. 

Role and ClusterRole

Role and ClusterRole are the Kubernetes resources used to define the list of actions a user can perform within a namespace or a cluster, respectively. 

In Kubernetes, the actors, such as users, groups, or ServiceAccount, are called subjects. A subject's actions, such as create, read, write, update, and delete, are called verbs. 

YAML
  
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: read-only
  namespace: dev-namespace
rules:
- apiGroups:
  - ""
  resources: ["*"]
  verbs:
  - get
  - list
  - watch


In the above Role resource, we have specified that the read-only role is only applicable to the deb-ns namespace and to all the resources inside the namespace. Any ServiceAccount or users that would be bound to the read-only role can take these actions- get, list, and watch. 

Similarly, the ClusterRole resource will allow you to create roles pertinent to clusters. An example is given below:

YAML
  
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: chief-role
rules:
- apiGroups:
- ""
resources: ["*"]
verbs:
- get
- list
- watch
- create
- update
- patch
- delete


Any user/group/ServiceAccount bound to the chief-role will be able to take any action in the cluster. 

In the next section, we will see how to grant roles to subjects using RoleBinding and ClusterRoleBinding.  

Also, note Kubernetes allows you to configure custom roles using Role resources or use default user-facing roles such as the following:

RoleBinding and ClusterRoleBinding 

To apply the Role to a subject (user/group/ServiceAccount), you must define a RoleBinding. This will give the user the least privileged access to required resources within the namespace with the permissions defined in the Role configuration. 

YAML
  
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: Role-binding-dev
roleRef:
  kind: Role
  name: read-only #The role name you defined in the Role configuration
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
  name: Roy #The name of the user to give the role to
  apiGroup: rbac.authorization.k8s.io
- kind: ServiceAccount
  name: nginx-sa#The name of the ServiceAccount to give the role to
  apiGroup: rbac.authorization.k8s.io


Similarly, ClusterRoleBinding resources can be created to define the Role of users. Note we have used the default superuser ClusterRole reference provided by Kubernetes instead of using our custom role. This can be applied to cluster administrators. 

YAML
  
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
 name: superuser-binding
roleRef:
 kind: ClusterRole
 name: superuser
 apiGroup: rbac.authorization.k8s.io
subjects:
- kind: User
 name: Aditi
 apiGroup: rbac.authorization.k8s.io


Benefits of Kubernetes RBAC

The advantage of Kubernetes RBAC is it allows you to “natively” implement the least privileges to various users and machines in your cluster. The key benefits are:

Proper Authorization 

With the least privileges to various users and Service Accounts to Kubernetes resources, DevOps and architects can implement one of the main pillars of zero trust. Organizations can reduce the risk of data breaches and data leakage and also avoid internal employees accidentally deleting or manipulating any critical resources. 

Separation of Duties

Applying RBAC on Kubernetes resources will always facilitate separation of duties of users such as developers, DevOps, testers, SREs, etc., in an organization. For e.g., for creating/deleting a new resource in a dev environment, developers should not depend on admin. Similarly, deploying new applications into test servers and deleting the pods after testing should not be a bottleneck for DevOps or testers. Applying authorization and permissions to users such as developers and CI/CD deployment agents into respective workspaces (say namespaces or clusters) will decrease the dependencies and cut the slack. 

100% Adherence to Compliance

Many industry regulations, such as HIPAA, GDPR, SOX, etc., demand tight authentication and authorization mechanisms in the software field. Using Kubernetes RBAC, DevOps, and architects can quickly implement RBAC into their Kubernetes cluster and improve their posture to adhere to those standards. 

Disadvantages of Kubernetes RBAC

For small and medium enterprises, using Kubernetes RBAC is justified, but it is not advisable to use Kubernetes RBAC for the below reasons:

 

 

 

 

Top