Kubernetes 101: Role-Based Access Control

Introduction

Role-Based Access Control (RBAC) is a crucial part of any sophisticated system's security architecture. It provides a mechanism to manage authorization, which means determining what operations an authenticated user can perform. RBAC achieves this through roles that are assigned a set of permissions and these roles are in turn assigned to users.

What is RBAC?

RBAC, in Kubernetes, hinges on four main components: Role, ClusterRole, RoleBinding, and ClusterRoleBinding.

Role

This is essentially a set of permissions that apply to a certain namespace and determines what actions can be taken on a resource within that namespace. The permissions are contained in policy rules. Here is an example of a Role that can be created to read ConfigMaps in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-reader
rules:
- apiGroups: [""]
  resources: ["configmaps"]
  verbs: ["get", "watch", "list"]

ClusterRole

Like a Role, a ClusterRole contains permissions in policy rules, but unlike a Role, these apply cluster-wide. A ClusterRole can be used to grant access to resources at a cluster level, or even across multiple namespaces. Here's a simple example of a ClusterRole:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding

This is what binds a Role to a user or a set of users. It effectively applies the permissions of a Role to the user(s). Here's a RoleBinding example:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-configmaps
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: configmap-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding

Like RoleBinding but for ClusterRoles. It binds a ClusterRole to a user or a set of users. Here's a simple example of a ClusterRoleBinding:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: managers
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

The Role and Relation of RBAC to Other Resources

The integration of RBAC into a broader resource management strategy allows for fine-grained control over who can access and manipulate different Kubernetes resources. Consider a situation where you have a Deployment resource that manages a set of Pods. To manage who can update the Deployment, which would in turn control the Pods' configurations, you could create a Role that permits only certain operations on the Deployment resource within a specific namespace. This Role could then be assigned to a user or group of users via a RoleBinding.

For example, this is how you might define a Role that can only get, list, and watch Deployments in the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: deployment-reader
rules:
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["get", "watch", "list"]

Then you could create a RoleBinding to grant John, for instance, the permissions of the deployment-reader Role:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-deployments
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: deployment-reader
  apiGroup: rbac.authorization.k8s.io

Create your own RBAC

Implementing your own Role-Based Access Control (RBAC) involves understanding your specific needs, defining roles accordingly, and binding these roles to appropriate users, groups, or service accounts. Here is a step-by-step guide to creating and implementing RBAC:

Assess Your Needs

Understand the access needs of your users or services. For example, a certain group of developers might need read and write access to ConfigMaps and Secrets in a specific namespace, while another group may need read-only access to the same resources.

Define the Roles

Based on the needs you've identified, create Roles or ClusterRoles that encapsulate those permissions.

Here's an example of a Role that grants read and write access to ConfigMaps and Secrets within the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: config-secret-manager
rules:
- apiGroups: [""]
  resources: ["configmaps", "secrets"]
  verbs: ["get", "watch", "list", "create", "update", "delete"]

Define RoleBindings or ClusterRoleBindings

Next, bind the roles to the appropriate users, groups, or service accounts using RoleBindings or ClusterRoleBindings.

Here's an example of a RoleBinding that assigns the config-secret-manager role to the user john within the default namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: config-secret-manager-binding
  namespace: default
subjects:
- kind: User
  name: john
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: config-secret-manager
  apiGroup: rbac.authorization.k8s.io

Apply the Roles and RoleBindings

Now, use kubectl apply to create these resources on your Kubernetes cluster:

~$ kubectl apply -f role.yaml kubectl apply -f rolebinding.yaml

Verify the Access

You can verify if the access was granted correctly by impersonating the user and trying to perform an operation that should be permitted by the role. For example, as john, you should now be able to list the ConfigMaps in the default namespace:

~$ kubectl --as=john get configmaps -n default

Continuously Monitor and Update Access

Ensure you have a system to audit your roles and bindings regularly. This could be manual (regular reviews of all roles and bindings) or automated (using tools or scripts). Make updates as necessary when job functions change, or users are added or removed.

By following these steps, you can effectively create and implement your own RBAC policies in Kubernetes. Remember that the principle of least privilege should guide the process – only grant the access that is absolutely necessary for a user or service to function.

About 8grams

We are a small DevOps Consulting Firm that has a mission to empower businesses with modern DevOps practices and technologies, enabling them to achieve digital transformation, improve efficiency, and drive growth.

Ready to transform your IT Operations and Software Development processes? Let's join forces and create innovative solutions that drive your business forward.

Subscribe to our newsletter for cutting-edge DevOps practices, tips, and insights delivered straight to your inbox!