RBAC Access and Service Account

Introduction:

Role-Based Access Control (RBAC) is a security feature in Kubernetes that allows administrators to define and manage access control policies for resources in the cluster. With RBAC, you can grant or deny access to specific actions, such as creating or modifying a resource, to specific users or groups of users.

In this blog, we will discuss the following topics to understand complete RBAC in Kubernetes:

1. What is RBAC in Kubernetes?
2. RBAC Resources
3. Role and Role Binding
4. Service Accounts
5. Cluster Role and Cluster Role Binding
6. How to use RBAC in Kubernetes
7. What is RBAC in Kubernetes?

RBAC is an authorization mechanism that allows you to define fine-grained access control policies for resources in your Kubernetes cluster. It is based on the concept of roles, which are sets of permissions that define what actions a user or group of users can perform on specific resources in the cluster.

RBAC (Role-Based Access Control) is a method of controlling access to resources in a Kubernetes cluster. It allows administrators to define roles and assign permissions to users, groups, and service accounts in the cluster. RBAC helps to ensure that users have only the necessary access to resources, and can be used to enforce security and compliance policies in a Kubernetes environment.

RBAC in Kubernetes is implemented using two main components: Roles and ClusterRoles.

1. Roles: Roles define a set of permissions that can be granted to users, groups, or service accounts in a single namespace.
2. ClusterRoles: ClusterRoles define a set of permissions that can be granted to users, groups, or service accounts cluster-wide.

In order to use RBAC in Kubernetes, you need to create roles and cluster roles, and then bind them to subjects (users, groups, or service accounts) using RoleBindings and ClusterRoleBindings.

Here’s an example of how to create a role in a namespace that allows a user to list pods:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: list-pods-role
namespace: default
rules:
– apiGroups: [“”]
resources: [“pods”]
verbs: [“list”]

Here’s an example of how to create a cluster role that allows a user to list all namespaces:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: list-namespaces-role
rules:
– apiGroups: [“”]
resources: [“namespaces”]
verbs: [“list”]

Next, you need to bind the roles to subjects using RoleBindings and ClusterRoleBindings:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: list-pods-binding
namespace: default
subjects:
– kind: User
name: <user-name>
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: list-pods-role
apiGroup: rbac.authorization.k8s.io

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: list-namespaces-binding
subjects:
– kind: User
name: <user-name>
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: list-namespaces-role
apiGroup: rbac.authorization.k8s.io

RBAC in Kubernetes is a powerful tool for controlling access to resources in a cluster. By using roles and cluster roles, administrators can define fine-grained permissions for users, groups, and service accounts, and ensure that only the necessary access is granted to each subject.

1. RBAC Resources:

In Kubernetes, there are several resources that are used to define and manage RBAC policies. These include:

• Role: A role defines a set of permissions for accessing resources in the cluster.
• Role Binding: A role binding maps a role to a user or group of users, effectively granting them the permissions defined in the role.
• Cluster Role: A cluster role defines a set of permissions for accessing resources across the entire cluster, rather than just within a single namespace.
• Cluster Role Binding: A cluster role binding maps a cluster role to a user or group of users, effectively granting them the permissions defined in the cluster role.

1. Role and Role Binding:

A role is a set of permissions that define what actions a user or group of users can perform on specific resources in the cluster. To define a role, you create a YAML file that specifies the resources, verbs, and API groups that the role is allowed to access.

A role binding maps a role to a user or group of users, effectively granting them the permissions defined in the role. To define a role binding, you create a YAML file that specifies the role that is being granted, and the users or groups of users who are being granted the role.

For example, the following YAML file defines a role that allows users to get, list, and watch pods in a specific namespace:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: my-namespace
name: pod-reader
rules:
– apiGroups: [“”]
resources: [“pods”]
verbs: [“get”, “list”, “watch”]

Here is a list of common verbs in Kubernetes and a brief description of each:

• create: creates a new resource object
• describe: provides detailed information about a resource object
• apply: creates or updates a resource object
• delete: deletes a resource object
• get: retrieves one or more resource objects
• label: adds or updates labels on a resource object
• patch: updates a resource object partially
• scale: sets the number of replicas of a resource object
• rollout: manages changes to a deployment
• exec: executes a command in a running container
• logs: retrieves logs from a resource object.

And the following YAML file maps the pod-reader role to a specific user:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: my-namespace
  name: read-pods
subjects:
– kind: User
  name: my-user
  apiGroup: “”
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: “”

2. Service Accounts:

Service accounts are special types of users in Kubernetes that are used to run pods. Service accounts can be granted RBAC permissions just like any other user, allowing

A Service Account in Kubernetes is a special type of account used by applications running in a cluster. It provides a way for these applications to interact with the Kubernetes API, and is essential for automating tasks and managing resources within the cluster.

Each Service Account is associated with a set of credentials, such as a token or a certificate, which are used to authenticate the account when it interacts with the Kubernetes API. Service Accounts can be used to grant an application access to specific resources, and to control what actions the application can perform on those resources.

Service Accounts are created in a namespace, and can be associated with a specific set of permissions using RoleBindings. For example, you could create a Service Account for a deployment, and grant it the ability to list and create pods in a particular namespace.

Here’s an example of how to create a Service Account:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: default

Once the Service Account is created, you can associate it with a RoleBinding in the same namespace:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: my-role-binding
  namespace: default
subjects:
– kind: ServiceAccount
  name: my-service-account
  namespace: default
roleRef:
  kind: Role
  name: my-role
  apiGroup: rbac.authorization.k8s.io

In this example, the Service Account my-service-account is associated with the Role my-role in the default namespace. The RoleBinding specifies that the Service Account is a subject of the Role, and that the Role should be applied to the Service Account in the same namespace.

It’s important to note that Service Accounts are not automatically granted any permissions when they are created. Instead, you must explicitly assign the necessary permissions to the Service Account using RoleBindings.

In addition to granting permissions to Service Accounts, you can also use Service Accounts to provide credentials to pods running in the cluster. This can be done using the serviceAccountName field in a pod definition, as follows:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  namespace: default
spec:
  serviceAccountName: my-service-account
  containers:
  – name: my-container
    image: my-image

In this example, the pod my-pod is associated with the Service Account my-service-account. The Service Account provides the necessary credentials for the pod to interact with the Kubernetes API.

In conclusion, Service Accounts in Kubernetes provide a way for applications to interact with the Kubernetes API and manage resources within the cluster. By using Service Accounts, administrators can control what actions an application can perform on resources, and can ensure that each application has the necessary credentials to perform its tasks.